App开发的新趋势

移动开发这些年，移动开发者人数越来越多，类似的培训公司发展也很快，不过伴随着的是移动应用的需求这几年发展更为旺盛。要开发好的App，纯原生开发肯定是最佳选择。但是这么多年发展，原生开发的难度并没有降低多少，特别是作为一个需要长期运营的App，需要原生人员的长期跟进，人员成本很高。另外，从苹果和Android的崛起开始，为了支持截然不同的二个操作系统，相当于二套开发人员开发二个功能完全的App，可想开发效率的低下。

一直以来，程序员对移动跨平台的追求就没有停止努力，跨平台是为了提高开发效率，随着带来的必然是性能的降低。但从软件发展的历史看，部分损失某一方面的性能来换取效率的提高还是非常值得的。
就好像我们用c语言替代汇编，损失了掉的那些运行效率基本是可以忽略不计的，我们换来的是开发效率大幅提高，相对于汇编语言而言C语言同时也部分解决了跨平台跨设备的问题（至少不用再考虑对特定寄存器的编程了）。
同样当历史发展到大量用Java替代C语言开发的时候，我们损失掉了c语言的Native设备的开发能力的同时，所换来的多线程开发、分布式开发、跨平台开发能力的增强，也完全符合www时代发展的需要的。

天然的，移动开发的程序员首先想到的H5和Webview，这是最容易实现的跨平台方案。在H5的路上移动开发者们做了很多努力。纯原生开发我们暂时不提，光从跨平台来说，发展的历程可以大概分3个阶段：

1. 纯H5方式

由于web应用已经在PC应用上占了半壁江山，最早的时候大家想着直接使用手机的系统浏览器加载一个网址，这最容易实现，显然问题很多，性能就不提了，其它方面，比如不同的浏览器适配很难，浏览器的安全性限制了大部分手机上的设备无法使用，存储本地都受限制。但是这种方式并没有消亡，它有一定的适应范围。特别是随着微信的崛起，这种方式已经应用很广了，微信承载了一个统一跨平台的浏览器功能，而且能调用不少原生功能。很多想长期运营的App都会有微信的入口，而且通常是先做微信推广，再做App。

以上的方式还有一个明显的缺陷就是应用的差异性，桌面上没有App的图标，大家都从浏览器或微信入口，对于一个长期运营的想有一定知名度的应用来说肯定无法接受。
接下来移动开发者的想法就是用一个有自己图标和入口的原生的App的壳加载一个原生的Webview组件，然后加载网页，同时通过js和原生的桥接技术来实现html和原生功能的调用。这种技术的代表是phonegap技术，它影响了国内很多移动开发者和公司，有不少框架和技术都是基于或学习它。在它被改名之前，我们也完整下载和研究过它的代码。
这个时期的应用特点是：
＊ 整个核心就一个webview，里面页面的切换都是本地网页或web网页的跳转
＊ 没有任何原生ui的参与，所有ui都是靠webview的标签。有一些简单原生ui可以以窗口的方式调用起来。
＊ 整个应用的逻辑都是靠html里的js来驱动。
＊ 能调用原生的一些基础功能，比如摄像头，存储，数据库等等。

这种方式起初还是有一定市场的，主要是开发效率非常高，很多已有的PC端的网站改吧改吧就出来一个跨Andoid和iOS的应用。但是这样的应用只能说勉强能用，稍微复杂一点就连用都不能用了。性能和体验问题是最主要的，更何况早期Android 2.x时代，iOS4.x，5.x时代手机的性能也不高。

2．H5和Native的混合 （Hybrid）
手机的性能越来越好，H5也越来越流畅，但是随之而来的是好的原生App越来越多，H5在很多方面还是无法替代原生。于是越来越多的原生功能和H5混合在一起，形成了Hybrid开发的模式。
这里我要说跨平台的发展分了二种思路或二个方向：
＊ 原生为主，更多的加入H5的元素，我们暂且称之为Native/H5
＊ H5为主，更多的加入Native的元素, 我们暂且称之为H5/Native

首先我们看Native/H5，这种应用很多，而且是现有市场上的主流，特别是大型的优秀的以内容为主的App，代表是微信，天猫，京东这些App。里面都大量使用Webview加载大量网页。因为原生的更新很麻烦，而那些需要大量内容更新的App必然会选择Webview作为内容承载。很显然，这种方式并没有降低多少成本，原生人员还是需要二套，内容页面还需要一套熟悉web技术等人员。

我们再看H5/Native，国内的代表应该是Appcan，APICloud，wex5等移动开发平台。这些框架的最早期就是我上面提到的纯H5方式，慢慢加上更多的原生因素，比如一个webview改成多个webview，页面上加入不少原生的ui元素，比如页面的titlebar使用原生的ui，还有很多，他们一直在努力解决体验和性能的问题。也有很多App产出了。国外也有很多框架，不少是通过html实现一套和原生样子很像的ui组件。但是相比Native/H5, 我觉得H5/Native的发展思路不对。
我们来看看它们的区别，我们先来看二个App的截图：

我使用了Android的开发者模式，可以看到原生UI组件的边框。我们可以看到他们的差别
＊ 天猫App的主要／主体页面是纯原生的页面，页面上所有大大小小的元素都是原生的UI组件。而下面的截图主体部分都是Webview组件，但是加入一些原生UI。
Native/H5的App所有核心的主要的界面都是纯原生，就像一棵树一样，通常只有到末端的内容页面是网页。页面的跳转都是原生效果。H5/Native主要的框架界面也是Webview加载Html，很显然，体验上和性能上来说H5/Native要差很多。

＊ Native/H5的主要逻辑都是靠原生来驱动。H5只是负责简单的页面展示和很少的逻辑处理。H5/Native所有的逻辑处理都是靠Webview里的html里的js来处理。这一块，性能相比又差了很多。另外复杂度上高了很多，webview只是原生众多组件中的一个，由它来支撑和控制整个App基本上很难，很多开发中的坑无法解决。

＊ 从成本上来说，Native/H5只是稍微降低了一点成本，因为还是需要多套人马。H5/Native的成本就降低了很多了，因为只需要一套web开发人员。

3.JS/Lua和Native的混合

从上面我们可以看到Native/H5 和H5/Native 中间我们还需要再努力努力再寻求一个中间状态，就是尽可能的不牺牲性能的基础上再降低效率和成本。这几年证明通过webview和H5的方式已经无法再优化了。

从Facebook的React Native开始，一种新的趋势已经逐渐冒出来，他们的思路是从Native/H5为源头，但是抛弃webview，保留js。Facebook自己相当于重新设计了一套类似H5的规范，并设计类似一个webview的组件来解析这套规范，包括ui和js代码。但是这里的标签对应的都是可扩展的纯原生的组件。
包括国内的阿里推出的weex和LuaViewSDK，思想上和React Native类似的。

他们的思路就是从原生开发人员的角度出发，尽量扩大跨平台的范围，但是又不带来体验的下降。这种趋势应该是正确的发展方向。

不过这几个技术现在都是一个SDK，也就是并不能实现真正的跨平台，做不到一套开发人员，一套代码就能发布多个平台。就像React Native的口号是Learn Once，Write Anyway。

我要重点介绍一下国内一个移动开发平台Deviceone。Deviceone的发展走过我上面提过的所有阶段，它经历是差不多4年，在内部已经有5个大版本的迭代了。总体来说，也是长期追求效率和性能的最优化的一个结果。

Deviceone的特点是：
 deviceone有一个核心框架，可以理解为类似React Native一样的SDK，可以解析自定义的ui标签和js／lua 代码的功能。差别就是，deviceone定义的ui并不是类似h5，而是把ui代码和js/lua代码完全分开成不同的文件。Ui文件通过IDE的拖拽功能来实现，然后通过属性设置的方式，当然也支持js/lua代码访问。我们直观的看看IDE里可视化ui的图。

 deviceone并不只是一个能实现跨平台的原生SDK，在这个框架的基础上，deviceone对android，ios，windows的移动基础框架做了抽象，包括移动系统基础元素Activity，UIViewCotroller之类的，也标准化了事件机制，存储管理，绑定机制，同步异步等等基础结构。目标就是App开发者无需了解Android，iOS技术的细节，用一套代码实现真正的跨平台，write once，run anyway。

 deviceone并没有脱离原生开发，只不过把原生开发和App开发者分离了，原生开发者只负责开发和业务无关的组件，比如Button，VideoView之类的。而App开发者不需要理解操作系统的差异，只需要参考组件的一套JS／Lua的API，然后专心整理自己App的业务需求，就能搭建出跨平台的App。

 deviceone最大的价值就是提供了一套组件重用的规范和标准，而且是跨平台的组件。我们平常用原生开发很多都是最基础的代码重用，组件重用也仅限于单个平台。而deviceone的组件商店已经积累了快100个跨平台的原生组件了，是由deviceone官方和一些个人原生开发者开发的，有很多都开源了，大家可以参考。目前正在以收费组件的方式吸引更多原生开发者参与。

 deviceone在现有的很多第三方组件基础上由实现了跨平台的封装。大量的第三方平台提供了优质的服务，通常原生开发人员只需要集成android和ios都sdk就可以使用，大大简化了开发人员的。我们在这个基础上又简化了一步，一套js的sdk就可以使用。我们已经集成了很多常用的比如百度地图，极光推送，几个常用的支付，分享等等。

 deviceone提供了强大的可配置组件云打包系统，开发者可以在100个组件里勾选自己需要的组件，然后打包成调试App和发布App。另外提供了很多配置项，尽量简化开发者的工作。

 deviceone对外正式发布半年多，已经积累了很多企业应用，最近几个月逐渐开始积累不少个人应用，感兴趣的可以去苹果的商店和android的市场上搜索一下“慧影时间流”，“纳豆－点餐”，“爱抢劵”，“易经造命”体验一下。这一个月应该又有不少上线应用，请多关注。

介绍了不少，感兴趣可以去多关注国内这个优秀的产品，我相信不少移动开发者被国内各种框架的“折磨”失去了对国内移动开发平台的信心，但是这个平台值得你花一点时间去研究和体验。