去年把公司幾個react native 相關的專案升級了下，已經過去一段時間了，這裡系統整理下之前的整個過程。

背景

之前到公司的時候發現公司用的還是0.40的版本，據瞭解，當時專案做的比較早，導航用的是自帶的路由庫，狀態管理用的是 mobx。到公司之前雖然有react native的相關經驗，不過當時官方已經推薦用 react-navigation 替代原來的導航庫。以前的專案比較小，也沒用到狀態管理，react-native-code-push也沒有用過，只是瞭解過一些。

剛開始接手專案的時候還是比較痛苦的，業務邏輯相比之前的複雜不少，有些程式碼並不完全知道是什麼意思，動也不敢動。不過經過一段時間後，基本上也算是熟悉了react native

周邊生態. 連著做了好幾期需求後算是大致明白了，幸好當時不是createClass的舊寫法，不然改造起來更麻煩了。

因為用的版本比較早，而安卓高版本又做了一些限制，這導致有時候除錯起來比較麻煩，我自帶的舊手機因為系統版本比較低（Android 6.0），成了唯一的測試機（版本高一點的沒法搖一搖進行除錯）。

這卡得不要不要的手機，讓我既愛又恨。愛是因為可以除錯，不用像iOS一樣IP地址變了還得打包，恨是因為，除錯非常話費時間， 你有時候都可以看到頁面在過渡的效果，如果你看過《瘋狂動物城》的話，你應該還記得那個樹懶。 react native 自帶的列表效能又不好，而專案裡面又不少用到列表的地方，複雜的業務需求讓導航庫難以使用，個人除錯也非常麻煩。

技術調研

因為涉及到的專案比較多，而且版本跨度又比較大，所以調研必須要更加認真、全面。

我把網際網路上近一年來關於react native的部落格文章全部看了一遍（谷歌+百度+GitHub +技術QQ群的方式），並針對性的蒐集了關於升級踩坑的博文，又把做rn以來收集到的相關技術部落格都翻開看了下。 儘量做到無死角全方面覆蓋網上目前所有相關的內容。

然後彙總了一篇 react-native升級調研文件，主要包括API變更，幾個重大更新的日誌、此次升級有關的重要點、涉及到的幾個庫、可能需要考慮的一些問題、參考資料連結（40多個）

 

版本升級

版本升級是首先需要考慮的問題，如果這個不定的話，其他的工作不方面開展，而版本升級又需要考慮多個方面：

• android和iOS使用者各個系統佔比是多少？如果安卓和蘋果低版本使用者太多的話，對rn版本的升級也會有阻力。
• react native本身版本變化如何？其本身的重構計劃進度如何？
• 第三方庫對react native版本有特殊要求？
• android和iOS方面的構建工具、IDE等是否有特殊要求？原生xcode/Android SDK 版本、安卓和iOS對應的版本號API號等，這些都是需要考慮的

經過實際調查以及和原生開發人員溝通，最終確定了要更新的版本。因為react native最新版本太新，很多第三方庫還沒有來得及更新，

第三方庫：

因為每個專案不同，用到的第三方庫也不一樣，但是在原生裡面的package.json是最全的，在挨個分析第三方庫的時候我發現有些庫可能最初用到了，因為業務變化，後來又沒有用到，便將那些沒有用到的庫全部刪除，這樣可以縮小查詢範圍，減少工作量。寫文件《react-native 各專案配置情況》

接下來是把當前所涉及需要更改的專案使用到的包的最新版本，做一個情況說明表，包括名稱、版本、地址（方便其他人及後續檢視）、重大更新等內容。大部分都還好，只有個別庫停止維護， 有些由原來的API改為分離出來的第三方庫，還好用法基本上沒有發生大的改變。

專案熟悉

因為主要是經常改動的那個專案自己平常接觸得比較多，程式碼基本上都熟悉了，其他的幾個專案找測試要相關的賬號，找產品負責人瞭解產品需求，大致跑了一遍之後，也基本上熟悉了程式碼邏輯。

早期程式碼因為各種原因，有些重複的地方，還有些可以改進的地方，這個在我得知react native需要升級的時候便開始著手優化程式碼了。刪除無關的程式碼，添加註釋，抽取公共樣式元件等，就當順帶全面熟悉這個專案的程式碼。 這樣的好處是後期升級的話不需要更改那麼多程式碼，也順手簡化了程式碼。

demo初試

為了保險起見，在確定react native版本後，先寫了一個包含所有第三方庫的最小demo，每安裝一個庫，就寫專案中用到同樣功能的程式碼，保證基礎功能實際可行，並在每一個功能完善之後提交程式碼到倉庫。

這樣一來，如果新安裝的那個庫因為更改程式碼錯誤導致無法執行APP的話，還可以及時回到上一步。這種情況尤其容易發生在更改android資料夾程式碼的時候，畢竟日常大部分時間都在改JavaScript程式碼，好多剛接觸react native時候踩過的熟悉的坑都忘記得差不多了。

在功能基本上可行之後，在安卓和蘋果手機各自大致運行了下，沒有什麼大的問題，便開始著手正式更改程式碼。

程式碼編寫

在升級之前，建立新的分支，升級期間新加的需求也暫時不同步更新（新舊功能同時做），待升級結束，一併更新。

寫專用的程式碼替換文件，方便其他開發參考，減少工作量。在文件中寫了新舊程式碼對比，如導航的跳轉傳參、引入方式的變化等，可以直接刪除原始碼，複製貼上新程式碼。

這裡既包括幾個通用的替換，還包括幾個可能的坑，比如React Native中的圖片元件載入靜態資源，圖片名稱含有@2x或@3x報錯 。

資訊同步

此次升級和原生端密切相關，資訊的同步非常重要。

在將0.40到0.59直接的版本更新日誌全部看了一遍後，整理成文件，將重點部分標註，讓原生那邊大致看下有無跟他們關係比較大的地方。有些地方並不是非常懂，需要對方去做個大致的判斷。

升級期間及時更新文件，提供所有可能用到的文件。並將整個調研中所有相關文件更新到公司知識管理平臺。

測試

列出幾個專案中更改到的地方，方便測試重點測試相關的功能。重要功能無誤後，測試各種機型，然後就是修bug。期間有遇到一些問題，不過還好，遇到問題多了，大致能看出來是什麼情況。

總結

一開始還是比較擔心的，畢竟涉及專案比較多，而且版本跨度這麼大，在網上看到的基本上都是小幅度的版本升級。

這次因為整個升級時間比較充足，前期調研準備也比較充分，倒沒有出現比較嚴重的耽誤進度的事情。就是專案業務邏輯比較多，在更改之後有個別小地方被遺漏了，後期才發現這些隱蔽的bug。

總體來說，基本上更改的程式碼量不是特別多，集中在 react-navigation 路由彙總、跳轉傳參，以及Flatlist等地方，在和iOS、android等聯調方面也花費了不少時間。

因為疫情的緣故，不得不在家辦公，但是APP照常更新，這讓本來沒打算更新升級過的程式碼不得不隨著更新，期間有些臨時發現的bug因為環境不同調試起來比較麻煩。

之前在網上查找了不少文件，多謝網友的分享，這裡也總結下自己遇到的情況，希望對大家有所幫助。

 

相關推薦