30天React Native從零到IOS/Android雙平台發布總結

標籤：

前言

本人有近十年的技術背景，除了APP開發之外對後端、前端等都比較熟悉，近期做一個APP項目需要IOS、Android兩個平台都需要，只能硬著頭皮上。其實很早就想開發APP也很早就接觸Android、IOS原生開發、Hybrid、HTML5 WebAPP等開發但一直也沒有做一個完整的項目，更多隻是技術上的驗證和嘗試。這回利用這個項目機會成功的基於RN技術發布了IOS和Android兩個平台的APP，項目周期由於IOS審核（第一次提交審核，修改了四次才通過）和自己假期的時間用了一個半月，實際用於項目代碼的開發大概是一個月的時間。

APP功能

由於是商業項目不能透露太多資訊，APP功能包含列表頁、搜尋網頁、HTML5遊戲、HTML Web頁面還有圖片的應用，以下為應用介面。如需APP進行測試請加留言或者發我郵件：cbcye#live.com

 選型

       之前說過我有一個定的技術背景也嘗試過各種不同的開發方式。基於APP的功能需求我可以都採用原生的方式或者Hybrid的方式或者HTML5的方式。首先，由於IOS和Android都需要發版而且我也沒有時間從零開始學習IOS和Android的開發其實之前也嘗試著學習但最大的問題基於是這兩種原生方式的介面布局給我最大的障礙，語言、文法對一個有經驗的程式員來說問題不大，一般來說像UI布局文法和架構是最大的門檻。其次對由於有一些原生操作硬體的介面需求所以也沒有採用純HTML5 WebAPP的方式。

       重點介紹Hybrid的開發方案, 幾年前接觸過PhoneGap+JQuery Mobile、Sencha Touch學習了一段時間還有嘗試PhoneGap+JQuery Mobile做一個小的內部應用，但由於在PhoneGap+JQuery Mobile在Android下相容問題太多放棄了；Sencha Touch封裝得太厲害；Ionic使用的Angular JS學習了一段時間還是不能順手所以也放棄了（所以說架構的學習成本其實要高過於語言本身）還有一點最重要的是這些Hybrid產品或架構封裝的太封閉了導致如果有問題的話你就很難去解決。這就是我為什麼這次選型放棄這些Hybrid方案的原因，當然這些經驗最近的也是一年前了，早的還是四、五年前的印象，了不一定符合再在情況，但由於也沒有更多的時間瞭解所以就先放棄了。

 最後無意中搜尋到React Native讓我眼前一亮，RN的介紹自己去搜尋一下，我這裡只講我選型的考慮：

1、RN是Facebook的項目，一個開源項目有大團隊的維護是相當的重要

2、RN採用的方式是在JS去調用原生模組的方式理論上來說一般情況下效能應該比較接近原生（這一點在一些測試報告上也有相應的說明），當然這種方式的工作量非常龐大。

3、社區太活躍了，官方版本兩周發布一次，在開發過程中的問題也能有人及時解答

另外之前沒有用過這相架構有足夠的好奇心，試了一下感覺還可以，試著試著就到發版了。

開發過程如何入門

     俗話說磨刀不誤砍柴工，但是做一個項目其實也沒有太多的時間來讓你好好學習技術，所以就需要快速入門，還好有一大波前輩已經整理出來學習筆記和分享了，對我來說協助最大的是東方耀老師的視頻系列(免費版），兩天看了50集基本上JSX文法+RN的基本知識就算掌握了，另外還購買了RN中文網一個月的付費群服務(90元/月），主要有技術坑的時候等社區的人回答效率是很低的，特別是剛開始的時候有專家幫忙解答一下會節省很多時間，後來也確實證明非常有效。最後在開發過程中還花了300多RMB購買了一個印度團隊的Native Starter Pro作為開發架構和UI架構，有時間也可以基於他們免費版的Native Starter Kit來開發，不過這個主要是節省了Redux的學習時間，直接上架構立馬能用即使我不知道Redux是如何工作的。

開發方法

開發方法也很重要，由於是使用新技術很容易出現一個問題解決不了的話就有可能要放棄該技術或者某個方案，我在之前就嘗試用RN做一個WebView的架構封裝但是在涉及到原生WebView與JS之前的通訊還有調用手機的一些功能比如儲存圖片到相簿和選擇相簿圖片由於那個時候對RN不熟悉就只能放棄全部基於WebView的方式來做。而且有可能一個功能需求用IOS的技術方案實現了但是在Android下卻不支援或者遇到問題的時候能不能解決，該項目過程中就遇到Android中WebView效能低且片段化嚴重的問題。

所以正確的開發姿勢是針對重點功能做技術驗證而且分別是對IOS和Android兩個平台都做，而不是急於按照功能模組來進行開發。然後再一步一步夯實功能模組。如果功能技術驗證通過了先完成IOS版本再做Android版本（乘著審核的時間做Android版本）。

那些技術坑

1、ListView效能問題

ListView效能問題之前在做驗證的時候沒有感覺，但是把資料往上加的時候就出現了，如所示帶圖片、標題、描述和按鈕的清單項目，在300條資料的時候就會出現非常卡的情況IOS比Android更嚴重經嘗試各咱辦法無效只能在需求上做調整將資料減少到50條，以獲得較好的體驗。在項目中臨時使用SGListView替代官方的ListViwe。目前這個問題到RN 0.33版本還未解決,暫時也沒有從原生源碼的方面去著手解決等著官方出解決方案（官方已經提上議程了）

 

2、IOS載入圖片問題

由於RN都是靠一個JS主進程在跑因此在APP第一次啟動後載入網路資料和圖片的時候並不能一次性全部顯示只能一個個顯示甚至好長時間才能顯示全部圖片，而且這個問題在IOS上比在Android上更加明顯。這個問題暫時也沒有解決。

3、效能問題

關於效能問題強烈建議先閱讀官方文檔關於效能的最佳化建議再來說效能好不好的問題，特別是文檔中提到的使用InteractionManager.runAfterInteractions回調的方式來處理耗時任務使UI不明顯卡鈍效果非常有效，不要在調試的時候去測試效能，在IOS下可以使用release模式來測試效能。

4、WebView效能問題

WebView由於在項目中有大量的情境需要用到因此也是重中之重，IOS上該問題小一點，除了在開發期間覺得內建的WebView佔用記憶體大之外（實際Release版本記憶體佔用可以接受）別的倒是可以接受，當然在IOS上也可以使用wkwebview來替代，但是由於當時不會擴充JS讀取WKWebView的頁面Title屬性（即時不是剛載入完成的Title）,因此只能使用預設的webview。

但是WebView的問題在Android平台上變得突出起來，後來沒有辦法只能通過封裝Crosswalk Xwalk webview的方式來提供並結合：react-native-crosswalk-webview和react-native-webview-bridge 兩個項目在crosswak webview的項目上擴充增加了讀取webview當前Title的方法（之前還走過彎路想變更webview-bridge使用crosswalk的webview但複雜度高失敗就放棄了。）

5、應用程式套件大小

IOS打包完成的時候包大小是十幾M，感覺能接受而且當時要儘快提交給蘋果審核所以沒花時間最佳化，帶熱更新功能。

 

Android的apk包由於封裝了crosswalk變得包異常大，arm和x86兩個版本的包為52M左右，只編譯arm版本的包為27M，如果沒有封裝crosswalk的話包大小隻有5.3M左右（刪除了無用的字型和最佳化了圖片），說明RN的包大小是可以接受的。

 總結

在這開發的一個月時間裡其實有很多次都想擔心會遇到無法填完的坑而失敗，好在這個架構比較給力基本上你只需要學習一部分知識就可以解決具體的問題而不是全部都要學習。由於我沒有做過原生的開發所以沒有像一部分原生程式員對Hybrid架構那麼“吹毛求疵”，也沒有像一部分前端程式員覺得學習成本太高曲線太陡。只是做為一個使用者來講用RN開發的程式體驗能打個70分，做為一個程式員來講RN的理念如果你想IOS和Android兩個平台都複用代碼的話我覺得是比較不錯的思路和架構了，本項目自主寫的代碼複用在90%以上。

所以強烈推薦你的下一個APP採用RN來進行開發！

30天React Native從零到IOS/Android雙平台發布總結