关于WCF、WebAPI、WebService之间的区别总结 分布式通信技术(Distributed Communication Technologies)浅析

关于WCF、WebAPI、WebService之间的区别总结
分布式通信技术(Distributed Communication Technologies)浅析

早在1996年Gartner就前瞻性地提出了面向服务架构的思想(SOA),SOA 的走红在很大程度上归功于 Web Service 标准的成熟和应用的普及。 Service Oriented Ambiguity 中文一般理解为:面向服务架构,简称SOA,这个概念算得上微服务的鼻祖了。 SOA 的提出是在企业计算领域,就是要将紧耦合的系统,划分为面向业务的、粗粒度、松耦合、无状态的服务。服务发布出来供其他服务调用,一组互相依赖的服务就构成了SOA架构下的系统。 SOA 本质上是服务的集合。 在分布式通信技术选型中,就本人曾经使用过的基于微软平台的分布式通信进行概述,先明确一下分布式框架的三个基本需求:
  • 客户端: Web、Android、IOS、跨平台(Java 开发的系统和.NET 开发的系统可以通信)
  • 服务端:部署在Windows、Linux
  • 合约(Contract):传递的格式(REST,Json、SOAP、XML)、通信协议(HTTP、XML-RPC、TCP)、消息超时设置、消息包大小
要打造分布式平台,各家技术栈多有不错的实践,这里重点说一下微软技术栈下,丰富的技术选型:
  • .NET Remoting (15年前技术,目前已经失传)
  • Web Service (ASMX, ASP .NET Web Services,15年前技术,维护项目依然存在)
  • WCF (Windows Communication Foundation,10年前技术,维护项目中比较多)
  • Web API (5年前技术开始火起来,和跨平台需求密不可分,最近3年的新需求大部分迁移在这里了)
下面展开来说:

.NET Remoting

是2.0时代的产物, 即2004年的技术,我还没有机会实战过。在微软Roadmap中已被WCF取代(.NET Remoting做得到的事,理论上WCF都可以实现) 依据微软一份,WCF在效能上比ASP.NET Web Service快了25%-50%,比.NETRemoting快25%,弃.NET Remoting改用WCF将有性能能上的突破。 详见报告链接

Web Service

在很早前开发WebForm ASP.NET中用的比较多,因此可以将 Web Service 理解为一个基于 HTTP 协议开发的上层应用程序 Web service 是一个平台独立的,低耦合的,自包含的、基于可编程的 Web 的应用程序,可使用开放的 XML(标准通用标记语言下的一个子集)标准来描述、发布、发现、协调和配置这些应用程序,用于开发分布式的互操作的应用程序。 Simple Object Access Protocol,中文为简单对象访问协议,简称 SOAP。
1、它是基于SOAP协议的,数据格式是XML (SOAP )

2、只支持HTTP协议

3、它不是开源的,但可以被任意一个了解XML的人使用

4、它只能部署在IIS上 

SOA 不是 Web Service,Web Service 是当年最适合实现SOA的技术。

WCF

WCF是取代Web Service及.NET Remoting的接班人,我记得这个是微软2010年开始力推的技术。 我第一次是用WCF是2012年,做一个电信级项目,结合微软吹水的Silverlight技术(Silverlight技术,2013年底该技术被微软安乐死了,again!)
1、这个也是基于SOAP的,数据格式是XML

2、这个是Web Service(ASMX)的进化版,可以支持各种各样的协议,像TCP,HTTP,HTTPS,Named Pipes, MSMQ.

3、WCF的主要问题是,它配置起来特别的繁琐!!! (此处特别强调了3个感叹号 )

4、它不是开源的,但可以被任意一个了解XML的人使用

5、它可以部署应用程序中或者IIS上或者Windows服务中

WCF门槛有些太高,仅仅在Windows平台开发,而且配置文件比较复杂(WCF 客户端\WCF 服务器端,仅Binding、Behavior的复杂度就能单独写一篇文章,踩过不少坑,都是泪。) 众所周知,微软.net技术未来是.netCore,成熟的.NetCore3 2019年底就可以应用于生产系统了, 但多年来微软一直拒绝将WCF 的服务器端移植到.NET Core, 导致这个分布式技术,面临的极大的技术瓶颈,即若干年后几无可用人才来维护WCF项目,所以大约3年前开始,我知道周围朋友公司的新项目大都避而不谈WCF了。

ASP.NET Web API

随着SOAP 逐渐淡出,RESTful大行其道, Web API火了起来。 微软技术栈的工程实现是 ASP.NET Web API,而且微软建议使用 ASP.NET Core Web API 或 gRPC,它们提供基于跨平台和跨编程语言的 RPC,也能使用 gRPC 来编写代码,并替换掉一些 WCF 服务器服务。
1、一个简单的构建HTTP服务的新框架

2、在.net平台上Web API 是一个开源的、理想的、构建REST-ful 服务的技术

3、不像WCF REST Service.它可以使用HTTP的全部特点(比如URIs、request/response头,缓存,版本控制,多种内容格式)

4、它也支持MVC的特征,像路由、控制器、action、filter、模型绑定、控制反转(IOC)或依赖注入(DI),单元测试。这些可以使程序更简单、更健壮

5、它可以部署在应用程序和IIS上

6、这是一个轻量级的框架,并且对限制带宽的设备,比如智能手机等支持的很好

7、Response可以被Web API的MediaTypeFormatter转换成Json、XML 或者任何你想转换的格式。

WCF 的未来是Web API,而且微软2014年推出开源.NetCore中就有ASP.Net Core Web API,可见重视程度。

分布式技术这么多,我该选谁?

都2019年了,新项目肯定是WebAPI,原因如下:
WebAPI只要有能力发送HTTP Request跟解析JSON,比较符合微服务要求, 跨平台支持。

创建一个基于HTTP的面向资源的服务并且可以使用HTTP的全部特征时(比如URIs、request/response头,缓存,版本控制,多种内容格式),你应该选择WebAPI

让你的服务用于浏览器、手机、iPhone和平板电脑时,你应该选择Web API

双工消息模式,过SignalR和WebSockets整合(创建一个支持消息、消息队列、双工通信的服务时)

微软.Net Core 3.0 预览版 7 发布:大幅减少 SDK 空间大小

这个预览版是 .Net Core 3 中重要的版本,可以视为原计划在 7 月发布的 RC 版本 (引自微软 .NET Core 首席 Program Manager Richard 先生原话),故可在生产环境进行开发和部署。

据悉,这个预览版是 .Net Core 3 中重要的版本,可以视为原计划在 7 月发布的 RC 版本 (引自微软 .NET Core 首席 Program Manager Richard 先生原话),故可在生产环境进行开发和部署。 Windows, macOS 和 Linux 版本的Download .NET Core 3.0 预览版 7 下载地址如下: 与此同时,ASP.NET Core 和EF Core 实体框架 也同于同一天发布。 针对 .NET Core 3.0 预览版 7 的新特性,Visual Studio 用户需要在 Visual Studio 2019 16.3 预览 1 中使用。 Microsoft .NET 站点已更新为.NET Core 3.0 预览版 7(请参阅网站页脚中提示 Powered by .NET Core 3.0.0-preview7-27912-14)。 且该站点已经在预览 7 上正常运行了两周多。 微软声称可能会在几周内将 Microsoft .NET 网站迁移到.NET Core 3.0 预览 8 版本。 另外,开发团队正在努力确保与 .NET Core 1.x 和 2.x 应用程序的高度兼容性,从而可以直接将现有应用程序快速升级到 .NET Core 3.0 版本。

.NET Core SDK 大小精简

使用 .NET Core 3.0 的 .NET Core SDK 要小得多。 主要原因是改变了构建 SDK 的方式改变,转而使用各种特定的“包”(引用程序集,框架,模板)。 在以前的版本(包括 .NET Core 2.2)中,我们使用 NuGet 包构建了 SDK,其中包含许多不需要的引用,导致浪费了大量空间。 您可以在.NET Core 3.0 SDK Size Improvements如何计算这些文件大小。 文章提供了详细说明,以便在自己的环境中运行相同的测试。 .NET Core 3.0 SDK 大小(括号中标注了大小更改)
操作系统 安装包大小 占用磁盘大小
Windows 164MB (-440KB; 0%) 441MB (-968MB; -68.7%)
Linux 115MB (-55MB; -32%) 332MB (-1068MB; -76.2%)
macOS 118MB (-51MB; -30%) 337MB (-1063MB; -75.9%)
Linux 和 macOS 的大小改进是令人惊奇的。 Windows 的改进较小,因为我们已将 WPF 和 Windows Forms 添加作为 .NET Core 3.0 的一部分。 令人惊讶的是,我们在 3.0 中添加了 WPF 和 Windows Forms,并且安装程序仍然(稍微)小一些。 您可以通过.NET Core SDK Docker映像包看到改进也不错(此处仅限于 x64 Debian 和 Alpine)。
发行版 2.2 压缩大小 3.0 压缩大小
Debian 598MB 264MB
Alpine 493MB 148MB
.NET Core 3.0 版本即将完成,故不再构建新功能,因此团队专注于稳定性和可靠性。 请尽快通过 Github 告诉开发团队您发现的任何问题,这样在发布 3.0 版本之前尽可能多地修复问题。

风生水起:我用过的IM工具

p>    不同的企业,有不同的文化,也有不同的沟通方式。

  1. QQ: 2000年开始使用,95%的联系人是见过面的人(约10%是同事)clip_image002  风生水起:我用过的IM工具 clip image002 thumb 中国最火的IM,没有之一,据说用户数超过7亿。尤以其QQ群、QQ空间、QQ微博、QQ游戏等一系列附加值著称。QQ的模式,在 IT业内算是一个标杆: 主业务不挣钱,大把大把的投入资源;而附属业务则实现了火箭般增长。据说QQ公司内的创新文化是3~5个人,2个月的DIY小项目,可获公司层立项,从而快速出demo,抢占市场。正是因为这样灵活的研发策略,使得QQ这个小企鹅10年来,依旧强健无比。
  2. MSN:2005年开始使用,90%的联系人是同事。clip_image004  风生水起:我用过的IM工具 clip image004 thumb 当年,可以说MSN属于北、上、广;外企的“标配”。“高端、大气、上档次”,其登录的立体小人非常cool,登录过程还要360度转几圈。MSN辉煌的时代,真实微软在IT业内独占鳌头的时代,一家独秀。然,微软2012年宣布,2013.4月使得MSN安乐死了—微软为了力挺其12亿美金收购的SkyPe权威地位。 故MSN目前只能算是一个历史记忆了。
  3. Skype:2007年开始使用, 联系人很少( 2012年底从MSN倒过去了几十个)   clip_image006  风生水起:我用过的IM工具 clip image006 thumb   刚开始使用的时候,它还没有被微软收购。其有2个优点:语音聊天、拨打电话。Skype目前是微软旗下的王牌IM,为了它的市场布局,微软自宫了MSN,不过,目前不太火。 其未来发展得看Win 8.1和WP 8.1市场的推进。
  4. 飞信:2007年开始使用,90 %的联系人是同事 (移动电信行业IM标配)。clip_image008  风生水起:我用过的IM工具 clip image008 thumb 刚开始是因为能够免费发短信(移动手机注册),这个功能非常让人兴奋。 再后来,因为做的项目是移动的,故同事、客户90%以上选择了飞信用来沟通。故,飞信对我而言,属于每天必用的软件(2009年到2013年)。
  5. GTalk:2008年开始使用,日常的联系人约10人(截止2012年底)。clip_image010  风生水起:我用过的IM工具 clip image010 thumb最近几年年,GTalk火了起来,可能是随着Google Android系统的内置Gtalk吧。但从用户体验上看,它比飞信、MSN、QQ要“差”–至少登录UI掉渣级的土;传文件、传图片等常用功能也不尽如人意。 

但随着时间推进,我发现Gtalk好像还有一些优点:

  1. 聊天记录:因为“三屏一云”后,多个终端通过GTalk聊天,能够浏览完整的聊天记录,且不用付费,这,确实很爽。而同样功能QQ是要收费的。
  2. Google Group:接触邮件组,是在2006年,那个时候公司内部好像还很流行。但是随着组织的急剧扩张,导致出现内、外部大量的群发邮件。后来公司某个政策出台,解散了邮件组这种形式。那个时候的印象是:邮件组很土。   而随着最近2年西安软件园的一些活动,我订阅了3个邮件组,发现这个玩意有它的优点:免费保存记录,熟人圈子等。
  3. Gmail邮箱:使用Gtalk的,一般都有对应账号的Gmail邮箱。这个功能确实比较酷,IM和邮箱实现了彼此的互补。 如,IM实现短、平、快;邮件辅助实现:长、博、稳。
  4. 日历提醒: 整合了时间管理的元素。如预定会议,某某重要的事情提醒等等。

总结:上述的5个IM工具,没有绝对的好坏、黑白之分。 相反,同质化好像日趋明显了。 如,凡是其他IM有的功能,QQ未来也会有。仅从中国市场看,QQ的生态圈子最好的,其市场很强:小马哥通过它美美的挣了很多钱!

Silverlight 点点滴滴

p>SL, RIA,即不仅仅是普通的层三架构的web系统。SL前台呈现,调用后端查询数据库传递,更多的东西可在前端,如浏览器实现更多的动作,xap包都下载到本地了,用户会默认安装SilverLight runtime,近似CRL的东西。

一个基于Silverlight的model至少由3个部分构成:

前段,一个SilverLight工程,生成xap包,

通信,一个WCF工程,生成dll

后端,一个class Library,生成dll

为了启动1个这样的model,你需要有一个web host(宿主程序),即asp.net web应用程序,他会生成对应的一个silverlight的defaul.asps文件, 部署在IIS上后,用户点击Http://192.168.1.1/SL_demo则打开的这个defaul.asps,故而第一次,用户通过IE浏览器,把你的SilverLight xap下载本地,启动了SL页面。

对于企业应用级别的SL借鉴方案,一般有10几个开发人员在做model,怎么把这些model组织为web site的菜单项,可以实现不同的region区域:固定展示log的region,展示当前用户信息的region,展示导航树的region,展示主工作区间的region。

需要采用插件架构,如Prism简介, 详细的可看这一系列blog:

*****************

  • MVVM:binding everything 一种新的思维,数据和UI交互的新思维。 MVVM  Silverlight 点点滴滴 MVVM thumb
  • 页面代码分离:asp.net思路。 xaml+xaml.cs文件组成前台用户看到的内容。 Xaml里面写页面元素,如Grid、textBox, cs里面写具体逻辑代码(实际上,如果完全通过上面的MVVM实现逻辑,则这个cs文件里面写的代码少得很)
  •       其项目编译后对应为xap文件(zip压缩文件,方便用户网络下载)

  • 前端,只能引用添加Silverlight项目、WCF引用,必须引用SilverLight类库(当添加非SL的,则Visual Stuido会报错提示)。
  • UI组件采用的是成熟的Telerik,主要用了其GridView、TreeView、Chart、RickTextBox、RadButton等。
  • 后端,普通的class Library项目即可,同以往的.net应用程序没有任何区别。
  •   WCF: 前段和后端通信的桥梁,写一个专门的WCF工程(位于后端),可直接调用后端的Class Library。 前段和后端通信,就靠这个了:前段传递数据给后端, 后端返回数据给前段。

  • 前后台怎么复用代码方法:
  •       通过添加WCF引用,会自动生成Entity的代码,在reference.cs文件里面

    通过链接类、条件编译方式,可以实现前、后端代码级别复用,这种办法,效率非常高。

  • 几个现金陷阱:

陷阱一:泛型传递

泛型是在编译器确定了数据类型,而WCF仅仅是XML封装的接口,如果发布了一个T的接口,那么使用者使用,谁编译WCF接口? 怎么编译WCF? 所以,不行的。

陷阱二:object传递: 基类、子类传递。参见上面说的基本类型,如果一个数据的calss,没有添加标签封装,WCF会报错的。

陷阱三:DataTable传递

典型的ADO.net思想,还停留在windows桌面应用系统领域, JSON、byte[]才是WCFSL的王道。

主要因为,你引用DataTable的System.Data类库,在前段不可见(前段相对后端裁剪了很多,更轻巧)。 如果你实在要这么做,推荐一个开源的SL.DataTalbe给你,需要源码的发邮件给我。

如果数据流大,可通过byte[]方式通信,在后端序列化为byte[],WCF传递给前段,(上篇写过,前段可通过链接类、条件编译复用后端代码:类变量、类方法), 前段可反序列化为实体类。

在多年单机版思路,几年前转换为Client-Server开发思路模式。 最近的2年往Brower-Server开发模式转变,同时也兼顾Windows Phone移动端思路吧。

[译] 开发者角度,王道之论:Android 与 Windows Phone

前几天,在codeproject搜索Silverlight资料,偶然看到这篇文章,耐心读了2遍,非常不错:文章通过访谈聊天形式叙述,2位主角目前在《斯法克斯国家工程学院》软件学院上学。

周五晚上,我给作者Houssem Dellai发gmail,咨询能否授权我翻译为中文,并发布。 3个小时后,他很爽快的回邮件说没有问题,给我一个原文链接就行。

英文原文地址: Android vs Windows Phone

———————————————————————————————————————————

作者目前在突尼斯,属于非洲北部一个小国家,人口1000万左右,约西安市人口的规模。

自我介绍

大家好,我是Houssem Dellai: 一名Windows Phone 开发者(译:他曾多次参加突尼斯Windows Phone编程挑战赛并屡屡获奖,且已获得微软Windows 8认证)。我身边的这位是我的同学Zied Jaballah: 他是Android 开发者 (译: 他已有3年Android开发经验).

我们一起曾在droidcon conference in tunis中做了一个session分享:从开发者的视角分别就Android和Windows Phone移动终端开发平台的几个方面问答。

Android和Windows Phone PK:

首先,我们通过应用商店,即一个移动终端开发者如何挣钱这个话题展开讨论;紧接着又讨论了手机终端支持情况。 然后,对IDE集成开发环境进行了分析: Visual Studio和Eclipse. 再然后,讨论了开发者最关注的模拟器。最后,我们又讨论了Google和微软对UI设计的规范要求。 结尾部分,又聊了一下平板电脑的话题。

1 – 应用商店

Houssem: 首先,让我们从应用商店开始讨论吧,看看Google为开发者做了些什么?

Zied: Google的应用商店叫 Google Play, 目前包含了近百万的app应用, 全球下载次数超过250亿次以上。那么,Houssem, 微软应用商店的情况如何?

Houssem: Windows Phone 应用商店目前有超过13万应用app. 虽然在数量远远不如Android商店的庞大, 但是,你可以找到你需要的所有应用app程序。

Zied: 开发者如要在google商店发布Android应用, 首先需要拥有一个 Google Play账号,申请注册费用为25刀。 那么,开发者申请一个微软的商店账号,需要多少钱?

Houssem: 在微软商店发布应用,有2类不同账号:开发者账号,需要49刀;还有一个是企业账号,需要99刀的费用。

Zied: 为了在Googe Play商店发布你的应用,你必须要通过Google的验证审核,这个过程很快,大约需要15到30分钟。 那么, 微软的应用审核策略呢?

Houssem: 微软商店的审核大约需要5天时间。 如果你的app被拒绝,你同样会受到一个审核错误报告,微软会告之你如何改进。 Zied! 我注意到你的PPT中提到了’恶意软件’ ?!!

Zied: 是的, 这不是笔误。Google play商店良莠不齐,有很多恶意软件, 这个可能是因为审核过程过快,且 Android开发者群体数量庞大导致的。 事实上,google已经认识到这个问题的严重性,并且出了一个新政策,它参考了微软和苹果的做法,即通过应用的使用反馈情况来代替审核制度,如:Google允许你发布你的应用app, 然后它会扫描app是否属于恶意软件。 在今年2月,Google创记录的从应用商店下架了6万款应用程序。

Houssem: 感谢上帝,在Windows Phone商店,你不会受到恶意软件侵扰,她值得信赖。

2 – 手机终端

Zied: Ok, 我们现在讨论手机终端吧。你知道Android阵营拥有数量庞大的终端吗? 这些是为数众多的手机厂商生产的,如我们耳熟能详的三星、LG、摩托罗拉等。(译:还包括HTC和华为、中兴) 这些手机终端,纵横了低端、中端、高端市场的不同的用户需求。那么Windows Phone手机的情况如何?

Houssem: 拥抱Windows Phone的手机厂商有诺基亚、三星、HTC、LG等等(译:还包括华为、中兴)。微软出于想给消费者以最佳体验品质,故对硬件比较挑剔, 所以,目前市场上的终端的售价都较高。

3 – 集成开发环境(IDE)

Houssem: 截止现在,我们讨论应用商店和手机终端, 下面接着讨论一下集成开发环境(IDE)吧。为了开发Windows Phone 8程序,你需要安装Visual Studio 2012,如免费的Express版。 那么Zied, 谈谈Eclipse吧?

Zied: Eclipse是Android程序员使用最多的IDE,免费且开源。呵呵,最重要的是,它没有太多的需求。( Zied望着Houssem乐了一下 :P ).

Houssem: 对于要通过VS 2012来开发WP8应用程序,确实对运行环境比较挑剔,或者说稍微有点困难吧。如,VS 2012要求操作系统和硬件必须达到最低配置:硬件需要支持能够安装虚拟环境; 操作系统的要求是Win 8 专业版或者企业版,Basic版本不支持,更重要的是,要求Win8操作系统是64位的。

Zied: 那么对你来说,能够满足WP8开发的必备条件, 你算是很幸运了。 但是, 对于Eclipse 来说,则更幸运:压根就不挑剔操作系统和硬件环境。 如,你只需要安装JVM虚拟机即可。事实上,只要能够安装JVM虚拟机,程序员可以在Windows、Mac、Linux等任何操作系统下用Eclipse开发Android应用程序。

Houssem: 众所周知,Visual Studio给程序员非常爽的体验,如:调试源码很容易、高效的编程能力、定位错方便误、修复问题非常快等等优势。

Zied: Houssem,在调试源码这一点上你获胜了, Visual Studio的的确确在调试上把Eclipse远远甩在后面。 但是,我更喜欢Ecipse数量众多的插件,通过这些插件的配合,你可以做得更出色。那么,VS有插件吗?

Houssem: 插件,Visual Studio当然有啦! VS也有大量的插件,且这些插件大部分开源。 你可以通过VS来搜索不同的插件,安装或升级来扩展Visual Studio的IDE。

4 – 模拟器

Houssem: Ok, 我们接着讨论下一个开发者关注的话题:模拟器.

Zied: Android 模拟器运行的不够快,我周围的很多开发者都饱受其害。但是,Google 对一些新机器,通过类似快照技术加速,目前看效果还不错。 如,这里还有一个模拟器开源项目Android x80, 其运行效率非常高,或许是Google模拟器的可选方案之一吧。让我们看看,微软为开发者在模拟器方面做了些什么?

Houssem: Windows Phone 模拟器运行效率非常高。她采用了hyper-v作为虚拟化环境,所以响应很及时。

5 – UI设计

Zied: Ok, 对比WP8的模拟器,Android确实显得力不从心。那么,微软的UI设计方面的支持情况如何呢?

Houssem: 呵呵, 我很欣赏你的坦率。Windows8采用了一种叫做现代UI设计的新的图形风格。它基于“内容胜过形式”的思路,这也意味着,编程开发者只需要把心思放在编码逻辑上,而不用太多注意主题、颜色、外形等。 这种UI设计有其严格的设计规范,但也有一些可复用的模板和控件,故UI可以被做的很漂亮。 如,作为WP8的程序员或者美工,你将会通过微软的expression Blend设计工具的做出最佳视觉效果。 Blend是一个IDE,专门为美工而生,即美工不用安装VS 这种程序员专属的IDE。 当程序员熟悉这些规则后,他将在一开始的时候不用美工。等程序demo成型后,在考虑美工介入提升UI设计、美化等。

Zied: 在Android这一侧,设计是程序员较头痛的一件事情。 你不得不写大量的XML去调整UI,拖拽的方式调试UI元素效果往往不好。 但是,一旦你精通XML的设计模式,则会爽翻天。Google也有自己的设计规范,只是没有微软这么严格罢了。

截止目前,我们讨论应用商店、IDE、设计规范、手机终端。 下面讨论一下平台电脑情况吧。

6 – 平板电脑

Houssem: Windows tablet平台没有运行WP的操作系统,它运行的是Windows RT,这是一种轻量级的Windows 8操作系统,专为平板电脑设计: 不能运行.exe程序, 仅只能运行Windows商店里面应用程序。但是,另外一种叫做Surface Pro平板可以运行
windows 8操作系统和.exe程序。

我猜测WP8有80%的API和Windows8 API相同。故,你可以很容易的在WP8和Windows 8之间共享代码。

Zied: Android操作系统不仅可运行在手机终端,也可以运行在平板电脑。从Android 3.0开始, Google新增了专门为大尺寸屏幕设计的API,故你可以开发专门适用于平板电脑的应用。其平板应用程序使用起来效果非常好。

总结

一般而言,这种讨论无法一决雌雄。某些方面,Windows Phone占据优势, 另外一方面说,Android获得胜利。至于谁是王者,这取决于你选择采用哪个平台,选择权在你。