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