博客主机
A-A+

记一次 React Native 大版本升级过程——从0.40到0.59

2020年05月24日 JavaScript, 工作总结 记一次 React Native 大版本升级过程——从0.40到0.59已关闭评论
博客主机

去年把公司几个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 +技术群的方式),并针对性的搜集了关于升级踩坑的博文,又把做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,每安装一个库,就写项目中用到的同样功能的代码demo,保证功能实际可行,并在每一个功能完善之后提交代码到仓库。 这样一来,如果新安装的那个库因为更改代码错误导致无法运行APP的话,还可以及时回到上一步。这种情况尤其容易发生在更改android文件夹代码的时候,毕竟日常大部分时间都在改JavaScript代码,好多刚接触react native时候踩过的 熟悉的坑都忘记得差不多了。 在功能基本上可行之后,在安卓和苹果手机各自大致运行了下,没有什么大的问题,遍开始着手正式更改代码。

代码编写

在升级之前,建立新的分支,升级期间新加的需求也暂时不同步更新(新旧功能同时做),待升级结束,一并更新。 写专用的代码替换文档,方便其他开发参考,减少工作量。 在文档中写出了新旧代码对比,如导航的跳转传参、引入方式的变化等,可以直接删除源代码,复制粘贴新代码。 这里既包括几个通用的替换,还包括几个可能的坑,比如“React Native中的图片组件加载静态资源,图片名称含有@2x或@3x报错

信息同步

此次升级和原生端密切相关,信息的同步非常重要。 在将0.40到0.59直接的版本更新日志全部看了一遍后,整理成文档,将重点部分标注,让原生那边大致看下有无跟他们关系比较大的地方。有些地方并不是非常懂,需要对方去做个大致的判断。 升级期间及时更新文档,提供所有可能用到的文档。并将整个调研中所有相关文档更新到公司知识管理平台。

测试

列出几个项目中更改到的地方,方便测试重点测试相关的功能。重要功能无误后,测试各种机型,然后就是修bug。期间有遇到一些问题,不过还好,

总结

一开始还是比较担心的,毕竟版本跨度这么大,在网上看到的基本上都是小幅度的更新。 这次因为整个升级时间比较充足,前期调研准备也比较充分,倒没有出现比较严重的耽误进度的事情。就是项目业务逻辑比较多,在更改之后有个别小地方被遗漏了,后期才发现这些隐蔽的bug。 总体来说,基本上更改的代码量不是特别多,集中在 react-navigation,以及Flatlist等地方,在和iOS、android等联调方面也花费了不少时间。 因为在疫情的缘故,不得不在家办公,让本来没打算更新升级过的代码不得不更新。

评论已关闭!