您好,登錄后才能下訂單哦!
轉載本文需注明出處:微信公眾號EAWorld,違者必究。
引言:
隨著移動端對用戶體驗要求越來越友好,以及企業對代碼能夠跨平臺執行的迫切需求。React-Native因此應運而生,從出生就一直備受關注。
開發周期的縮短,開發成本和維護成本的降低,簡單的代碼熱更新機制等優點被各大中小企業所鐘愛。活躍的社區服務,以及豐富的三方插件都為React-Native注入了強大的生命力。本文將和大家一起找尋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大概的發展歷程如下:
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+星星的項目。社區的組件得益庫也已經比較豐富,社區活躍度比較高。對于很多復雜的組件,我們都不需要重復再去造輪子。
案例一:三個月重構兩個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這門技術。
現在很多游戲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,數據治理,移動架構原創技術分享。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。