去它的h5，我仍是用js写原生跨平台app吧

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

1、APP开发之殇

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

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

许多公司都是新成立的创业公司，能出得起钱配足三套人马的百里挑一。一般都是一我的干三我的的活。若是一个研发牛人又能搞android又能搞ios，立刻就能成为香饽饽，到手工资大把大把地。

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

 

2、H5的解决之道

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

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

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

 

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

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

 

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

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

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

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

别听不少跨平台开发工具商吹的天花乱坠，稍微复杂一些的APP卡顿就是卡顿，短时间内仍是没法解决。‍‍

 

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

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

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

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

 

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

‍H5的app，若是有美术基础，用HTML描述界面非常便捷。可是若是你想调用系统的一些功能，则就须要看你的跨平台的工具是否支持了。一旦还没有提供，那就苦B了。

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

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

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

 3、原生跨平台解决方案

（一）、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使用中还存在一些问题：

一、界面布局困难

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

同时，react布局方式与以前传统观念差异很大，且没有可视化工具，若是想布局出一套复杂的的界面是很是费劲的。‍

二、安装包太大

React native是本身的渲染引擎，不是webkit‍或任何咱们熟悉的浏览器。至关因而facebook的定制浏览器‍。引擎包的体积不小，hello world就是7M。‍‍若是实现一个中等功能的APP，十几兆的包是跑不了啦‍‍。‍

 

三、开发工具

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

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

 

四、 不符合国情

‍像国内开发一款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吧！