用 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 吧！