rn源码ios_新年之初,回看我们用Taro开发RN的那些事儿

Taro 开发RN的抉择Taro RN的第一个项目尝试是公司网约车服务FAQ，当时为了三端同构采用了同步开发的方式，即打开小程序开发工具、同时是打开H5debug服务以及RN的开发服务，在RN上，我们使用IOS的模拟器作为调试。也是因为公司采用mac开发，所以不再安装Android环境。即便是这样16G内存配置环境下，三端同步开发依然会对电脑性能有着巨大的考验。如果使用Android环境...

SerendipityLol

638人浏览 · 2021-01-06 16:16:02

SerendipityLol · 2021-01-06 16:16:02 发布

Taro 开发RN的抉择

Taro RN的第一个项目尝试是公司网约车服务FAQ，当时为了三端同构采用了同步开发的方式，即打开小程序开发工具、同时是打开H5debug服务以及RN的开发服务，在RN上，我们使用IOS的模拟器作为调试。也是因为公司采用mac开发，所以不再安装Android环境。

即便是这样16G内存配置环境下，三端同步开发依然会对电脑性能有着巨大的考验。如果使用Android环境，可以想象我们的电脑如何更加辛苦劳作了。

后来为了避免增加业务负责性，我们选择在 FAQ 客户端使用H5方案，也就暂时搁置Taro RN化的选择。但是这一次尝试，增加了基于Taro开发RN的信心。

开始真正在业务上使用 Taro 开发 RN 业务

我们的第一个真正在业务上使用 TARO 开发 RN 的是我们的网约车业务模块，当时怀着满满的希望和决心去做。

也许是初生牛犊不怕虎的心态，在行业里没有任何现有案例的情况下，我们在taro1的版本开始撸袖子开荒的干活。但逐渐的发现Taro在RN开发上有着各种需要面对的挑战。

Taro在RN开发上的挑战

缺少RN组件库

我们在小程序和H5环境下，在已有的业务积累下，这两个环境已经形成稳定的Taro组件，但是RN上却没有，这里我们所说的是没有TaroRN组件。

我们的想法是把已有原生的RN组件Taro化，最终达成三端统一的组件库，于是便有了alita-ui组件库。阿丽塔UI库的最终目的是开源到社区里，目前业务线已基本全业务覆盖，相信走往社区的路会走的很快。

导航栏的API缺陷

在 RN 里，我们经常会用到 react-native-navigation 库。Taro 默认也使用了该库，但是Taro在编译配置上却未能完全暴露所有API，这导致我们只能考虑修改Taro编译源码来调整。

于是基于 Taro1.2.21 版本，我们修改了 taro cli 。在编译 RN 的时候，我们扩展了 Taro 原有的 config 静态配合，这样我们的项目不会受API限制了。

初始化路由和路由跳转

一个业务项目有多个页面，有些页面会被复用，例如订单业务。通常来说，订单页的入口可以有多个原生入口，这时候初始化页面的需要是必然了。结合客户端的路由协议，我们统一了客户端跳转RN页面的路由协议。在RN跳转原生页面上，我们也通过JS bridge 建立客户端RN桥接方法，实现统一化。

我们也走过的弯路，当初有个想法是把所有页面逻辑上当做组件，实现思路上类似于 SAP。但是问题也随即出现，首先是性能问题，每个页面都有自己的状态，如果新的页面建立那么老的页面会一直存储在，这些页面实际上都在一个页面内。然后是传参问题，页面组件化后，页面与页面的传参就得通过统一状态来管理，这样更多是增加了框架的复杂度。

还有一点就是在跨原生与RN页面跳转，我们会遇到更加底层的问题，这些都视乎在警告我们不该这样去处理。

于是我们完全的使用 react-native-navigation 库来管理路由，后来证明我们的选择是正确的。我们在taro的路由编译模块修改了，初始化的路由页面生成方式。在初始化的时候，我们会动态根据客户端传入的模块和页面路径来初始化第一个页面，并把初始化的参数经过格式化处理后赋值给 navigation。

这样我们就可以通过 Taro 原有的语法 this.$router.params 来访问，符合 Taro 的原有的API设计。

Taro RN 脚手架的出炉

在经历过这次项目后，我们立刻输出了 Taro RN的脚手架，而我们的Taro RN 在业务上的使用从此开始。到目前为止，所有RN的业务都采用 Taro 实现。这期间我们也做过各种场景的尝试。

我们尝试 Modal 方式的RN局部实现、路线规划RN在路线规划的局部实现、同时也尝试了复杂的RN动画的实现，最后让所有涉及RN业务线的框架问题稳定了，让客户端的同学也能在开发RN时得心应手。

合并到多端化进程

我们的当初在选择 Taro 的初衷便是实现多端重构，即 write once, run any where.所以，在TaroRN脚手架的稳定下来后，我们建立的多端脚手架。让我们的开发同学不必为选择使用哪种脚手架而烦恼，同时也让我们的项目支持多端场景。例如，让我们的网约车业务代码在一个脚手架内同时支撑小程序和RN，当然这一实现得益于我们的多端组件库阿丽塔组件库的完善。