同步自個人博客css
去年三月份,以及十一月份,我分別作了兩個React Native
(下稱RN
)的項目,一個是一個很簡單的充值頁面,發上線之後就基本不維護了,暫且不表;另外一個是把咱們客戶端首頁的技術方案由Hybrid
遷移到了RN
,跟進並維護了幾個版本之後,又決定切換回了Hybrid
的方案,如下記錄一下我這段時間的心路歷程以及我對RN
的見解。前端
咱們首頁遷移RN
主要有如下幾個緣由git
公司的架構組對RN
的支持度比較高,有一個比較完整的解決方案,包括打包體積的優化,封裝了redux
和路由,方便業務方的開發github
咱們的前端代碼優化力度不夠,bundle
的體積很大,首屏會比較慢,在Android
的WebView
裏尤爲明顯,並且代碼時間也比較久,想要拆包優化也須要大量的時間去測試,而後以前作的RN
項目幾乎是秒開,給了咱們很大的誘惑力。web
前端的框架是React
,前期調研了一下以爲切換的成本很低,這是咱們最終決定遷移RN
的緣由,也是咱們預估的最失敗的地方,遇到的問題我在以前的博客裏有提到過。redux
就像我以前的博客所說,我花了大概20天的時間作了此次遷移,其實真正估時的時候並無這麼久,主要是在開發上踩了一些坑,項目最終上線後的效果也很棒,首屏的渲染時間快了不少,尤爲是Android
,就當咱們爲此慶祝而且準備繼續遷移的時候,問題慢慢展示出來了。架構
主要的矛盾在於要維護兩個工程。框架
我們的首頁既要服務於Touch
端,又要服務於客戶端,以前的客戶端是Hybrid
方案,矛盾並不突出,只須要在個人前端代碼裏對客戶端作一些特殊處理便可,可是遷移RN
之後咱們就須要維護兩套代碼了。就像我以前說的,咱們過於樂觀的以爲,從React
的代碼到RN
其實並不須要作過多的轉換,甚至考慮着本身寫一套轉換的腳本,實現無縫對接,現實倒是來了當頭一棒。佈局
好比,css沒法複用,Android
下的overflow:visible
就是不可用的,好比不支持百分比佈局,好比不支持fix
,致使咱們在兩邊的切圖仍是不能使用一套方案。測試
又好比:加大了需求開發的成本和時間,好比PM有一個需求,單作前端可能2pd,算上RN
可能就是3pd,對於一個創業團隊會拖慢本身的進度,並且只能找有Mac的同窗來作這個需求 = =。
就不說調試難,以及開發一些需求的時候須要請教客戶端的同窗是否支持而後去找對應的方案了。而若是是Hybrid
的方案,只須要web
和native
討論好接口,分別開發便可。
最終,在維護了幾個版本的RN
後,我又毅然的將方案改回了Hybrid
這是一次失敗的嘗試,卻不是一次無用的嘗試,在我看來,React Native
是一項很是棒的技術,咱們不須要針對客戶端開發兩套代碼,並且總體體驗是優於Hybrid
的。可是我仍是以爲採用這項技術以前你們要考慮清楚,我我的以爲,對於大公司的大團隊,業務需求不是特別緊的團隊,都很適合採用這一項技術,對於咱們反而是不太合適了。
通過這件事我對技術選型也有一些思考。技術選型時,應該選擇根據本身的團隊,本身的需求,花費不少時間調研之後再去決定,而不是選擇一些火的方案。好比咱們以前移動端選擇使用React
,就是以爲之後仍是要作本身的客戶端,用了React
之後切換RN
會是一件很小成本的事,結果如今仍是採用的Hybrid
方案。如今又由於React
包體積很大,不得不對項目再作一些優化。
但願你們在選擇RN
時,也考慮清楚,我是否對Web
的需求很低,我是否有很強的跨平臺需求,個人技術人員是否能夠hold住一些場景等等,而不是由於它很火選擇它。