去它的h5，我还是用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白学了，重新学facebook的语法。

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

2、安装包太大

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

3、开发工具

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

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

4、 不符合国情

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

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

（二）、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，很方便使用。像 H5 难以完成的媒体、影音的效果，用DO实现轻而易举。

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

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

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

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

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

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

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

转载自OSChina，原地址：http://my.oschina.net/qinerg/blog/624956?p=7#comments