去年把公司几个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因为环境不同调试起来比较麻烦。
之前在网上查找了不少文档，多谢网友的分享，这里也总结下自己遇到的情况，希望对大家有所帮助。
