http://m.blog.csdn.net/article/details?id=51778086
發表於2016/6/28 18:52:46 1176人閱讀
最近工作中接觸到React-Native框架，對其進行一些技術分析，結合之前了解的H5的一部分，加上自己做了很久的原生開發（十幾個android app、sdk，包括2個ios）, 總結下目前了解到的這三種移動端應用開發方式的特點和試用范圍，作為個人知識的記錄，也作作為公司內部互相學習的分享。
一、原生開發
原生開發是系統自帶的app開發方式，也是大部分人最熟悉app開發的技術，如android、ios、wp。
原生開發依然是開發者采用最廣泛的開發方式，優點十分顯著。相比其他開發方式而言，原生開發可以訪問設備中的所有功能，運行速度更快，性能更高，而且可以啟用優秀的離線處理和存儲能力等等，提供最佳的用戶體驗，最優質的用戶界面，最華麗的交互。原生開發人員眾多，開發環境成熟，有許多的開源庫提供開發人員調用，可是方便實現各種設計效果。
原生開發的缺點在逐漸的開發、運營過程中顯現出來。開發成本高，不同平台需要定制不同的app，也就是android定制apk，ios定制app，開發人員需要多平台多語言，人力成本、時間成本較多，通用性差；上線時間不穩定，需要審核，特別是蘋果審核機制，審核時間長短不一，對內容還有控制，國內Android APP市場（百度手機助手，應用寶，360市場等等）也有類似的問題；版本控制能力差，版本發布到達率無法控制，多個版本更新發布，修復bug，無法保證及時送達到用戶手中；獲得新版本需要重新下載安裝，雖然目前有增量升級方式逐漸改變，但是隨之而來的其他問題如增量升級多版本控制也是個很頭疼的問題；
總結：原生開發雖然有各種缺點，但是在目前所有的開發技術中原生是最成熟，有效，也是開發人數最多，開源庫最廣泛的。對APP要求各方面性能、響應要求高，人員充足，完整開發、測試流程，適合原生APP開發。
二、H5開發
H5開發是Html5開發的app，本質上運行在手機瀏覽器中的頁面，一般使用app做一個殼套用瀏覽器運行H5的頁面，由於H5的特性也有很多app使用半原生半H5的hybird app 開發模式。
H5有許多優點，特別針對原生開發的缺點。如： 直接在網頁上調試和修改，幾乎不用考慮用戶機型和適配的問題，針對原生開發的平台碎片化、開發人力成本、時間成本高；版本升級優勢，網頁的升級與用戶無關，用戶無需下載更新安裝，保證實時送達到用戶手中；上線時間穩定、快速，不需要通過開發市場的審核，有收入分成的開發市場更是可以繞過收入分成。除此以外在視頻媒體方面H5表現也十分優秀的。
H5的缺點有許多，當新技術出現時候許許多多的人都在吹噓它的優點，到真正實用時才對它的缺點正視。H5加載大圖片的時候性能會下降，大量用戶訪問同一個H5應用時性能會下降，響應速度比不上原生app，上網速度也不及原生app，H5不能自動處理動畫上反復交互（網頁游戲），需要借助css3、javascript。H5本質上是網頁，無論是離線的還是在線的，它本質上是通過瀏覽器呈現到用戶面前的網頁，在手機上模擬得像app，網頁的缺陷它無可避免。1.軟、硬件的支撐問題，現在早已不是問題，這里講出是由於2012年左右當時H5火起來時，我在FF公司看到宣講H5時，當時許多的手機依然無法支持h5，幾年過去了這個問題基本不存在了；2.性能問題，這才是H5最大的問題，原生開發對性能的支持遠超H5，在用戶體驗上，H5的app絕對是占據下風的，app反應速度、流暢度等；3.功能問題，對某些硬件攝像頭、陀螺儀、麥克風等硬件支持較差，頻繁調用這些硬件，H5不容易擴展，調用速度也不如人意。
總結：純H5 app適合小游戲、媒體、視頻、營銷產品、介紹等功能，大部分大型app屬於原生、H5混合的hybird app。
H5話題的延伸。2010-2012年H5大火，有許多人認為可以替換原生開發，成為一種“write once,run anywhere”的開發模式，但是在許多公司的案例中就遭遇了失敗，但是僅僅過去了3-4年，硬件設備的更新，軟件的支持，H5又一次以不同的面目再一次火起來。這個過程十分讓人唏噓。HTML5已經出來很多年了，早在2010年，喬布斯在封殺Flash的言論中，就預言HTML5將取代Flash成為下一波技術浪潮。就算不關心技術的朋友，去翻翻手機也能感受到在pc端一直以來占據統治地位的Flash在手機端幾乎不見蹤影，這是從2010年以來蘋果公司與Adobe公司的戰爭開始，蘋果背后無數開發人員支持研發HTML5技術，讓HTML5技術得以普及開來。2011年Adobe自己也放棄了Flash移動端的研發工作，HTML5已經被移動瀏覽器廣泛支持，Flash已經落后於時代了。很多大公司都在推動HTML5的發展，但是也有滑鐵盧，Facebook的扎克伯格是最慘痛的教訓，他想要用HTML5的web app來打破ios和android的壟斷，實用HTML5來代替原生App。在這件事上facebook失敗了，具體表現在2013年前facebook在移動端的產品的市場表現非常一般，最后無奈宣布回歸原生app的開發。Facebook在html5的試錯大大打擊了HTML5的實用性，但是HTML5自身的厚積薄發還是讓這項技術沒有沒落。
手機硬件的提升和HTML5本身的完善，使得基於HTML5的應用表現更好，iPhone對HTML5的支持更加完善，Google也完成了移動端Chrome瀏覽器向Chromiumnie內核的切換，大幅提升對HTML支持。很多基於HTML5的應用都在試圖替代原生app，但是由於技術限制，用戶體驗遠遠不如原生app，但是某些方面HTML5提供了比原生App更好的體驗，但這種體驗的基礎不是單純的替代原生App，而是做一些最適合HTML5的細分應用，比如小游戲、媒體和營銷類的產品。這些細分的方向能夠最大程度發揮HTML5跨平台、開發成本低、開發速度快的優點，在整體產品體驗上遠超過原生app。HTML5和原生app並不是對立的，反而原生app需要HTML5去解決一些核心的問題，讓整個移動市場更有效率。很多公司在努力推動HTML5技術，但是讓HTML5重新煥發生機的是微信，利用朋友圈的私密社交，以及HTML5自身的跨平台、低成本開發、速度快等特性，不少公司利用HTML5技術在朋友圈做了一次又一次的營銷。微信本身沒有在HTML5技術上有什么創造性的推動，而是在HTML5的應用場景上做出了自己的不同嘗試，形成了附着微信這個超級app的HTML5應用場景。HTML5的優點跨平台、低成本開發、開發速度快等優點不是最終站穩市場的根源，最終成就它的還是它自身比原生app更加優秀的特質，比如小游戲、媒體、視頻、營銷產品等等。目前許多app都采用hybird app 開發（微信、支付寶等等），在h5適合的地方展示，在其他地方使用原生開發，以規避缺點，發揚優勢。
三、react-native框架
介紹react-native之前，需要先提下react，react 是facebook在2013年開源的網站ui開發的js庫，react-native是用react 進行原生app開發的框架，讓廣大開發者使用js和react開發應用，提倡組件化開發。react-native提供一個個封裝好的組件讓開發者使用，也可以相關嵌套形成新的組件。使用react-native可以維護多種平台（Web，Android和IOS）的同一份邏輯核心代碼來創建原生app。從代碼上看結構類似，細節有差別，facebook強調的是“learn once,write everywhere”，應用前端使用js和React來開發不同平台的ui，下層核心模塊編寫復用業務邏輯代碼，提高應用的開發效率。
react-native的原理。react-native的優點和H5類似，跨平台、低成本開發、開發速度快、動態發布、一套類似代碼維護三個平台。代碼結構如下圖：
程序結構上，有兩個工程分別是ios 、android，編譯后回在相應文件夾中生成apk和app，界面代碼是選中的index.android.js和index.ios.js，右側的JS代碼在這兩個JS文件中幾乎一模一樣。
它與web app很類似，但是絕對不是web app，查看開源代碼，你不會發現webview的使用，也就是本質上react-native的app不是web app 或者hybird app，而是原生控件。那它是怎么實現的呢，react-native的原理如下圖：
原理上看react-native在js端和java端互相有個映射關系，通過兩端的配置表來實現，java端和js端持有同一張表，通信時靠這張表的各個條目的對應進行的。上面提到了facebook實現了組件讓開發者調用，就是通過js的配置表調取原生控件，java調用js也是類似的情況。所以當我們使用復雜控件時，可以自己實現java代碼，添加入配置表中，即可自定義心新的映射關系，讓我們js調用自定義的復雜控件 , 當然web 、ios、androi需要實現不同的控件代碼，只是js端的調用代碼一樣或者類似。
react-native的優點：不用webview,擺脫了webview的交互和性能問題；有較強的擴展性，java端提供了基礎控件，js可以自由組合使用也可以自定義組合控件；
react-native的缺點：組件不全，第三方組件也不全，遇到某些特殊功能，需要花大力氣寫；性能方面也無法媲美原生，還是有一些損耗，特別是交換大數據時；IOS版本略好，androi發展較慢；ios和android代碼並非通用，有可能需要維護兩套代碼或者在代碼中做一些判斷；開發人員還是需要會原生開發，不然自定義組件無法編碼；
個人感受，react-native不是萬能葯，只是一種高效的解決方案，不要期望它解決所有的問題，要不要使用需要場景衡量；客戶端轉開發react-native感覺比較簡單，比較JS大部分人都有基礎，前端人員開發react-native理解原生部分的代碼應該十分困難；相比原生海量的第三方控件和第三方包，react-native大部分道路還得靠自己摸索；不同端的代碼風格和結構大體類似，但具體標簽可能會不一樣；目前得到經驗是IOS版本比較穩定，android版本還不太成熟，android 版本2015年下半年發布，一直在0.*版本上更新，android1.0版本還沒有發布；把把facebook的第三方包網絡連接包okhttp和圖片下載解析包fresco等一起封裝進結果，造成包增加7、8M，但據了解這是可以修改的；只支持IOS7以上和android4.1以上機型，這應該不成問題，比較其他屬於少數；聽說qzone使用了react-native，但是crash率前10，react-native占8個，前5全是react-native，但是我一朋友項目使用過react-native，雖然有坑，但是不會有如此多crash;
總結：新技術，開發環境和代碼編碼方面都比較艱澀，有可能有很多坑，但是在界面簡單，三端都要求，開發成本需要降低情況下可以使用react-native。
最近在學習react-native，以后可能會有新感受，公司內部最近可以找個項目實戰一下。