React-native如何變爲移動端的弄潮兒

轉載本文需註明出處：EAWorld，違者必究。

引言：

隨着移動端對用戶體驗要求愈來愈友好，以及企業對代碼可以跨平臺執行的迫切需求。React-Native所以應運而生，從出生就一直備受關注。 

開發週期的縮短，開發成本和維護成本的下降，簡單的代碼熱更新機制等優勢被各大中小企業所鍾愛。活躍的社區服務，以及豐富的三方插件都爲React-Native注入了強大的生命力。本文將和你們一塊兒找尋React-Native如此火熱的起因。

1、React-native的發展

衆所周知，React-native是由Facebook開源的一門技術。它的出現也是經歷了種種嘗試與摸索。Facebook在客戶端2.0版本的時候，將主要頁面使用web來實現。

網上得知：大約是在2011年，android還在2.3版本、ios還在5.0版本。當時手機硬件和軟件優化相對比較差，用戶體驗一塌糊塗、怨聲載道。Facebook無奈只能換成原生來實現。Facebook做爲混合應用開發的先驅和探索者，此次失敗爲React-native的孕育種下了但願種子。失敗是成功之母，這句話說的一點沒錯。React-native想法的出現大約是在2013年一個極客大會上提出的。2014年7月Facebook本身開始實現並嘗試使用該項技術，一直到2015年3月份，React-native的ios版本橫空出如今世人眼中，同年9月，React-native的android版本也相繼亮相世人。React-native大概的發展歷程以下：

2、React-native使用案例

RN較H5而言，有如下優點：



1.頁面加載速度：React-native號稱是99%接近原生體驗，它是寫js代碼，映射原生去渲染頁面，頁面渲染速度和原生是差很少的。可是H5就不同，特別依賴手機的硬件配置，ios對H5應用的支持還能夠，可是安卓就差太多。安卓裏面一些高端機型運行H5應用還能夠，可是大部分機型都是會有點卡頓，尤爲是像加載圖片這種比較消耗資源的操做，H5的頁面渲染速度和React-native就會有很明顯的差異。

2.機型適配：例如H5對於如今的iPhone x劉海屏的適配就比較麻煩。還有對於不少安卓機型H5並不能作很好的適配。

3.動畫效果：H5的動畫是經過css和js實現的，對於一些複雜的動畫實現相對是比價困難的，也是比較消耗內存的。React-native自身提供了實現動畫的API，若是爲了過於追求動畫的流暢度，React-native還能夠藉助原生去實現，原生封裝出來空間來供給React-native使用。

相對於原生來講，RN也是具備優點的：



1.熱更新：作移動開發的都知道，蘋果的審覈一直讓你們很頭疼。原生對於緊急的業務開發完成以後，還必須等待蘋果的審覈才能上線，這個時候React-native就體現出來它的優點，在不碰及原生代碼的時候，能夠直接經過熱更新js代碼來實現實時發佈。React-native能夠很好的支持線上業務功快速迭代和隨時更新發布。

2.開發效率：React-native有20%的代碼是原生代碼，80%的代碼爲能夠複用的js代碼，這樣大大縮短了開發週期，爲企業節省了發開成本。

3.維護成本低：若是業務僅僅涉及到js代碼的修改，在APP開發需求少的狀況下，一個React-native工程師就能夠很好的維護本該APP，同時又爲企業節省了維護成本（即便剛開始該工程師不會原生開發，可是通過長時間的鍛鍊，或多或少都會一點）。

4. 學習成本低：React-native使得以前作前端的工程師能夠快速的參與APP的開發，下降了學習成本。

5. 擴展性強：React-native提供了自定義原生控件以供js調用渲染的API，這使得它的擴展性極其強大。

此外，RN還具備其特殊的背景優點：



1.React-native做爲Facebook的「親兒子」，依靠這棵大樹，讓這個技術一直在不斷的完善。

2.React-native自己是開源的，全部的源代碼都是能夠看到的。React-native從開源道如今就備受關注，React-native是歷史上第一個沒到正式版本，github卻有7w+星星的項目。社區的組件得益庫也已經比較豐富，社區活躍度比較高。對於不少複雜的組件，咱們都不須要重複再去造輪子。

3、React-native使用案例

案例一：三個月重構兩個APP




當時公司在進行後臺重構的同時，CTO也打算把APP使用React-native進行重構一遍。我一個作安卓的和兩個ios的一塊兒邊學邊作，摸着石頭過河，咱們用了三個月時間完成APP重構。主要功能涉及到聊天，微信分享等業務功能。而後由於特殊緣由本身離開，APP由兩個ios進行維護以及新功能迭代（本身在走以前教會ios同事安卓的打包和發佈）。再到後來另外一個ios同事也離開作前端去了，就剩下一我的。在公司需求少的狀況下，他一個維護這個APP已是綽綽有餘（藥店幫手）

案例二：使用RN效率提高


在兩個APP開發人員，開發維護三個APP，而且公司的需求迭代特別頻繁的背景下。若是沒有使用React-native這個技術，公司一個月的需求我評估使用原生兩我的最少須要兩個月，甚至更長。可是使用React-native以後，任務是兩我的均攤的，而且彼此的代碼均可以看懂，這大大加快咱們的開發速度。

那麼，企業選擇RN的緣由有哪些呢？我認爲有以下幾點：



使用React-native以後，代碼更新方便以此來知足緊急。當業務需求少的時候，APP較少的人員就能夠維護。

隱藏價值：若是公司使用React技術棧，那麼前端人員通過較短的學習時間就能夠快速參與到APP開發當中，一樣APP開發人員通過較短期學習就能夠進入前端開發中，這樣極大的對人才進行了複用。這就是爲何那麼多小公司如此鍾愛使用React-native技術進行APP開發。極大的縮短了開發週期短。

同時也有一部分大公司使用React-native和原生進行混合開發，React-native頁面嵌在原生裏面。我我的以爲他們這作的緣由是：對於常常需求修改的頁面使用H5體驗又很差，使用原生熱更新比較困難，結合這兩點，React-native就理所固然的成了最好的選擇。


固然，也不能盲目選擇，應該辯證的看待RN。咱們上面列舉了那麼多React-native的優勢，可是並不表明咱們就能完徹底全拋棄原生。React-native並非一個完美的技術方案，它也有其自身的缺點。因此對於React-native技術選擇，須要企業考慮學習成本，開發成本，維護成本，以及企業自身的業務等等實際狀況來評估是否選擇React-native這門技術。

4、展望

如今不少遊戲APP都開始使用React-native來作殼。一些大公司也在逐步將一些業務使用React-native來替換。React-native依靠Facebook這個親‘爸爸’，版本迭代特別快，也一直在不斷完善中。

Facebook如今的口號是：
Learn once，Write anywhere。
我認爲會有那麼一天實現
Write once，run anywhere。

 

關於做者：範濤，普元React-native開發工程師，畢業於長沙理工大學，專一於使用React-native開發APP，負責太平洋保險APP內部保險箱務RN改造業務。


關於EAWorld：微服務，DevOps，數據治理，移動架構原創技術分享。長按二維碼關注！