智能手機功能越來越強大，已經在逐漸替代電腦的作用。百度、騰訊、阿里的移動端日活數也在逐步的趕上甚至超越電腦端用戶。叫喊着“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