一、原生開發       原生開發是系統自帶的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版本略好，android發展較慢；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;

 原生頁面和H5頁面的優劣勢分析：

 

原生頁面

優勢：

（1）執行速度比較快

（2）能使用裝置的底層功能，如攝像頭、方向感測器、重力感測器、撥號、GPS、語音、簡訊、藍芽等

（3）在介面設計、功能模組、操作邏輯等層面相較web更易做到App的便捷性和舒適性，功能更加強大

（4）節省流量

劣勢：

（1）不同的作業系統（如Android和iOS）需要獨立的進行開發，使用其各自的開發包、開發工具和控制元件

（2）每次有更新，都需要重新打包一次釋出到應用平臺上，且每次要向各個應用商店進行提交稽核。之後使用者需要手動進行點選更新安裝（安裝成本較高）

（3）開發成本比較高，尤其需要適配各種機型時（如Android應用，需要適配各種Android手機）

 

H5頁面

優勢：

（1）由於是執行在瀏覽器上，所以只需要開發一次便可以在不同的作業系統上顯示

（2）迭代版本時，不需要打包便可以釋出（實時更新、快速迭代），與雲端實現實時資料互動

（3）開發成本相對較低，對瀏覽器的適配較簡單，且釋出門檻相對較低

劣勢：

（1）每次開啟頁面，都得重新載入，獲取資料...

（2）過於依賴網路，速度無法保證。特別在弱網環境下，不僅耗費流量而且載入緩慢，就算是WiFi情況下也不容樂觀

（3）只能使用有限的裝置底層功能（無法使用攝像頭、方向感測器、重力感測器、撥號、GPS、語音、簡訊、藍芽等功能）

（4）仍處於發展階段，部分功能無法在基於現有技術的瀏覽器基礎上實現，且無法全面的顯示最完美的使用者體驗，只能用現有技術去彌去找最佳解決方案

 

 分析淘寶中的原生頁面和H5頁面

 

----------------------------------------------------------------------------------------------------------------------------

 ---------------------------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------------------------

 ---------------------------------------------------------------------------------------------------------------------------

由上圖得知，是否有底部tab導航欄也無法區別出H5頁面

 

----------------------------------------------------------------------------------------------------------------------------

 ---------------------------------------------------------------------------------------------------------------------------

如下圖是一個原生與webview混排的介面，紅色線框是各控制元件的繪製邊界，中間那一大塊佈局豐富的介面沒有顯示出很多邊界紅色，就是H5實現的。

此外，據說天貓、淘寶據說之前用過react native一段時間，後來自己出了Weex框架。