本人負責的APP項目即將搭建團隊啟動開發(fā)了酬土，現(xiàn)在糾結了，到底是原生還是h5格带？
領導們也在過問這個抉擇撤缴，
考慮到APP項目的穩(wěn)定性、擴展性和高性能的要求叽唱，其中的推送功能屈呕、離線功能、本地存儲棺亭、數(shù)據(jù)交互較頻繁且量較大的因素虎眨，技術選型的問題

原生開發(fā)模式

原生的缺點

• 開發(fā)成本高，不同平臺需要定制不同的app，開發(fā)人員需要多平臺多語言嗽桩，人力成本岳守、時間成本較多，通用性差碌冶；
• 上線時間不穩(wěn)定湿痢，需要審核，特別是蘋果審核機制扑庞，審核時間長短不一譬重，對內(nèi)容還有控制，國內(nèi)Android APP市場也有類似的問題罐氨；
• 版本控制能力差臀规，版本發(fā)布到達率無法控制，多個版本更新發(fā)布栅隐，修復bug塔嬉，無法保證及時送達到用戶手中；獲得新版本需要重新下載安裝租悄，雖然目前有增量升級方式逐漸改變邑遏，但是隨之而來的其他問題如增量升級多版本控制也是個很頭疼的問題

原生的優(yōu)點

原生開發(fā)依然是開發(fā)者采用最廣泛的開發(fā)方式，優(yōu)點十分顯著恰矩。相比其他開發(fā)方式而言：

• 原生開發(fā)可以訪問設備中的所有功能记盒，運行速度更快，性能更高外傅，而且可以啟用優(yōu)秀的離線處理和存儲能力等等纪吮，提供最佳的用戶體驗，最優(yōu)質的用戶界面萎胰，最華麗的交互碾盟。
• 原生開發(fā)人員眾多，開發(fā)環(huán)境成熟技竟，有許多的開源庫提供開發(fā)人員調(diào)用冰肴，可是方便實現(xiàn)各種設計效果。

H5開發(fā)模式

H5開發(fā)是Html5開發(fā)的app榔组，本質上運行在手機瀏覽器中的頁面熙尉，一般使用app做一個殼套用瀏覽器運行H5的頁面，由于H5的特性也有很多app使用半原生半H5的hybird app 開發(fā)模式搓扯。

H5優(yōu)點

H5有許多優(yōu)點检痰，特別針對原生開發(fā)的缺點。

• 直接在網(wǎng)頁上調(diào)試和修改锨推，幾乎不用考慮用戶機型和適配的問題铅歼，針對原生開發(fā)的平臺碎片化公壤、開發(fā)人力成本、時間成本高椎椰；
• 版本升級優(yōu)勢厦幅，網(wǎng)頁的升級與用戶無關，用戶無需下載更新安裝慨飘，保證實時送達到用戶手中慨削；
• 上線時間穩(wěn)定、快速套媚，不需要通過開發(fā)市場的審核，有收入分成的開發(fā)市場更是可以繞過收入分成磁椒。
• 除此以外在視頻媒體方面H5表現(xiàn)也十分優(yōu)秀的堤瘤。

H5的缺點

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)頁的缺陷它無可避免今膊。
• 最大的問題是性能問題，這才是H5伞剑，原生開發(fā)對性能的支持遠超H5斑唬，在用戶體驗上，H5的app絕對是占據(jù)下風的黎泣，app反應速度恕刘、流暢度等
• 功能擴展與調(diào)用性能問題，對某些硬件攝像頭抒倚、陀螺儀雪营、麥克風等硬件支持較差，頻繁調(diào)用這些硬件衡便，H5不容易擴展献起，調(diào)用速度也不如人意洋访。

原生 VS H5的總結

目前許多app都采用hybird app 開發(fā)（微信、支付寶等等）谴餐，在h5適合的地方展示姻政，在其他地方使用原生開發(fā)，以規(guī)避缺點岂嗓，發(fā)揚優(yōu)勢汁展。
純H5 app適合小游戲、媒體厌殉、視頻食绿、營銷產(chǎn)品、介紹等功能公罕，大部分大型app屬于原生器紧、H5混合的hybird app。

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強調(diào)的是“l(fā)earn once,write everywhere”蔗崎，應用前端使用js和React來開發(fā)不同平臺的ui酵幕，下層核心模塊編寫復用業(yè)務邏輯代碼，提高應用的開發(fā)效率缓苛。

react-native的原理

react-native的優(yōu)點和H5類似芳撒，跨平臺、低成本開發(fā)未桥、開發(fā)速度快笔刹、動態(tài)發(fā)布、一套類似代碼維護三個平臺冬耿。代碼結構如下圖：

image.png

• 程序結構上舌菜，有兩個工程分別是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的原理如下圖：

  
  
  image.png
  
  

  原理上看react-native在js端和java端互相有個映射關系栅表，通過兩端的配置表來實現(xiàn)，java端和js端持有同一張表师枣，通信時靠這張表的各個條目的對應進行的怪瓶。上面提到了facebook實現(xiàn)了組件讓開發(fā)者調(diào)用，就是通過js的配置表調(diào)取原生控件坛吁，java調(diào)用js也是類似的情況。所以當我們使用復雜控件時铐尚，可以自己實現(xiàn)java代碼拨脉，添加入配置表中，即可自定義心新的映射關系宣增，讓我們js調(diào)用自定義的復雜控件 , 當然web 玫膀、ios、androi需要實現(xiàn)不同的控件代碼爹脾，只是js端的調(diào)用代碼一樣或者類似帖旨。

react-native的優(yōu)點

• 不用webview,擺脫了webview的交互和性能問題；
• 有較強的擴展性灵妨，java端提供了基礎控件解阅，js可以自由組合使用也可以自定義組合控件；

react-native的缺點

• 組件不全泌霍，第三方組件也不全货抄，遇到某些特殊功能，需要花大力氣寫朱转；
• 性能方面也無法媲美原生蟹地，還是有一些損耗，特別是交換大數(shù)據(jù)時藤为；
• IOS版本略好怪与，androi發(fā)展較慢；ios和android代碼并非通用缅疟，有可能需要維護兩套代碼或者在代碼中做一些判斷分别；
• 開發(fā)人員還是需要會原生開發(fā)遍愿，不然無法開發(fā)擴展的自定義組件；

react-native總結

react-native不是萬能藥茎杂，只是一種高效的解決方案错览，不要期望它解決所有的問題，要不要使用需要場景衡量煌往；

• 客戶端轉開發(fā)react-native感覺比較簡單倾哺，比較JS大部分人都有基礎，前端人員開發(fā)react-native理解原生部分的代碼應該十分困難刽脖；
• 相比原生海量的第三方控件和第三方包羞海，react-native大部分道路還得靠自己摸索；
• 不同端的代碼風格和結構大體類似曲管，但具體標簽可能會不一樣却邓；

• 版本發(fā)布頻繁，一直是穩(wěn)定1.0版本下面beta的0.xx的版本號院水，意味著穩(wěn)定性是最大短板：目前得到經(jīng)驗是IOS版本比較穩(wěn)定腊徙，android版本還不太成熟，android 版本2015年下半年發(fā)布檬某，一直在0.*版本上更新撬腾，android1.0版本還沒有發(fā)布；

  
  
  image.png
• 聽說qzone使用了react-native恢恼，但是crash率前10民傻，react-native占8個，前5全是react-native场斑，但是我一朋友項目使用過react-native漓踢，雖然有坑，但是不會有如此多crash;
• 新技術漏隐，開發(fā)環(huán)境和代碼編碼方面都比較艱澀喧半，有可能有很多坑，但是在界面簡單青责，三端都要求薯酝，開發(fā)成本需要降低情況下可以使用react-native

最后個人總結：

• 安卓和蘋果自家的原生開發(fā)是整個APP的底層框架，或者說是基座爽柒，
  但沒有銀彈吴菠，不要指望一種技術通吃所有的業(yè)務場景，最完美的解決方案是取長補短浩村，結合具體的頁面場景來混搭：

• 穩(wěn)定性做葵、擴展性、適配機型和運行性能的高要求心墅，其中的推送功能酿矢、離線功能榨乎、本地存儲、數(shù)據(jù)交互較頻繁且量較大瘫筐，鄉(xiāng)下手機較低端或者領導高端機型的適配蜜暑，建議大家就別繞過原生，畢竟是平臺自家的原生開發(fā)才是親生兒子策肝，享有其他任何技術沒有的優(yōu)勢肛捍。

• 存在較多變更因素，可以采用H5或者React之众，比如需求未明確拙毫，需求變更較頻繁，比較鮮明的場景就是內(nèi)容發(fā)布棺禾，天天更新缀蹄，如果只是內(nèi)容變更，而樣式不變倒原生開發(fā)也是可以的膘婶；

• 具體技術場景相關業(yè)界標準的限制要求：自定義圖層的在線地圖缺前，openlayers+GeoServer就是H5的地圖開發(fā)標準，甚至是3D地圖的Cesium解決方案悬襟，肯定是不適合安卓和蘋果各自開發(fā)一套原生代碼衅码，但對于離線地圖要求，還是要選擇原生SDK的百度古胆、高德地圖肆良；