谈谈移动客户端技术选型

By 罗潇@英雄互娱

移动设备的发展

随着移动互联网的发展，手机,手环,手表,移动电源,移动wifi等各式各样的移动设备不断地被量产并应用到生活。移动设备的数量已经远远超过地球上的人口数量。这些移动设备在生活中给予了我们许多便利，它们的作用已经延伸到生活的各个方面，如通讯，购物，支付，出行，医药，生物，农业，旅游，健康等等。

以手机为代表的移动通讯设备发展最为迅速，出现了很多优秀的个例，各手机厂商之间的战役也拼得非常血腥。也发生了很多新设备取代旧设备的行业故事。从Nokia、摩托罗拉的落幕到HTC、三星的崛起，再到HTC的落幕，苹果的崛起，太多的故事让人记忆深刻。公认第一的苹果手机的故事告诉我们，移动设备的发展是变化多端的，体验和创新才是唯一不败的原因，任何弱体验，弱创新的产品终会被用户所舍弃。

国产手机的发展故事也层出不穷。有刚开始走形似Iphone路线的魅族。有以MIUI社区为策略，专长互联网营销而成功崛起的小米。有工艺设计情怀派的锤子。也有走实路线的华为。甚至各大互联网公司都伸足手机制造领域，比如360的奇酷手机，阿里云手机。大家都看好移动设备这个天然的大入口, 想通过其获取海量用户从而为各自的互联网生态系统提供用户基石。然而，到今天我们发现小米销量下滑，魅族跌出第一阵营，奇酷落幕都已成为不争的事实，反而以产品性能为基础，用户体验为主导的华为,OPPO,VIVO等国产品牌却越来越为人们所接受。国产品牌崛起的事实告诉我们，移动设备的发展需要在技术和产品上不断地沉淀和创新，才能使自己立足于市场。

移动客户端的定义

移动客户端，顾明思议，就是在移动设备上运行的客户端软件，也可以称为移动应用或移动APP。本文我们仅讨论以手机为代表的移动设备，所以我们这里狭义地定义移动客户端是指可以在手机终端运行的软件。它是移动互联网行业发展的一个核心，具有极其重要的意义。尤其到了智能机时代，手机客户端软件带来的产业发展极其迅猛，它已逐步成为各互联网公司占领移动互联网的第一入口，为企业发展用户，推广产品开辟了一条康庄大道。

移动客户端是运行于移动操作系统之上的软件。而移动操作系统的发展也经历了重大变化。从功能机时代的嵌入式系统到智能机时代的手机OS，目前市面上比较流行的手机OS主要为三大阵型: Google的Android, Apple的IOS, Microsoft的Windows Mobile。因此，我们接下来会重点围绕基于这三大阵营的操作系统上的移动客应用来展开讨论。

移动客户端为企业开辟了全新的产品推广手段，移动客户端通过软件技术把公司的产品和服务安装于用户的手机上，相当于把公司的名片、宣传册、服务、产品等一次派发给用户，有些服务甚至可以在手机上直接使用，而且用户还会主动的保留他们的应用。这个过程的成本都是比较低的，用户使用次数也不受限制，并且最便捷地宣传了企业的产品，提供了企业的服务，只要产品服务好，用户还能主动帮其分享传播，相当于免费为企业做了推广。所以，现在绝大多数互联网企业甚至是传统企业都会把自己的产品介绍，或者服务放到移动端供用户直接查阅或使用。

移动操作系统的发展

随着移动互联网的发展，移动设备从功能机到智能机，移动客户端的软件技术也发生了极大的变化。从功能机时代的嵌入式应用、kjava应用到智能机时代的移动App、h5应用。开发语言也发生了很大的变化，从之前嵌入式时代的C, C++到现在Android用的Java, IOS用的Object-C(Swift), Windows Mobile/Phone用的C#。

Android操作系统是一个由谷歌Google和开放手持设备联盟共同开发发展的移动设备操作系统，其最早的一个版本Android 1.0 Beta发布于2007年11月5日，至今已经发布了多个更新。从2009年5月开始，Android操作系统改用甜点来作为版本代号，这些版本按照从C大写字母开始的顺序来进行命名：纸杯蛋糕（Cupcake）、甜甜圈（Donut）、闪电泡芙（Éclair）、冻酸奶（Froyo）、姜饼（Gingerbread）、蜂巢（Honeycomb）﹑冰淇淋三明治（Ice Cream Sandwich）、果冻豆（Jelly Bean）、奇巧（KitKat）、棒棒糖（Lollipop）、棉花糖（Marshmallow）、牛轧糖（Nougat）。

Android系统到Nougat已经发展到7.0版，变化相比最开始的Cupcake1.5版已经相当之大，从1.5到7.0除了经历了大版本迭代之外，还经历了无数的子版本，这样就导致Android系统的碎片化非常严重。因此做Android开发面临的一个很大的挑战就是适配版本。同理，Android客户端应用的技术也随着他的版本变化发生了很大的变化。比如在1.5，1.6到2.2，2.3时代，大家都基本是做Android Native的开发，当时做新闻类应用，详情页可能还会去用Activity做图文混排，还要去考虑适配各种比例。如果到现在5.0，6.0的版本，大家可能就会考虑直接用WebView加载H5页面来实现了。

Android客户端的开发除了操作系统本身的版本复杂性之外，还有一个问题就是由于Android操作系统本身对厂商开源，很多手机厂商会对其进行深度定制，甚至是一些底层的设计也会更改，这样就给我们的Android开发者带来了另一个大的挑战，就是适配Android机型。比如我们国产的小米，魅族品牌的部分机型经常会由于其定制的操作系统而给开发者带来各种问题。

IOS是由苹果公司开发的移动操作系统。苹果公司最早于2007年1月9日的Macworld大会上公布这个系统，最初是设计给iPhone使用的，后来陆续套用到iPod touch、iPad以及Apple TV等产品上。iOS与苹果的Mac OS X操作系统一样，属于类Unix的商业操作系统。原本这个系统名为iPhone OS，因为iPad，iPhone，iPod touch都使用iPhone OS，所以2010WWDC大会上宣布改名为iOS（iOS为美国Cisco公司网络设备操作系统注册商标，苹果改名已获得Cisco公司授权）。

IOS操作系统的版本更新从最开始的1.0到目前的10.2也经历了巨大的变化。并且由于苹果系统的严谨和约束性比Android更加强大，它的系统版本变化对应的API变化非常大，相信做IOS客户端开发的人员都经历过这个版本变化过程的痛苦。不过比较幸运的是IOS系统是封闭性的，它只应用于苹果的设备，而苹果的移动设备无论从机型还是分辨率上来看都比较单一，所以对开发者而言，对机型的适配相对Android而言要轻松的多。这也有利于移动客户端技术架构的选择，不需要太考虑机型的差异性。

Windows手机操作的发展经历了Windows Mobile和Windows Phone两个大版本。Windows Mobile是微软针对移动设备而开发的操作系统。该操作系统的设计初衷是尽量接近于桌面版本Windows，微软按照电脑操作系统的模式来设计WM，以便能使得WM与电脑操作系统一模一样。由于WM在手机上的体验不被用户所喜爱，很快便退出了手机OS的市场，2010年10月，微软宣布终止对WM的所有技术支持。但微软同一时间发布了Windows Phone操作系统。基于Windows CE内核，采用了一种称为Metro的用户界面(UI)，并将微软旗下的Xbox Live游戏、Xbox Music音乐与独特的视频体验集成至手机中。这个版本发展至今已到了Windows 10 Mobile版本。

Windows Phone 操作系统的版本更新相对Android和IOS来说都简单一些，重点经历了7，7.5，8，10四个版本的变化，对开发者而言，系统版本适配相对容易不少。

移动客户端的软件技术

随着移动设备的不断智能化，系统版本的不断迭代，系统新技术的不断更新，虽然会有各种版本和机型适配的问题，但各种成熟的应用框架也层出不穷，使得移动客户端应用的开发变得越来越规范。

不管是Android,IOS还是WP的开发发展到今天都已经比较成熟，开发的架构和思路都比较类似。由于本人只对Android,IOS有过实际开发经验，以下就对这两个系统的开发思路做个总结。

从系统技术层面看，Android和IOS的一般应用开发我觉得可以总结为四类：

四种分类各有优缺点，需要根据具体的业务和需求来进行选择所用的实现方式。另外，关于跨平台的框架除了ReactNative还有很多也较成熟的比较Phonegap等，这里仅以当前较流行的为例进行说明。

这里还要提一种特例就是移动游戏应用，它的技术选型与一般应用开发有些不一样，由于现在游戏引擎的不断成熟化，市面上开源、商用的引擎也不断涌现，对于游戏开发来说，移动客户端的技术选型更多的是对游戏引擎的选择。因为引擎已经封装了对各种手机OS API的底层实现，所以目前市面上流行的引擎一般也是跨平台的，即不需要太考虑Android还是IOS实现上的区别。当然也有部分专门针对Android或IOS的引擎，甚至是开发者自研的游戏引擎，这个与个别开发者的经验有很大关系。在这我也以国家手游测试中心TestBird的数据来说明下国内游戏引擎的使用情况。

对于游戏引擎的选择，个人觉得对开发者重点需要考虑的两大因素就是：游戏视角类型是3D还是2D，是否要考虑用免费开源。

移动客户端的应用类型

在智能机时代，随着各行各业在移动互联网上的不断渗透与发展，各式各样的移动应用如雨后春笋般涌出。以Appstore为例,至16年3月，全球共有190w应用上线，其中90%可以中国区下载使用。在这90%应用当中，有13%左右是由中国本土开发者开发运营的。中文应用占全球应用的比例(12%)正在逐年提高，增速明显也高于全球。同样Android方面的GooglePlay应用市场的应用也正在与日俱增。以下是蝉大师提供的Appstore的应用数量情况。

虽然各大应用市场已经是好几百万的应用，但总结下来发现，其归属类型也是有限的，按appstore和googleplay的分类可以看出也无外乎几十种。以Appstore为例，有游戏、摄影与录像、娱乐、儿童、教育、购物、效率、美食佳饮、生活、健康健美、旅游、音乐、体育、商务、新闻、工具、社交、报刊杂志、财务、参考、导航、医疗、图书、天气等。下面是蝉大师提供的Appstore的分类数据。可以看出，游戏是应用市场的第一大分类，这也是为什么我上面要特别提到移动游戏客户端的技术选型的原因。

行业的不同，业务的不同，应用类型的不同都会导致所选的移动客户端的技术方案的不一样。比如要做一个导航的工具类应用，可能会考虑用Native的开发方式。做一个新闻客户端可能会考虑Native/H5混合的方式。而做一个RSS订阅的客户端阅读软件可能简单的H5 APP更加合适。

移动客户端应用的技术选型的考虑

那么，移动应用的开发到底该如何选择合适的技术架构？在这个过程中需要做哪些考虑？下面本人针对所了解的情况分享一些在技术选型过程中所要注意的点，由于游戏应用的特殊性，我会分开来做分析。

一般应用的技术选型考虑

从应用功能本身对更新要求考虑

有些产品的功能，一开始框架就会比较固定，更多的是在内容的变化，即时迭代框架也不会发生大的变化或者更新。这类应用我们可以采取Native的方式以获取更好的性能体验。比如我们的一些工具类，摄影类应用，这些应用一段周期内的功能会比较固定，不需要经常一时半会儿，变化的可能是一些图文内容，对性能要求也比较高，建议是采取原生开发的方式。同理，如果对更新要求比较高的产品或者是某个功能点，就建议用H5的方式。比如我们大多数应用在启动时可能会展示的运营推广活动界面，这个可能是以周甚至天的单位就需要更新的内容，页面的内容也是不确定性的，这种用H5的方式会更加满足需求。

从应用功能本身对性能要求考虑

Natvie和H5一个很大的区别就是Native的开发能获取更高的性能。因为H5是通过Webview去加载HTML实现的，而Webkit渲染本窗口的效果和硬件配置（CPU/内存）以及内核优化都有较大的关系，至少从目前的发展来看，与本地的效果还有很大的差距，尤其在一些低端Android设备上体验会大打折扣。所以如果对性能要求特别高的应用，建议还是用Native的方式去实现，相反可以考虑H5的加载方式。

当然，随着技术的发展，也出现了上面提到的ReacNative的方式。这个方式是通过JS与本地API通信，体验基本能与原生媲美。但是需要提醒的是React也并非是万能的，它的virtualdom思想确实使DOM操作到视图刷新变为了现实。但本人觉得在一些基本组件渲染方面确实达到了很好的体验，不过如果有复杂的需求可能还是会有些瓶颈。 另外，针对性能问题，也可以考虑用一些技巧来处理。比如考虑到WebView加载Url的性能体验，有很多应用采取先获取数据，再加载本地Html模板的方式，体验同样也提升不少。网易新闻客户端就是这样做的。

从团队规模、开发成本、项目周期考虑

用Native的方式开发应用，理所当然，需要Android,IOS甚至WP都开发一套才能支持，所需要的团队人员，开发成本无疑会大大增加，开发测试周期也会相应加长，甚至对领头技术人员的知识面要求也会大大提高。相反如果用H5的方式来开发应用，除了做屏幕适配外，基本只需要考虑H5的人才，由于能跨平台支持，所需要的人员和开发成本会减少很多。不过，实践经验告诉我们，H5在做屏幕适配的时候也会踩较多的坑，尤其是在不同手机浏览器上的适配，这个也需要有经验和实力的前端人员来填补。 用ReactNative方面和H5的方式一样，可以做到跨平台支持，相应人员和开发成本会降低，甚至性能还会有较大的保障，这也是最近为什么特别流行的一个原因。

从人员招聘难度和待遇考虑

由于Android,IOS,H5的发展都经历了好些年。所以相对而言，从业的人员比较多，简历自然也会比较多。相反，ReactNative的人才也是比较难找的，尤其是优秀的React人才更是可遇而不可求。所以采用框架的时候需要从现实考虑，当前团队是否有这方面的精英，可以满足自己的项目需求，如果临时招兵就要考虑项目周期了。

从开发效率与难度上考虑

随着多年客户端技术的发展，针对Android,IOS,H5各种框架，模块，甚至是三方SDK包都已经相当成熟。比如有网络的库，Json的库，图片异步加载的库，列表的库等等。做分享可以用ShareSDK, 做支付可以调用支付宝的支付SDK, 微信支付SDK，银联SDK, 做登录也有第三方， 甚至做数据分析都有成熟的友盟，TalkingData可用。总之，目前技术的发展方向整体是开放化的状态，在成员基本靠谱的前提下，多使用已有的技术，开发效率自然越来越高。开发难度是因人而已，相应的技术找到合适的人员就行。但个人认为，整体而言，因为H5, React都只需要书写一套代码，在同等资源的情况下，效率会相对较高，难度会相对较低。

从应用安全方面考虑

随着技术的发展，应用对安全的需求越来越高，开发者开发应用的同时也必需考虑到安全问题。Android平台由于可以反编译代码安全保障较低。IOS平台由于苹果的封闭性和严谨性，安全保障相对较高。H5和React由于都是代码透明，所以安全保障最低。当然，针对这个可以考虑把重点的点如果重点逻辑、支付、登录等环境放到服务端来做二次验证以提高应用的安全等级。

对于移动应用的技术的选型还有其它很多方面的考虑，比如用户对体验的要求，产品的特殊需求，甚至企业的人才积累等等。总体来说，大家可以根据自身产品的需求，对市场上同类比较有名的应用进行一些研究，然后做出参考性的选择。

游戏应用的技术选型考虑

游戏应用的技术选型更多的是对引擎的选择。下面以cocos2d-X和Unity3D为例，分享几个对引擎选择方面的考虑。

从游戏类型出发

如果游戏是2D的，那么cocos2d-X是个很好的选择，不过需要选择合适的协同工具用来编辑地图/场景等，也需要集成或者开发各种需要的其他模块，如物理（Physics)、人工智能（AI）、寻路（Path Finding）等等。

如果游戏是3D的，选Unity会更加合适，市面上已经有很多成功的例子。网上有讨论Unity因为收费坑比较多，需要出钱解决。但个人觉得其实很多坑也是前人踩过的，Unity本身也不会故意去设坑，而且很多问题是可以绕过去解决的。Unity具备集成的开发环境，协同开发除了二进制的（其实现在有text的）场景、材质等不大友好外，其他都比较成熟。

从人员成本和招聘难度考虑

由于最近VR的流行，Unity3D的人才被当成VR人才来抢。另外，Unity对于美术、3D模型都要求非常专业，所以Unity的优秀人才是非常贵的，招聘也比较难。相对而言，cocos2d-X上手比较容易，各种培训机构培训几个月就可以上手，从招聘上来说，会相对容易。

从团队规模和后续发展考虑

由于cocos2d-X开源、轻量，所以运行效率，资源占用方面有优势。仅制作2D游戏，前期团队规模有限的前提下，建议用cocos2d-X, 发展到当前,cocos2d-X的扩展工具也已经非常丰富了。相反，如果团队规模比较大，可以优先考虑unity3D，因为在cocos3D还未成熟，VR也提前火爆的时候，个人觉得，unity在这方面优势非常之大。

总之，游戏引擎的选择也是需要从多方面考虑，比如开发难度和效率也同样需要考虑。另外，对于游戏引擎这些还提一下H5游戏引擎。目前市面上像白鹭这种发展的也比较成熟，也有不少H5游戏用，也足够满足需求了。

微信公众号、钉钉企业号、微信小程序的发展

前面稍微对一般应用和游戏应用的类型和技术选型做了一下阐述。最近两年，随着大平台的崛起，脱离应用本身，无需安装的考虑也越来越多。很多互联网公司的产品从开始就不考虑做移动应用，而是依托微信这种平台，做公众号开发。而最近微信又即将推出小程序的功能，也是利用微信底层的封装做到类似原生的体验，个人非常期待。

还有微信的企业号、阿里的钉钉在企业办公这块也发展的成熟，很多企业办公自动化都有用到。他们也提供开放平台，供企业特殊需求，让企业自己可以依托其定制开发。这些技术和平台的发展都丰富了企业的需求和选择。

对于这类依托第三方平台做自己的移动应用产品的，个人的建议是只要是这些平台能实现的产品功能，前期考虑成本以及产品迭代尝试，可以考虑从公众号出发，积累前期用户，等到发展到一定用户量，再研发自己的移动应用来承载用户。