App[编辑]
APP,是Accelerated Parallel Processing的缩写。中文译作AMD加速并行处理技术。是AMD针对旗下图形处理器(GPU)所推出的通用并行计算技术。利用这种技术可以充分发挥AMD GPU的并行运算能力,用于对软件进行加速运算或进行大型的科学运
第三方应用程序 应用程序application program的简称,由于iPhone智能手机的流行,现在的APP多指第三方智能手机的应用程序。目前比较著名的App商店有Apple的iTunes商店里面的App Store,android的Google Market,诺基亚的ovi store
编辑本段程序设计方面App
app是Application 的缩写
在VC++中,app是应用程序的入口和出口,一般在这里处理一些启动和退出程序时需要读取或写入的设置信息,还有设置一些全局变量。
编辑本段电脑领域中的APP
app server的前身是middleware(中间件),历史要长的多。早在上世纪六七十年代就已经开始在IBM大型机系统上广泛应用了,叫做TP Monitor,比较著名的是BEA的Tuxedo和IBM的CICS,运行在Terminal/Server模式的Server端,其功能主要是分离商业逻辑,进行分布式计算的,可以自动管理事务、资源和容错等等。因为发展的时间很长,所以技术非常成熟。middleware最早是用cobol编写的,现在还可以偶尔看到cobol的中间件的旧系统,再后来middleware改用C++来实现,著名中间件的有IBM的CICS,BEA的Tuexdo,仍然广泛的应用在高端系统中,特别是银行系统。
市场上常见的app 服务器的主要有以下几种:
1. Tomcat. Tomcat严格意义上并不是一个真正的App Server, 它只是一个可以支持运行Serlvet/JSP的Web容器,不过Tomcat也扩展了一些App Server的功能,如JNDI,数据库连接池,用户事务处理等等。Tomcat被非常广泛的应用在中小规模的Java Web应用中;
2. BEA Weblogic.
3. IBM Websphere.
4. Jboss. Jboss是免费开源的App Server.
然而在面向对象的技术出现和广泛的应用之后,TP Monitor由于不是面向对象的,而是面向过程的调用,因此TP Monitor管理的商业逻辑并没有分布式对象系统中的商业组件那样的可
不过像PHP这样主要还是面向过程调用的函数式的语言来说,TP Monitor仍然可以支持的非常完美,由于有了TP Monitor的支持,PHP也可以应用在企业的环境中了。
我所知道的eachnet用的是: Linux+Apache+PHP+Tuxedo+Oracle
eachnet在上海好几个ISP那里放了服务器,以保证服务不因某个ISP的问题而无法访问。我曾经见过eachnet在上海热线机房的服务器,说出来,大家可能不信,eachnet竟然用的是自己攒的兼容机,世纪之星的机箱,估计不比我们大家自己买的兼容机强到哪里去。大概有六七台机器的样子,来负载均衡。
对象请求代理(Object Request Brokers)是另一种用的很多的中间件,支持分布式对象的调用。然而它的问题是仅仅是一个代理(Broker),系统级的功能需要自己来实现,这包括管理并发性、事务、资源管理和容错机制等等,而且不同的厂商提供的ORB之间也存在互操作的兼容性问题。
于是一种综合了TP Monitor和ORB功能的新的服务器出现了,叫做CTM(Component Transaction Monitor)组件事务监控器。用在我们特定的管理应用程序的环境中就是App Server。
在1997年开始,CTM市场发生了巨大的变化,因为这一年Sun的J2EE标准正式发布,从此除了微软之外,所有的CTM厂商都用Java来改写自己的产品,例如Sybase原来有一个叫做Jagus CTS的东西,现在已经变成了纯Java实现的EAServer,Borland的公司app server也是这样来的。这样一来,除了微软之外,就剩下基于Java的app server了。
App Server可以自动管理并发性、事务、对象分布、负载均衡、安全性和资源管理等等系统级功能。简单的来说就是App Server是管理服务端组件的,它给服务端组件提供了一个全功能可靠的运行环境。
打个比方来说,数据库系统是管理数据的,它也给数据提供了一个受监控和管理的运行环境,提供了事务、安全性、负载均衡,并发性等等系统级功能,对于使用者来说,你不需要自己处理数据库表的并发锁定问题,自己处理SQL语句的解析、自己处理索引的优化等等系统级功能,同样对于服务端组件的调用者来说也不需要自己处理并发请求、对象创建、销毁、缓存,控制组件事务等等系统级功能。
App Server对服务端组件的的关系就是数据库系统对数据的关系。App Server完全是一个类似数据库系统这样一个非常复杂的服务端软件,所不同之处就是数据库系统(RDBMS)是管理数据的,而App Server是管理对象的。这也是我研究Weblogic Server之后的切身感受。
Microsoft是最早发布App Server的厂商,叫做Microsoft Transaction Server(MTS)。其他还有很多基于不同技术的App Server,不过随着EJB规范的发布,主流的App Server基本上都是基于J2EE的了。目前看来,App Server市场主要就是实现J2EE规范的Java应用服务器和Microsoft的.Net应用服务器这两大主流。
Tuxedo等基于过程传统的中间件会继续在特定的场合发挥巨大的作用,像那些需要极高的响应性能和基于特定平台C/C++的场合,还是具有不可替代的作用。
App Server提供的服务端组件模型并没有解决所有的问题,基于不同技术实现的服务端组件之间不能互相调用和数据共享,比如EJB组件和COM组件之间不能之间交换数据,所以基于SOAP协议的Web Services试图解决这个问题,想把互联网上所有的不同技术实现的组件服务都统一成单一的Web Services。这也是Web Services热门的原因之一,标准的统一对大家都有好处。
APP的应用:
应用一:启动载入默认窗口解析
通常APP Loading页后进入默认页,初始化的时候是需要链接网络的,有些程序的开始界面时间会长一点,会去读取网络信息,有些是进入后再读取。
不管何时读取,在网络连接有问题的情况下,都会在进入默认页面后显示“网络连接”的相关提示。默认页会遇到两种情况 :
一、有历史信息的情况:
把历史信息展现给用户,再后台拉取新的数据。如果遇到网络问题给出相应的提示。如图: 互联网的一些事
二、无历史信息情况:(如果首次使用app的话是没有历史信息的。)
一般有几种处理方式 :
1.采用仪表盘(宫格型)导航的App,这样的默认页一般本身有固定的内容,那么直接显示主页即可,遇网络问题显示“网络连接”提示。如图
2.Loading页后先进入功能引导页(What’s new),也有把引导和默认页面结合起来的。
3.预置一些推荐信息(就是通常说的造些信息,取代空白页面),这样没有网络的情况下也可以看到相关信息。比如:推荐些热门信息,信息内容根据app的类型确定(如图片,书籍、地点等等)这些信息只需要简单的列表,具体信息可以当用户点击后另外加载。遇网络问题显示“网络连接”提示。 互联网的一些事
4.直接提供一个范例,提前把用户操作后将得到的类似效果模拟展示给用户
应用二:当前页进入新页面的交互过程
方式一:在新页面载入.互联网的一些事
优点:即时切换页面。 互联网的一些事
适用:B页信息量大,如长篇图文混排信息页。
建议:1).进入B页时不要使用空白页面,采用预置的格式化信息(图片的占位符,信息分隔样式等);2).带入A页面已有的部分信息,3).对B页的信息进行分段载入。(这样用户边阅读提前载入的信息,边等待,减少焦躁情绪)
范例:载入中页面采用了预置格式化,在信息载入前已经把信息框架传递给了用户。用户对将要载入的信息有了预见。
方式二:在当前页载入完成后,再切换下一页。
优点:不会出现空白页面,切换页面完整性好。
互联网的一些事
适用:B页信息少,载入时间快,以文字为主的页面。或者A页面已在执行某个任务,且有延续性。比如A页面为一个音频播放页,用户在进入B页前可以继续收听。
建议:需要考虑网络极端不好的情况,载入信息极少时使用,如图05,ios原生短信应用采用的就是当前页载入,当遇到手机报之类的大量信息,就感觉界面卡上一小会。不过介于大部分短信都是文字为主,这样设计无可厚非,如果加载时间长的情况下如图06一样提供状态就更完美。 互联网的一些事
范例:
另外提交信息(如注册、登录等)一般都在当前页返回状态并处理加载。 互联网的一些事
加载方式是死的,其实也可以根据具体情况结合灵活使用。
比如:在A页载入的列表数据前几条拉取完整的数据信息,用户切换到详情B的情况下就直接可以看了。然后后台预读取余下的信息。减少用户切换延迟。(gmail就是这么做滴。前面5封邮件先预取。)这样做对服务器来说,要求高了些,大家具体用的时候自己权衡。 互联网的一些事
另外提一句,进入前保存A当前的状态,B返回A时回到进入前状态(如在第15条进入,返回时第15条信息在原来位置,并且配合原高亮消失效果)
http://www.wm23.com/wiki/244.htm
网络营销词典内容均由网友提供,仅供参考。如发现词条内容有问题,请发邮件至info # wm23.com。