最近工作中接觸到React-Native框架，對其進行一些技術分析勺拣，結合之前了解的H5的一部分奶赠，加上自己做了很久的原生開發(fā)（十幾個android app、sdk宣脉，包括2個ios）, 總結下目前了解到的這三種移動端應用開發(fā)方式的特點和試用范圍车柠，作為個人知識的記錄，也作作為公司內(nèi)部互相學習的分享塑猖。
一竹祷、原生開發(fā)
原生開發(fā)是系統(tǒng)自帶的app開發(fā)方式，也是大部分人最熟悉app開發(fā)的技術羊苟，如android塑陵、ios、wp蜡励。
原生開發(fā)依然是開發(fā)者采用最廣泛的開發(fā)方式令花，優(yōu)點十分顯著。相比其他開發(fā)方式而言凉倚，原生開發(fā)可以訪問設備中的所有功能兼都，運行速度更快，性能更高稽寒，而且可以啟用優(yōu)秀的離線處理和存儲能力等等扮碧，提供最佳的用戶體驗，最優(yōu)質的用戶界面，最華麗的交互慎王。原生開發(fā)人員眾多蚓土，開發(fā)環(huán)境成熟，有許多的開源庫提供開發(fā)人員調用赖淤，可是方便實現(xiàn)各種設計效果蜀漆。
原生開發(fā)的缺點在逐漸的開發(fā)、運營過程中顯現(xiàn)出來咱旱。開發(fā)成本高确丢，不同平臺需要定制不同的app，也就是android定制apk莽龟，ios定制app蠕嫁，開發(fā)人員需要多平臺多語言锨天，人力成本、時間成本較多，通用性差餐塘；上線時間不穩(wěn)定歉甚，需要審核，特別是蘋果審核機制益缠，審核時間長短不一脑奠，對內(nèi)容還有控制，國內(nèi)Android APP市場（百度手機助手幅慌，應用寶宋欺，360市場等等）也有類似的問題；版本控制能力差胰伍，版本發(fā)布到達率無法控制齿诞，多個版本更新發(fā)布，修復bug骂租，無法保證及時送達到用戶手中祷杈；獲得新版本需要重新下載安裝，雖然目前有增量升級方式逐漸改變渗饮，但是隨之而來的其他問題如增量升級多版本控制也是個很頭疼的問題但汞；
總結：原生開發(fā)雖然有各種缺點，但是在目前所有的開發(fā)技術中原生是最成熟互站，有效私蕾，也是開發(fā)人數(shù)最多，開源庫最廣泛的胡桃。對APP要求各方面性能踩叭、響應要求高，人員充足标捺，完整開發(fā)懊纳、測試流程揉抵，適合原生APP開發(fā)。
二嗤疯、H5開發(fā)
H5開發(fā)是Html5開發(fā)的app冤今，本質上運行在手機瀏覽器中的頁面，一般使用app做一個殼套用瀏覽器運行H5的頁面茂缚，由于H5的特性也有很多app使用半原生半H5的hybird app 開發(fā)模式戏罢。
H5有許多優(yōu)點，特別針對原生開發(fā)的缺點脚囊。如： 直接在網(wǎng)頁上調試和修改龟糕，幾乎不用考慮用戶機型和適配的問題，針對原生開發(fā)的平臺碎片化悔耘、開發(fā)人力成本讲岁、時間成本高；版本升級優(yōu)勢衬以，網(wǎng)頁的升級與用戶無關缓艳，用戶無需下載更新安裝，保證實時送達到用戶手中看峻；上線時間穩(wěn)定阶淘、快速，不需要通過開發(fā)市場的審核互妓，有收入分成的開發(fā)市場更是可以繞過收入分成溪窒。除此以外在視頻媒體方面H5表現(xiàn)也十分優(yōu)秀的。
H5的缺點有許多冯勉，當新技術出現(xiàn)時候許許多多的人都在吹噓它的優(yōu)點澈蚌，到真正實用時才對它的缺點正視。H5加載大圖片的時候性能會下降珠闰，大量用戶訪問同一個H5應用時性能會下降惜浅，響應速度比不上原生app，上網(wǎng)速度也不及原生app伏嗜，H5不能自動處理動畫上反復交互（網(wǎng)頁游戲）坛悉，需要借助css3、javascript承绸。H5本質上是網(wǎng)頁裸影，無論是離線的還是在線的，它本質上是通過瀏覽器呈現(xiàn)到用戶面前的網(wǎng)頁军熏，在手機上模擬得像app轩猩，網(wǎng)頁的缺陷它無可避免。
1.軟、硬件的支撐問題均践，現(xiàn)在早已不是問題晤锹，這里講出是由于2012年左右當時H5火起來時，我在FF公司看到宣講H5時彤委，當時許多的手機依然無法支持h5鞭铆，幾年過去了這個問題基本不存在了；
2.性能問題焦影，這才是H5最大的問題车遂，原生開發(fā)對性能的支持遠超H5，在用戶體驗上斯辰，H5的app絕對是占據(jù)下風的舶担，app反應速度、流暢度等彬呻；
3.功能問題衣陶，對某些硬件攝像頭、陀螺儀废岂、麥克風等硬件支持較差祖搓，頻繁調用這些硬件狱意，H5不容易擴展湖苞，調用速度也不如人意。
總結：純H5 app適合小游戲详囤、媒體财骨、視頻、營銷產(chǎn)品藏姐、介紹等功能隆箩，大部分大型app屬于原生、H5混合的hybird app羔杨。
H5話題的延伸捌臊。2010-2012年H5大火，有許多人認為可以替換原生開發(fā)兜材，成為一種“write once,run anywhere”的開發(fā)模式理澎，但是在許多公司的案例中就遭遇了失敗，但是僅僅過去了3-4年曙寡，硬件設備的更新，軟件的支持举庶，H5又一次以不同的面目再一次火起來执隧。這個過程十分讓人唏噓。HTML5已經(jīng)出來很多年了镀琉，早在2010年屋摔，喬布斯在封殺Flash的言論中，就預言HTML5將取代Flash成為下一波技術浪潮。就算不關心技術的朋友，去翻翻手機也能感受到在pc端一直以來占據(jù)統(tǒng)治地位的Flash在手機端幾乎不見蹤影，這是從2010年以來蘋果公司與Adobe公司的戰(zhàn)爭開始，蘋果背后無數(shù)開發(fā)人員支持研發(fā)HTML5技術，讓HTML5技術得以普及開來橄教。2011年Adobe自己也放棄了Flash移動端的研發(fā)工作，HTML5已經(jīng)被移動瀏覽器廣泛支持盔夜，F(xiàn)lash已經(jīng)落后于時代了喂链。很多大公司都在推動HTML5的發(fā)展衩藤，但是也有滑鐵盧，F(xiàn)acebook的扎克伯格是最慘痛的教訓，他想要用HTML5的web app來打破ios和android的壟斷间狂，實用HTML5來代替原生App忙菠。在這件事上facebook失敗了淆游，具體表現(xiàn)在2013年前facebook在移動端的產(chǎn)品的市場表現(xiàn)非常一般拾稳，最后無奈宣布回歸原生app的開發(fā)震鹉。Facebook在html5的試錯大大打擊了HTML5的實用性泥技，但是HTML5自身的厚積薄發(fā)還是讓這項技術沒有沒落榕订。
手機硬件的提升和HTML5本身的完善贩幻，使得基于HTML5的應用表現(xiàn)更好仿荆，iPhone對HTML5的支持更加完善舶替，Google也完成了移動端Chrome瀏覽器向Chromiumnie內(nèi)核的切換坎穿，大幅提升對HTML支持展父。很多基于HTML5的應用都在試圖替代原生app，但是由于技術限制玲昧，用戶體驗遠遠不如原生app栖茉，但是某些方面HTML5提供了比原生App更好的體驗，但這種體驗的基礎不是單純的替代原生App孵延，而是做一些最適合HTML5的細分應用吕漂，比如小游戲、媒體和營銷類的產(chǎn)品尘应。這些細分的方向能夠最大程度發(fā)揮HTML5跨平臺惶凝、開發(fā)成本低、開發(fā)速度快的優(yōu)點犬钢，在整體產(chǎn)品體驗上遠超過原生app苍鲜。HTML5和原生app并不是對立的，反而原生app需要HTML5去解決一些核心的問題玷犹，讓整個移動市場更有效率混滔。很多公司在努力推動HTML5技術，但是讓HTML5重新煥發(fā)生機的是微信歹颓，利用朋友圈的私密社交坯屿，以及HTML5自身的跨平臺、低成本開發(fā)巍扛、速度快等特性领跛，不少公司利用HTML5技術在朋友圈做了一次又一次的營銷。微信本身沒有在HTML5技術上有什么創(chuàng)造性的推動撤奸，而是在HTML5的應用場景上做出了自己的不同嘗試吠昭，形成了附著微信這個超級app的HTML5應用場景喊括。HTML5的優(yōu)點跨平臺、低成本開發(fā)怎诫、開發(fā)速度快等優(yōu)點不是最終站穩(wěn)市場的根源瘾晃，最終成就它的還是它自身比原生app更加優(yōu)秀的特質，比如小游戲幻妓、媒體蹦误、視頻、營銷產(chǎn)品等等肉津。目前許多app都采用hybird app 開發(fā)（微信强胰、支付寶等等），在h5適合的地方展示妹沙，在其他地方使用原生開發(fā)偶洋，以規(guī)避缺點，發(fā)揚優(yōu)勢距糖。
三玄窝、react-native框架
介紹react-native之前，需要先提下react悍引，react 是facebook在2013年開源的網(wǎng)站ui開發(fā)的js庫恩脂，react-native是用react 進行原生app開發(fā)的框架，讓廣大開發(fā)者使用js和react開發(fā)應用趣斤，提倡組件化開發(fā)俩块。react-native提供一個個封裝好的組件讓開發(fā)者使用，也可以相關嵌套形成新的組件浓领。使用react-native可以維護多種平臺（Web玉凯，Android和IOS）的同一份邏輯核心代碼來創(chuàng)建原生app。從代碼上看結構類似联贩，細節(jié)有差別漫仆，facebook強調的是“l(fā)earn once,write everywhere”，應用前端使用js和React來開發(fā)不同平臺的ui撑蒜，下層核心模塊編寫復用業(yè)務邏輯代碼歹啼，提高應用的開發(fā)效率。
react-native的原理座菠。react-native的優(yōu)點和H5類似，跨平臺藤树、低成本開發(fā)浴滴、開發(fā)速度快、動態(tài)發(fā)布岁钓、一套類似代碼維護三個平臺升略。代碼結構如下圖：
程序結構上微王，有兩個工程分別是ios 、android品嚣，編譯后回在相應文件夾中生成apk和app炕倘，界面代碼是選中的index.android.js和index.ios.js，右側的JS代碼在這兩個JS文件中幾乎一模一樣翰撑。
它與web app很類似罩旋，但是絕對不是web app，查看開源代碼眶诈，你不會發(fā)現(xiàn)webview的使用涨醋，也就是本質上react-native的app不是web app 或者hybird app，而是原生控件逝撬。那它是怎么實現(xiàn)的呢浴骂，react-native的原理如下圖：
原理上看react-native在js端和java端互相有個映射關系，通過兩端的配置表來實現(xiàn)宪潮，java端和js端持有同一張表溯警，通信時靠這張表的各個條目的對應進行的。上面提到了facebook實現(xiàn)了組件讓開發(fā)者調用狡相，就是通過js的配置表調取原生控件梯轻，java調用js也是類似的情況。所以當我們使用復雜控件時谣光，可以自己實現(xiàn)java代碼檩淋，添加入配置表中，即可自定義心新的映射關系萄金，讓我們js調用自定義的復雜控件 , 當然web 蟀悦、ios、androi需要實現(xiàn)不同的控件代碼氧敢，只是js端的調用代碼一樣或者類似日戈。
react-native的優(yōu)點：不用webview,擺脫了webview的交互和性能問題；有較強的擴展性孙乖，java端提供了基礎控件浙炼，js可以自由組合使用也可以自定義組合控件；
react-native的缺點：組件不全唯袄，第三方組件也不全弯屈，遇到某些特殊功能，需要花大力氣寫恋拷；性能方面也無法媲美原生资厉，還是有一些損耗，特別是交換大數(shù)據(jù)時蔬顾；IOS版本略好宴偿，androi發(fā)展較慢湘捎；ios和android代碼并非通用，有可能需要維護兩套代碼或者在代碼中做一些判斷窄刘；開發(fā)人員還是需要會原生開發(fā)窥妇，不然自定義組件無法編碼；
個人感受娩践，react-native不是萬能藥活翩，只是一種高效的解決方案，不要期望它解決所有的問題欺矫，要不要使用需要場景衡量纱新；客戶端轉開發(fā)react-native感覺比較簡單，比較JS大部分人都有基礎穆趴，前端人員開發(fā)react-native理解原生部分的代碼應該十分困難脸爱；相比原生海量的第三方控件和第三方包，react-native大部分道路還得靠自己摸索未妹；不同端的代碼風格和結構大體類似簿废，但具體標簽可能會不一樣；目前得到經(jīng)驗是IOS版本比較穩(wěn)定络它，android版本還不太成熟族檬，android 版本2015年下半年發(fā)布，一直在0.*版本上更新化戳，android1.0版本還沒有發(fā)布单料；把把facebook的第三方包網(wǎng)絡連接包okhttp和圖片下載解析包fresco等一起封裝進結果，造成包增加7点楼、8M扫尖，但據(jù)了解這是可以修改的；只支持IOS7以上和android4.1以上機型掠廓，這應該不成問題换怖，比較其他屬于少數(shù)；聽說qzone使用了react-native蟀瞧，但是crash率前10沉颂，react-native占8個，前5全是react-native悦污，但是我一朋友項目使用過react-native铸屉，雖然有坑，但是不會有如此多crash;
總結：新技術切端，開發(fā)環(huán)境和代碼編碼方面都比較艱澀抬探，有可能有很多坑，但是在界面簡單帆赢，三端都要求小压，開發(fā)成本需要降低情況下可以使用react-native。
最近在學習react-native椰于，以后可能會有新感受怠益，公司內(nèi)部最近可以找個項目實戰(zhàn)一下。
