RN開發筆記-背景和思考

同步自個人github

最近花了大概一個月的時間，對咱們以前的一個hybrid項目進行了React Native(如下簡稱RN)改造，中間踩了很多坑，也學習到了很多RN的知識，準備寫幾篇文章記錄一下這一段時間的收穫，由於公司有專門的平臺組作RN的打包構建以及優化，我會更側重於業務來聊一下。

這是第一篇，想大概講一下背景以及項目中遇到的一些問題，後續會就一些問題作深刻的分析。

項目背景

爲何要作此次改造

咱們是公司內部的一個創業項目，以前的移動端頁面已經穩定運行了一段時間了，最近在作本身的app，原本是先用的hybrid的方案，運行了一段時間後發現了一些問題

1. 項目設計問題，只有一個js包，100K+，在一些較爲低端的安卓機裏首屏很慢，即便咱們用了離線包的機制，有的安卓機任然須要2-3s花在js的parse上

2. native開發人手不夠，咱們只有兩個客戶端的開發人員，若是用原生開發的話無法進行快速的開發迭代，並且咱們的迭代很快，客戶端的發版頻率已經徹底不能知足咱們的需求了

3. 體驗很不native，有一部分性能問題，安卓下的iScroll，動畫等等會丟幀；對於原生的掌控很弱，好比我想設置狀態欄，獲取一些設備信息，都是須要native的同事作一些橋的開發，致使兩邊都有開發成本

爲何選擇RN

1. 以前有過一個簡單的RN項目的經驗，總的來講我以爲不管是開發效率仍是體驗上都是能夠接受的（固然此次的項目比上次的複雜許多，證實我仍是太天真了）。

2. 客戶端人員不夠，無法進行快速的開發迭代。

3. 以前hybrid的是用react+redux進行的開發，組內討論過以爲客戶複用大部分的邏輯，能夠儘量快的迭代上線。

4. 公司的平臺部門已經幫咱們作好了打包構建的流程而且已經作了一些優化，會將RN的代碼統一打到客戶端裏，咱們只須要關注本身的業務，並且他們在RN的基礎上進行了二次封裝，已經幫咱們規避了一部分iOS和Android的差別性。

所以，咱們決定先用RN來先作首屏的改造，打算先看一下效果，後續再決定是否繼續遷移

項目中遇到的問題

• 切圖不是很習慣

RN實際上是用了一套cssLayout，雖然語法是css的而且對flex有很好的支持，可是不少屬性還不支持，好比fix，好比overflow:visible在安卓下是不支持的(致使最後我真機測試的時候花了兩天返工從新設計)，不支持百分比等等，其實有的時候很難用css那一套的思路去切圖，最終花在切圖上的時間並無想象的那麼少。

• 自定義輸入框和鍵盤的設計

由於咱們涉及到一些自定義的鍵盤，好比車牌的省份，好比限制一些鍵的錄入，在RN上咱們但願沿用這一套方案，可是由於事件系統，手勢系統，一些DOM中的api在RN中沒有相似的實現，致使咱們無法複用以前的那一套方案，這個我會單獨寫一遍去分析。

• debug困難

遇到過幾回報錯是在native的代碼裏，致使我很難定位問題，由於我沒有原生開發的經驗，有時候只能麻煩客戶端的同窗幫忙去看是哪裏的問題

• 原生組件的使用問題

好比有的組件只有Android有，有的組件只有iOS有，而後平臺的同事以前又沒有開發，致使我不得不給另一個平臺開發一個組件；又好比像Picker，Android和iOS徹底是兩種調用方式，我又不得不爲了抹平個人調用差別而作一次上層的封裝

總結

前先後後我大概作了20天，總的來講沒有以前想象的順利。咱們團隊內部也就RN作了一些思考。
首先，咱們以爲對於開發一個native的應用，RN確實是一個很棒的方案，相比於native和hybrid來講都有不小的優點，對於大公司來講，若是有專門的團隊來作RN的打包構建以及優化，各個部門只須要考慮本身的業務的話，很是值得嘗試一下。可是對於小的團隊，創業團隊，若是人手不是很充足的話，我不是很建議去用RN進行開發，hybrid反而是一個最優解，畢竟RN目前還不是一個穩定的方案，須要有人去跟進RN，包括優化。

後續我會根據我此次遇到的一些問題作一些深刻的分析與梳理