用 JS 写原生跨平台 app

智能手机功能越来越强大，已经在逐渐替代电脑的作用。百度、腾讯、阿里的移动端日活数也在逐步的赶上甚至超越电脑端用户。叫喊着 “mobile first” 的公司越来越多， App 开发者应运而生，且队伍日趋庞大，有的人以此为契机走上创业之路。

一、APP 开发之殇

移动开发并未如想像般风光。

每一个原生应用开发的项目都是一个巨大的坑。要么等着竞争者通过移动互联技术把你打败，要么跳进坑自己招人来开发移动应用。写App真是一个苦B的差事。做一个App通常要配置三套人马，一拨人去做android，一拨人去做ios；如果还有网站的话，还需要另外配置网页开发人员，开发成本也随之加倍。最可怕的是，需要面对大量的黑屏、闪退、屏幕适配等底层技术陷阱。再加上技术人员流失更换频率较高，业务系统维护周期较长，操作系统平台升级后的兼容性问题（例如IOS7 UI布局结构的强制调整问题、IOS8的64位内核强制升级问题）。到处都是技术陷阱，这岂是每个小项目的成本能够承受的。

许多公司都是新成立的创业公司，能出得起钱配足三套人马的凤毛麟角。通常都是一个人干三个人的活。如果一个研发牛人又能搞android又能搞ios，马上就能成为香饽饽，到手工资大把大把地。

人员问题往往还不需要研发操心，但是开发过程中更会遇到开发维护成本高、难度大、操作系统版本众多适配难等等实际问题。那更叫人头疼！

二、H5 的解决之道

HTML5标准终于通过了！很多人看到其在移动端“阳光灿烂” 的明天。一套 html5 的代码可以适应 android 、 ios 、微信、 web 等多端平台。许多人叫嚣，未来移动跨平台开发是 H5 的天下！很多 “ 砖家 ” 也说， HTML5 将颠覆原生 App 世界。

基于此，催生了一批跨平台H5 跨平台开发平台 / 工具： PhoneGap 、 Appcan 、 HBuilder 、 APICloud ……

然而，事情真的像想象中美好吗？

之前哥相信了“砖家” 的这些话，上了 H5 的贼船，结果苦 B 、趟坑的日子就来了……

基于血泪的经验，H5 应用目前还是存在如下问题：

1、H5 存在天生的“性功能”障碍

“性功能”的说法是HBuilder的老总提出的。即：性能不如原生，工具不如原生、功能不如原生。HBuilder 及一众跨平台开发商都宣称自己解决了这些问题。

H5 发展如此多年，在老旧机器上，甚至在高端 android4.2 以下版本的机器上，卡顿非常明显。虽然近一年来，千元机硬件性能大幅度飙升，千元机也能买到 8 核了。但你写一个 H5 的 app 试试，未经过专业人员性能优化，开多了页面依然卡顿。

H5 的应用有许多优化点，如果没有经历若干次趟坑经验，很难搞出性能很好的应用来。

别听很多跨平台开发工具商吹的天花乱坠，稍微复杂一些的 APP 卡顿就是卡顿，短期内还是无法解决。

2、 存在源码泄露、黑客代码注入等风险

H5写的app，你只需要将安装包后缀改为 zip ， 解压缩后就能直接看到源代码，根本没有秘密可言。想想看，你花了好几个月披星戴月赶工出来的app ，源码随意就能被人拿走，稍微修改后就能重新打包成新的 app ，你是什么感受 ？

更可怕的是，你应用的支付宝密钥、微信的加密 key 全部都直接暴露给破解者了……

有的跨平台开发商声称提供混淆加密的功能，但实际上根本没什么卵用。无论你怎么加密，浏览器显示页面之前就必须解密出来才能正常显示。而在 android4.4 以后版本上，连上电脑，用 Chrome 浏览器直接就能提取出 app 打开的浏览器中原始页面的任意内容，甚至可以设断点调试，用浏览器控制台随意注入代码。

3、 控件稀缺，集成三方 SDK 困难

H5的app ，如果有美术基础，用 HTML 描述界面很是便捷。但是如果你想调用系统的一些功能，则就需要看你的跨平台的工具是否支持了。一旦尚未提供，那就苦 B 了。

虽然好多开发商都声称，自己的工具很容易自已封装控件扩展。但费话，如果我会原生开发，还用你这工具干毛啊，哥直接写原生的啦。  

我之前就遇到这个问题，写一款 APP ，要用到第三方的 SDK ，而当前的开发工具没有提供此类控件，导致项目无法进行。之后每天都去开发商 BBS 、 QQ 群里求爷爷告奶奶的等待人家开恩，帮你提供。连续一个月，人家根本不鸟你，项目最后无奈告终。

既然 H5 的跨平台开发还不靠谱，那怎么办呢？

三、 原生跨平台解决方案

（一）、 React Native 的解决方案

React Native的出现，让人感觉到惊喜。既拥有Native 的用户体验、又保留React 的开发效率。 这个理念似乎迎合了业界普片存在的痛点，开源不到1 周 github star 破万，目前是 27000+ 。

React Native 的 原理是在 JavaScript 中用 React 抽象视图操作为系统原生的 UI 组件，代替 DOM 元素来渲染。它不同于 webkit 或任何我们已知的浏览器，采用自行封装的渲染引擎，渲染生成不同平台下的原生 UI ，同时 JS 和 Native 之间通过 Bridge 通信实现相应的功能。

这种技术将独立的界面描述文件与原生 UI 统一起来，个人认为它是已知中间件产品中最先进、最能代表未来发展趋势的方向。

React Native看上去很美，然而现实却很“ 骨感 ” 。

目前， React Native 使用中还存在一些问题 ：

1、界面布局困难

React native 与 HTML5 无关。 虽然它使用的语言还是 javascript ，它使用自定义的 react 方式去声明界面，没有 HTML 和 css ！ 对于广大开发者，你的 HTML 和 css 白学了，重新学 非死book 的语法。

同时， react 布局方式与之前传统观念差别很大，且没有可视化工具，如果想布局出一套复杂的的界面是非常费劲的。

2、 安装包太大

React native是自己的渲染引擎，不是webkit 或任何我们熟悉的浏览器。相当于是非死book 的定制浏览器 。引擎包的体积不小， hello world 就是 7M 。 如果实现一个中等功能的APP，十几兆的包是跑不了啦 。

3、开发工具

React native没有配套的ide ， 开发调试非常麻烦。没有原生开发基础的话甚至可能搭不起来开发环境 。

打包也不方便，没有 mac 电脑无法调试或打包 ios 应用。

4、 不符合国情

像国内开发一款App ， 嵌入一些第三方开发包那是再正常不过的事情。比如登录要嵌入微信、微博、QQ 等 第三方库，聊天嵌入环信，统计嵌入友盟，支付嵌入支付宝 ……

这些第三方库如何集成到 React Native 的项目里呢？如果你祈祷哪天 非死book 帮你集成好发布一些控件包的话，那你就等着去吧。

（二）、 DeviceOne 的解决方案

DeviceOne 是一个新兴的移动跨开发平台。 2015 年 5 月份正式对外发布（他们网站 SEO 做的很烂，宣传也少，故目前还较少人知道）。

DeviceOne采用类似于React Native 的解决方案。它已经提供了大量丰富的 UI 组件和API组件，这些组件全部 都是货真价实的 纯原生 实现，而 运行中的应用也是纯原生的UI呈现。你开十几个页面根本感觉不到卡顿。

平台下所有 UI 组件功能组件都已经被抽象成可被自由扩展的跨平台组件，就连 Webkit 本身在模型中也仅仅退化成一个普通的 UI 组件而已， App 开发者可以自由选择 js 脚本、 lua 脚本来编写业务逻辑。只需要下 javascript 人员即可完成纯原生的 app 开发，做出的产品那个流畅啊 ……

研发人员可以选择要打包的控件列表，打出的包非常小，通常在3-5M以内。而且由于是原生app，代码全部做的加密处理，黑客无法简单的解压缩就能盗用代码了。

同时，DeviceOne实现了界面和业务逻辑的分离。UI可以通过IDE直接拖拽生成，那叫一个爽字！

所见即所得的界面

DeviceOne已经提供了80多个控件，不仅仅可以DIY出很炫的界面，而且还很接地气的加入了许许多多第三方SDK，很方便使用。同时如果官方的控件没有满足需要的话，可以自己封装原生控件到IDE中来。这样一来，基本上所有原生可以做的事，它都可以实现了。像 H5 难以完成的媒体、影音的效果，用DO实现轻而易举。

另外，DeviceOne并不排斥H5。你完全可以把之前实现的 html 代码用 WebView 控件加载起来，实现了历史资产的复用，以及过渡。

官方提供了三个演示app源码：

更多演示源码可以在论坛里找到。

我下载看了这些代码后，大约在两天时间内就完成了上手。在实际使用其进行了一个APP开发后，开发过程中没有什么太多的坑，过程还是很美好的 。

只需用JS就可以写原生APP ，哇赛， 简直是太爽了 。

等有空时，我会写一系列文章介绍它，以及用它开发一款APP 的整个过程，帮助同我一样有跨平台APP 开发的人更方便的去开发 。

让我们一起用JS 写原生 APP 吧！