Android 原生開發、H五、React-Native使用利弊和場景技術分享

http://m.blog.csdn.net/article/details?id=51778086

發表於2016/6/28 18:52:46  1176人閱讀

 

     最近工做中接觸到React-Native框架，對其進行一些技術分析，結合以前瞭解的H5的一部分，加上本身作了好久的原生開發（十幾個android app、sdk，包括2個ios）, 總結下目前瞭解到的這三種移動端應用開發方式的特色和試用範圍，做爲我的知識的記錄，也做做爲公司內部互相學習的分享。

 

1、原生開發

 

         原生開發是系統自帶的app開發方式，也是大部分人最熟悉app開發的技術，如android、ios、wp。

     原生開發依然是開發者採用最普遍的開發方式，優勢十分顯著。相比其餘開發方式而言，原生開發能夠訪問設備中的全部功能，運行速度更快，性能更高，並且能夠啓用優秀的離線處理和存儲能力等等，提供最佳的用戶體驗，最優質的用戶界面，最華麗的交互。原生開發人員衆多，開發環境成熟，有許多的開源庫提供開發人員調用，但是方便實現各類設計效果。

     原生開發的缺點在逐漸的開發、運營過程當中顯現出來。開發成本高，不一樣平臺須要定製不一樣的app，也就是android定製apk，ios定製app，開發人員須要多平臺多語言，人力成本、時間成本較多，通用性差；上線時間不穩定，須要審覈，特別是蘋果審覈機制，審覈時間長短不一，對內容還有控制，國內Android APP市場（百度手機助手，應用寶，360市場等等）也有相似的問題；版本控制能力差，版本發佈到達率沒法控制，多個版本更新發布，修復bug，沒法保證及時送達到用戶手中；得到新版本須要從新下載安裝，雖然目前有增量升級方式逐漸改變，可是隨之而來的其餘問題如增量升級多版本控制也是個很頭疼的問題；

     總結：原生開發雖然有各類缺點，可是在目前全部的開發技術中原生是最成熟，有效，也是開發人數最多，開源庫最普遍的。對APP要求各方面性能、響應要求高，人員充足，完整開發、測試流程，適合原生APP開發。

 

2、H5開發

 

     H5開發是Html5開發的app，本質上運行在手機瀏覽器中的頁面，通常使用app作一個殼套用瀏覽器運行H5的頁面，因爲H5的特性也有不少app使用半原生半H5的hybird app 開發模式。

     H5有許多優勢，特別針對原生開發的缺點。如： 直接在網頁上調試和修改，幾乎不用考慮用戶機型和適配的問題，針對原生開發的平臺碎片化、開發人力成本、時間成本高；版本升級優點，網頁的升級與用戶無關，用戶無需下載更新安裝，保證明時送達到用戶手中；上線時間穩定、快速，不須要經過開發市場的審覈，有收入分紅的開發市場更是能夠繞過收入分紅。除此之外在視頻媒體方面H5表現也十分優秀的。

     H5的缺點有許多，當新技術出現時候許許多多的人都在吹噓它的優勢，到真正實用時纔對它的缺點正視。H5加載大圖片的時候性能會降低，大量用戶訪問同一個H5應用時性能會降低，響應速度比不上原生app，上網速度也不及原生app，H5不能自動處理動畫上反覆交互（網頁遊戲），須要藉助css三、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適合的地方展現，在其餘地方使用原生開發，以規避缺點，發揚優點。

    

     

3、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等一塊兒封裝進結果，形成包增長七、8M，但據瞭解這是能夠修改的；只支持IOS7以上和android4.1以上機型，這應該不成問題，比較其餘屬於少數；據說qzone使用了react-native，可是crash率前10，react-native佔8個，前5全是react-native，可是我一朋友項目使用過react-native，雖然有坑，可是不會有如此多crash;

 

總結：新技術，開發環境和代碼編碼方面都比較艱澀，有可能有不少坑，可是在界面簡單，三端都要求，開發成本須要下降狀況下可使用react-native。

 

最近在學習react-native，之後可能會有新感覺，公司內部最近能夠找個項目實戰一下。