软件架构模式基本概念及三者区别
在做软件架构设计时,根据不同的抽象层次可分为三种不同层次的模式:架构模式(Architectural Pattern)、设计模式(Design Pattern)、代码模式(Coding Pattern)。
架构模式是一个系统的高层次策略,涉及到大尺度的组件以及整体性质和力学。
架构模式的好坏可以影响到总体布局和框架性结构。
设计模式是中等尺度的结构策略。
这些中等尺度的结构实现了一些大尺度组件的行为和它们之间的关系。
模式的好坏不会影响到系统的总体布局和总体框架。
设计模式定义出子系统或组件的微观结构。
代码模式(或成例)是特定的范例和与特定语言有关的编程技巧。
代码模式的好坏会影响到一个中等尺度组件的内部、外部的结构或行为的底层细节,但不会影响到一个部件或子系统的中等尺度的结构,更不会影响到系统的总体布局和大尺度框架。
架构模式(Architectural Pattern)一个架构模式描述软件系统里的基本的结构组织或纲要。
架构模式提供一些事先定义好的子系统,指定它们的责任,并给出把它们组织在一起的法则和指南。
称之为系统模式。
?MVC模式,一个架构模式常常可以分解成很多个设计模式的联合使用。
MVC模式常常包括调停者(Mediator)模式、策略(Strategy)模式、合成(Composite)模式、观察者(Observer)模式等。
?Layers(分层)模式,有时也称Tiers模式?Blackboard(黑板)模式?Broker(中介)模式?Distributed Process(分散过程)模式?Microkernel(微核)模式架构模式常常划分成如下的几种:一、 模块结构(From Mud to Structure)型。
帮助架构师将系统合理划分,避免形成一个对象的海洋。
包括Layers(分层)模式、Blackboard(黑板)模式、Pipes/Filters(管道/过滤器)模式等。
二、分散系统(Distributed Systems)型。
为分散式系统提供完整的架构设计,包括像Broker(中介)模式等。
三、人机互动(Interactive Systems)型,支持包含有人机互动介面的系统的架构设计,例子包括MVC(Model-View-Controller)模式、PAC(Presentation-Abstraction-Control)模式等。
四、Adaptable Systems型,支持应用系统适应技术的变化、软件功能需求的变化。
如Reflection(反射)模式、Microkernel(微核)模式等。
设计模式(Design Pattern)一个设计模式提供一种提炼子系统或软件系统中的组件的,或者它们之间的关系的纲要设计。
设计模式描述普遍存在的在相互通讯的组件中重复出现的结构,这种结构解决在一定的背景中的具有一般性的设计问题。
设计模式常常划分成不同的种类,常见的种类有:创建型设计模式,如工厂方法(Factory Method)模式、抽象工厂(Abstract Factory)模式、原型(Prototype)模式、单例(Singleton)模式,建造(Builder)模式等结构型设计模式,如合成(Composite)模式、装饰(Decorator)模式、代理(Proxy)模式、享元(Flyweight)模式、门面(Facade)模式、桥梁(Bridge)模式等行为型模式,如模版方法(Template Method)模式、观察者(Observer)模式、迭代子(Iterator)模式、责任链(Chain of Responsibility)模式、备忘录(Memento)模式、命令(Command)模式、状态(State)模式、访问者(Visitor)模式等等。
以上是三种经典类型,实际上还有很多其他的类型,比如Fundamental型、Partition型,Relation型等等。
设计模式在特定的编程语言中实现的时候,常常会用到代码模式。
比如单例(Singleton)模式的实现常常涉及到双检锁(Double-Check Locking)模式等。
代码模式(Coding Pattern)代码模式(或成例)是较低层次的模式,并与编程语言密切相关。
代码模式描述怎样利用一个特定的编程语言的特点来实现一个组件的某些特定的方面或关系。
较为著名的代码模式的例子包括双检锁(Double-Check Locking)模式等
安卓软件架构是指什么
引言 软件架构是一门学科,开始于 20 世纪 70 年代。
面对不断增加的复杂性和开发复杂实时系统的压力,作为主流系统工程和软件开发的基本构造,软件架构应运而生。
与任何其他久经考验的学科一样,软件架构在诞生之初也面临许多挑战。
软件架构表示系统的结构和行为方面。
在早期为软件架构编写文档说明时,所使用的文本和图解表达常常不足或者不够精确。
所需的是某种一致并得到充分理解的伪(或元)语言,以便将对软件架构进行表示和编写文档说明的不同方式统一起来。
在学术研究的推动下,在用于开发有效软件架构文档说明的最佳实践和指导原则方面,工程和计算机科学领域已取得了长足的发展。
在本系列中,您将了解如何编写软件架构文档说明。
了解编写文档说明的不同方面:系统上下文、体系结构概述、功能体系结构、操作体系结构和体系结构决策。
在这第一篇文章中,了解软件架构是什么,以及为该学科的不同方面编写文档说明的重要性。
回页首软件架构不同的研究人员已解释了软件架构是什么,并且他们对有关如何最好地表示软件系统的体系结构具有不同的观点。
其中没有哪一种解释是错误的;每种解释都具有自己的价值。
Bass L 等人抓住了软件架构的本质: “程序或计算系统的软件架构是该系统的结构,包括软件组件、那些组件的外部可见的属性,以及那些组件之间的关系” 。
此定义重点关注由粗粒度的构造(软件组件)所构成的体系结构,可以将这些构造看作是体系结构的构建块。
每个软件组件或体系结构构建块具有某些外部可见的属性,这是它向其他体系结构构建块公开的属性。
软件组件的内部设计和实现细节不是系统的其他部分所关心的内容,系统的其他部分只是将某个特定组件视为一个黑盒。
该黑盒具有某些所公开的属性,其他软件组件可以使用这些属性来共同实现业务或 IT 目标。
软件架构在恰当的粒度级别标识体系结构构建块。
软件架构还标识那些构建块如何彼此相关,并进行文档记录。
与软件工程相关的体系结构涉及到将单个系统分解或划分为一组可迭代地、渐进地和独立地构造的部分。
各个部分彼此具有显式的关系。
当组合在一起时,各个部分就形成了系统、企业或应用程序的体系结构。
关于体系结构与设计之间的区别,存在一些混淆。
正如 Clements P 等人 所指出的,所有体系结构都是设计,但不是所有设计都是体系结构。
需要绑定以使系统满足其功能性和非功能性需求和目标的设计本质上是体系结构。
体系结构将体系结构构建块视为黑盒,而设计则处理体系结构构建块的配置、自定义和内部工作。
体系结构将软件组件与其外部属性绑定在一起。
设计通常要比体系结构松散得多,因为它允许以更多的方式遵守组件的外部属性。
设计还考虑用于实现组件内部细节的各种方法。
软件架构可以递归地使用。
请考虑一个属于某个系统的软件架构组成部分的软件组件 (C1)。
软件架构师将该组件及其应该公开的属性、功能和非功能特性及其与其他软件组件的关系交给系统设计人员。
设计人员在分析软件组件 C1 之后,决定将该组件分解为更细粒度的组件(C11、C12 和 C13),其中每个组件提供可重用的功能,这些功能将用于实现 C1 的要求属性。
设计人员详细设计了 C11、C12、C13 及其接口。
此时,对设计人员来说,C11、C12 和 C13 是体系结构构造(或组件);其中每个构造具有显式定义的外部接口。
对设计人员来说,C11、C12 和 C13 是软件组件 C1 的体系结构,并且这些构造需要进一步的改进和设计,以处理它们的内部实现。
通过将大型、复杂的系统划分为小型的构成部分并集中于每个部分,可以递归地使用体系结构。
体系结构使用共同满足行为和质量目标的体系结构构建块将系统绑定在一起。
参与者必须能够理解体系结构。
因此必须为体系结构编写足够的文档说明,下一个部分将对此进行讨论。
回页首编写体系结构文档说明的重要性参与者:体系结构的下游设计和实现用户。
为体系结构的定义、维护和增强功能进行投资的人。
向参与者传达您正在构建的系统蓝图的关键是为系统体系结构编写文档说明。
软件架构通过不同的视图进行表示——功能、操作、决策等等。
没有任何单一视图能够表示整个体系结构。
并非所有视图都需要表示特定企业或问题领域的系统体系结构。
架构师将确定足以表示所需软件架构范畴的视图集。
通过编写不同视图的文档说明并捕获每个部分的开发,您可以向开发团队和业务及 IT 参与者传达有关该不断发展的系统的信息。
软件架构具有一组其预期要满足的业务和工程目标。
体系结构的文档说明可以向参与者传达这些目标将如何实现。
为体系结构的各个方面编写文档说明,有助于架构师弥补用白板描述解决方案(使用框线图方法)与以对下游设计和实现团队有意义的方式表示解决方案之间众所周知的差距。
体系结构的框线图留下了大量有待解释的空间。
需要揭示的细节通常隐藏并令人混淆地固守在那些框线背后。
文档说明还可以促进创建切合实际并且可以系统开发(例如遵循标准模板)的体系结构构件。
作为一门学科,软件架构是非常成熟的。
您可以利用最佳实践和指导...
什么是SOA架构图?
SOA的核心主体是服务。
所谓“服务(Service)” ,从业务角度而言,服务是一个可重复的经过标准封装的任务,例如: 检查帐号余额;开新帐户 等等…。
SOA的目标是通过服务的流程化来实现业务的灵活性,所谓流程(Process)是由一系列相互关联的任务所组成,实现一个具体的业务功能。
一个流程可以由一系列服务来实现。
标准架构图如下:一个正确的框架,是指导我们开发和实施SOA架构的基础。
由IBM提案,国际开放群组(The Open Group)提出了一个SOA架构的参考模型,这个架构框架目前是产业界最权威和严谨的SOA架构标准。
The Open Group是一个非营利标准化组织,是一个厂商中立和技术中立的机构,致力于提出各种技术框架和理论结构,致力于促进全球市场的业务效率。
The Open Group已有超过20年的标准制定与推广历史。
在1996年,由X/Open与Open Software Foundation合并组成。
The Open Group最有名是作为UNIX商标的认证机构。
在过去,协会最出名的是其出版的Single UNIX Specification,它扩充了POSIX标准而且是UNIX的官方定义,其成员包括IT用户、供应商以及政府机构。
The Open Group在中国的创始会员为金蝶集团,金蝶集团负责成立了中国分会。
TOG在1993年提出的The Open Group Architecture Framework (TOGAF) 架构框架,是一套行之有效的企业架构。
历经15年9个版本发展,支持开放、标准的SOA参考架构,已被80%的福布斯( Forbes)全球排名前50的公司使用。
根据这个模型,完整的SOA架构由五大部分组成,分别是:基础设施服务、企业服务总线、关键服务组件、开发工具、管理工具等。
SOA基础实施是为整个SOA组件和框架提供一个可靠的运行环境,以及服务组件容器,它的核心组件是应用服务器等基础软件支撑设施,提供运行期完整、可靠的软件支撑。
企业服务总线是指由中间件基础设施产品技术实现的、通过事件驱动和基于XML消息引擎,为SOA提供的软件架构的构造物。
企业服务总线ESB提供可靠消息传输、服务接入、协议转换、数据格式转换、基于内容的路由等功能,屏蔽了服务的物理位置,协议和数据格式。
在SOA基础实现的方案上,应用的业务功能能够被发布、封装和提升(Promote)成为业务服务(Business Service);业务服务的序列可以编排成为BPM的流程,而流程也可以被发布和提升为复合服务(Composited Service),业务服务还可以被外部的SOA系统再次编排和组合。
ESB是实现SOA治理的重要支撑平台,是SOA解决方案的核心,从某种意义上说,如果没有ESB,就不能算作严格意义上的SOA。
关键服务实现,是SOA在各种业务服务组件的分类。
一般来说,一个企业级的SOA架构通常包括:交互服务、流程服务、信息服务、伙伴服务、企业应用服务和接入服务。
这些服务可能是一些服务组件,也可能是企业应用系统(如ERP)所暴露的服务接口等等。
这些服务都可以接入ESB,进行集中统一管理。
开发工具和管理工具:提供完善的、可视化的服务开发和流程编排工具,涵盖服务的设计、开发、配置、部署、监控、重构等完整的SOA项目开发生命周期。
按照这个模型,许多SOA解决方案是只提供部分实现。
这个行业中,许多国内的企业为了搭上SOA的便车,经常以偏概全,混绕概念。
应该说真正按照SOA的思想和模型来构建整个企业的IT架构的案例是非常之少的。
许多国外厂商的宣传案例,基本上是停留在部署应用服务器,开发了部分WebService组件,可以实现部分数据集成,这个层次而已,而这些WebService是部署在ESB平台之上的,就已经很不错了。
实现了服务流程重组,实现SOA治理的案例就更是很少见到了。
OASIS(一个SOA标准组织)给予出的SOA定义“SOA是一个范式,用于组织和利用可能处于不同所有权范围控制下的分布式系统。
”维基百科给出的SOA定义“面向服务的体系结构(Service-oriented architecture)是构造分布式系统的应用程序的方法。
它将应用程序功能作为服务发送给最终用户或者其他服务。
它采用开放标准、与软件资源进行交互并采用表示的标准方式。
”。
要准确全面理解SOA,首先必须理解SOA的核心要素:SOA的目标就是实现灵活可变的IT系统。
要达到灵活性,通过三个途径来解决:标准化封装、复用、松耦合可编排。
互操作(标准化封装)、复用、松耦合等SOA技术的内在机制,也是中间件技术和产品的本质特征。
标准化封装(互操作性)传统软件架构,因为封装的技术和平台依赖性,一直没有彻底解决互操作问题。
互联网前所未有的开放性意味着各节点可能采用不同的组件、平台技术,对技术细节进行了私有化的约束,构件模型和架构没有统一标准,从而导致架构平台自身在组件描述、发布、发现、调用、互操作协议及数据传输等方面呈现出巨大的异构性。
各种不良技术约束的结果是软件系统跨互联网进行交互变得困难重重,最终导致了跨企业/部门的业务集成和重组难以灵活快速的进行。
在软件的互操作方面,传统中间件只是实现了访问互操作,即通过标准化的API实现了同类系统之间的调用互操作,而连接互操作还...
传统的企业数据总线和目前的分布式消息系统有什么区别
有了它,才能释放SOA的最大价值。
因此,ESB成为厂商在SOA(面向服务的架构)竞争中的焦点。
作为近两年软件领域最热门的词汇之一,SOA(Service Oriented Architecture,面向服务的架构)的概念以及SOA带来的好处,正在被用户逐步接受。
Gartner的数据表明,到2007年,全球将有70%以上的大企业会将他们的应用转到SOA。
但是目前CIO们最关心的是,如何才能真正实现基于SOA的应用? 在近一段时期,多家软件厂商如IBM、Sun、BEA、Oracle等都加大了对ESB(Enterprise Service Bus,企业服务总线)产品的投入力度,并声称自己的SOA解决方案因此而更加完善,ESB成为厂商在SOA竞争中的焦点。
ESB成为一种新的诱惑 ESB是传统中间件技术与XML、Web服务等技术结合的产物。
ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。
业内对ESB的定义是:它是由中间件技术实现并支持SOA的一组基础架构,支持异构环境中的服务、消息以及基于事件的交互,并且具有适当的服务级别和可管理性。
这样的定义稍显抽象,简单地说,ESB就是试图将应用服务器上的多种逻辑层面迁移到总线以及连接点上,从而降低企业内部信息共享的成本。
IBM WebSphere软件全球副总裁Sandy Carter女士介绍说,“企业服务总线是SOA中的消息框架-即消息相互交换和通信的方式,是业界标准与客户消息框架的整合。
” ESB产品的共有特性包括:连接异构的MOM(Microsoft Operations Manager)、利用Web服务描述语言接口封装MOM协议,以及在MOM传输层上传送简单对象应用协议(SOAP)传输流的能力。
大多数ESB产品支持在分布式应用之间通过中间层如集成代理实现直接对等沟通。
ESB的出现改变了传统的软件架构,可以提供比传统中间件产品更为廉价的解决方案,同时它还可以消除不同应用之间的技术差异,让不同的应用服务器协调运作,实现了不同服务之间的通信与整合。
从功能上看,ESB提供了事件驱动和文档导向的处理模式,以及分布式的运行管理机制,它支持基于内容的路由和过滤,具备了复杂数据的传输能力,并可以提供一系列的标准接口。
在电信领域:ESB能够在全方位支持电信行业OSS(运营支撑系统)的应用整合概念,是理想的电信级应用软件承载平台。
在电力领域:ESB能够全方位支持电力行业EMS的数据整合概念,是理想的系统数据交换平台。
在金融领域:ESB能够在全方位支持银企间业务处理平台的流程整合概念,是理想的B2B交易支撑平台。
为SOA挑起大旗 对于SOA的概念,不同的软件提供商有不同的定义方式。
很多用户也都是从不同的视角来理解SOA,从程序员的角度,SOA是一种全新的开发技术,新的组件模型,比如说Web Service;从架构设计师的角度,SOA就是一种新的设计模式,方法学;从业务分析人员的角度,SOA就是基于标准的业务应用服务。
SOA不仅是Web服务,如何让业务服务最大限度地复用才是SOA的核心价值。
ESB为分散服务提供了交互、组合和治理的基础架构。
有了它,才能释放SOA的最大价值。
我们可以这样来理解,ESB就是在SOA架构中实现服务间智能化集成与管理的中介。
而它与SOA的关系是:ESB是逻辑上与SOA所遵循的基本原则保持一致的服务集成基础架构,它提供了服务管理的方法和在分布式异构环境中进行服务交互的功能。
可以这样说,ESB是特定环境下(SOA架构中)实施EAI(enterprise application integration,企业应用集成)的方式。
IONA公司大中国区总裁薛志勇表示,采用IONA公司的ESB产品Artix作为SOA的切入点,将可以使企业以最小的投入将已有系统纳入SOA架构。
薛志勇称,目前ESB是SOA集成中最普遍采用的方法,传统的EAI和平台厂商是以“服务器”为中心、以“Hub”为形式的解决方案,这种方法虽然解决了信息孤岛问题,但投资大,见效慢,而且也不灵活。
因为ESB是传统中间件技术与XML、Web服务等技术结合的产物,对企业而言,采用ESB中间件系统作为企业级信息系统整合方案中的中枢技术,可以无须添加任何软硬件设备,就可把过去、现有和未来的IT系统整合在企业级的信息应用框架下,并且能为企业提供实时、大容量的信息通信和实时控制、管理和分配消息传递的能力。
目前,除了IONA、Tibco等专业的ESB公司外,SOA的两大领导厂商IBM和BEA也加入了ESB的阵营。
Forrester公司分析师Mike Gilpin说:“尽管人们还不十分确定如何构建出一个完整的SOA,但他们已经知道要解决集成问题,而ESB正好能帮助他们解决该问题。
” 国内CIO对SOA早已听了很多。
SOA的理念和他们所面临诸多挑战,SOA 的开放性和灵活性,给了CIO一个选择它的理由。
然而,不菲的平台迁移成本以及缺少成功案例的佐证,都让CIO难下决心。
CIO不但要考虑必须对现有产品进行集成以支持SOA的使用场景。
还必须考虑如何构建面向未来的SOA应用。
ESB的出现和应用恰好为这个难题提供了一个解决之道。
甲骨文公司在去年将ESB产品内嵌在其业务流程管理产品中,今年就推出了独立的ESB产品。
BEA推出了 AquaLogic ...
软件架构的视图
我们决定以多种构架视图来表示软件构架。
每种构架视图针对于开发流程中的涉众(例如最终用户、设计人员、管理人员、系统工程师、维护人员等)所关注的特定方面。
构架视图显示了软件构架如何分解为构件,以及构件如何由连接器连接来产生有用的形式 [PW92],由此记录主要的结构设计决策。
这些设计决策必须基于需求以及功能、补充和其他方面的约束。
而这些决策又会在较低层次上为需求和将来的设计决策施加进一步的约束。
构架由许多不同的构架视图来表示,这些视图本质上是以图形方式来摘要说明“在构架方面具有重要意义”的模型元素。
在 Rational Unified Process 中,您将从一个典型的视图集开始,该视图集称为“4+1 视图模型”[KRU95]。
它包括:用例视图:包括用例和场景,这些用例和场景包括在构架方面具有重要意义的行为、类或技术风险。
它是用例模型的子集。
逻辑视图:包括最重要的设计类、从这些设计类到包和子系统的组织形式,以及从这些包和子系统到层的组织形式。
它还包括一些用例实现。
它是设计模型的子集。
实施视图:包括实施模型及其从模块到包和层的组织形式的概览。
同时还描述了将逻辑视图中的包和类向实施视图中的包和模块分配的情况。
它是实施模型的子集。
进程视图:包括所涉及任务(进程和线程)的描述,它们的交互和配置,以及将设计对象和类向任务的分配情况。
只有在系统具有很高程度的并行时,才需要该视图。
在 Rational Unified Process 中,它是设计模型的子集。
配置视图:包括对最典型的平台配置的各种物理节点的描述以及将任务(来自进程视图)向物理节点分配的情况。
只有在分布式系统中才需要该视图。
它是部署模型的一个子集。
构架视图记录在软件构架文档中。
您可以构建其他视图来表达需要特别关注的不同方面:用户界面视图、安全视图、数据视图等等。
对于简单系统,可以省略 4+1 视图模型中的一些视图。
常见的软件架构有B/S架构和C/S架构,我想问问,我们常用的哪些软...
B是浏览器,S是服务端,C是客户端。
简单讲B/S架构用户侧是使用浏览器获得服务;C/S架构用户侧需要先安装相应的软件,如手机上的各种APP、电脑上的qq等都是C/S架构。
据说,B/S架构是未来趋势,因为通用性强啊,不用像C/S架构还得windows、安卓、IOS各开发一款软件。
什么是系统架构设计?
展开全部 不同的架构方法论,会将架构分为不同视图,每个视图侧重某一个方面、领域的问题。
比如希赛推的ADMEMS架构体系,分为以下几种视图: 1. 数据架构:描述数据的存储结构、格式等方面。
2. 物理架构:描述机器的物理部署、网络拓扑方面。
3. 运行架构:描述运行期线程、进程间的交互工作机制。
4. 逻辑架构:指如何将代码分成不同模块、组件,以及之间的职责分配、交互行为。
5. 开发架构:主要指开发工具的选择,程序单元的划分,开发管理规范流程等方面。
例如分为哪些工程、项目,源代码管理,自动化编译构建、测试、部署等。
目前国际上运用比较广泛的是TOGAF架构体系,他把架构分为业务架构、数据架构、应用架构、技术架构等几个方面。
想详细的了解这些架构视图,可以参考这些架构体系相关的书、资料。
另外有很多人无缘无故的抨击架构概念,不知道是出于调侃还是无知。
埃及的金字塔、神庙的建设,不是几个平常的泥瓦匠聚在一起就能够造出来的。
像SAP、Oracle ERP,国内的金蝶等大规模的系统,以及空间站、火箭的控制系统等,没有系统性的架构方法、规范、流程,结果只能是悲剧。
当规模、复杂度没有达到一定程度,比如在一些小的团队、产品中,架构过程可能融入到老板、经理、组长、资历较深的一些开发者中,融入在大家的日常工作中,以至于感觉不到架构的存在。
就算遇到一些问题,因规模不大、复杂度不高,也比较容易调整。
当这些前提条件发生变化时,架构的作用和必要性就逐步的体现出来。
总的来说,一说到架构,如果懂软件,那么会了解为一个软件系统,这个软件设计的组成结构,如哪些是基础支持组件,哪些是完成A业务,哪些完成B业务……但说道企业架构的时候,就会问,该企业架构的几个架构如业务架构、数据架构、业务架构、技术架构,以及如何链接在一起。
倒觉得,一个企业确实需要这样的架构,但不要神话它,最主要的是业务如何最终体现到软件中和流程中。
而采取分离式设计时,最容易的错误就是各自为政,集成困难。
那么以数据为中心的架构设计,会自然提供集成的基础。
提到过,企业最重要的资产是数据,甚至不是信息,是数据。
企业的业务流程会变,IT系统会变,所需要的信息与知识会变,唯有数据能够积淀下来。
这有点象自然演进,考古那种,啥都...
熟悉的Android社交软件的架构是什么样的
必须是谷歌android现在诺基亚对于系统发愁呢,眼看着份额的下降。
谷歌和许多可以改进的空间,明年肯定是android的世界。
诺基亚跃升到很多人会发现,谷歌的系统真的比塞班得多。
但在比塞班Android的复杂的复杂性,不折腾手机采用Symbian肯定合适,点击看详细六大手机企业进入Android(安卓)是谷歌系统。
国内外厂商和运营商也纷纷加入Android阵营,包括MOTO,中国移动,中国联通,华为通讯,联想,HTC,三星,谷歌,T-Mobile德国公司等,只有NOKIA持有。
在应用程序,苹果是领先的,但谷歌将超过苹果公司在不久的将来。
Symbian应用程序有很多,但没有苹果的人性化。
微软WM则主要是为了拿手机的人使用的办公室,但现在不建议这个时候WM,因为W7马上就出去了,现在基本上无法升级。