去它的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吧！