RN转小程序引擎 Alita 1.2 版本发布

Alita在处理React语法的时候，采用了一种运行时处理JSX的技术，相对于社区现有的编译时方案，在JSX语法的支持上更加完备，关于运行时处理JSX的原理，详情请看。

自发布以来，Alita受到了社区普遍的关注，有多个内外团队已经开始调研Alita的使用。1.2版本咱们除了平常的bug修复，重点在运行性能作了改动，另外咱们也在优化cli 命令行，让其更加友好。

Alita如今也放置到了React Native文档Out-of-Tree Platforms类目下

改进cli

让Alita更加易用，一直是咱们的重要目标，咱们也会根据用户的反馈不断优化Alita脚手架。

当前版本中，新增了 alita 提示信息，指引你正确得使用 alita 相关命令。当你输入alita, alita -h 或其它非 alita 脚手架支持的 command，都可以看到 alita 的正确用法。

性能优化

1.2版本在小程序的运行性能上作了不少改进，性能优化是个长期且细致的事情，在微信小程序上主要的手段就是。

1. 减小setData次数，
2. 减小每次setData的数据量，

下面咱们具体说明一下Alita的探索。

加入批量更新

微信小程序2.4.0，提供了groupSetData接口。

这个接口的出现，给了Alita更加高效的刷数据到微信小程序的方式。 在v1.2版本，咱们重写了内部mini-react和小程序层的数据交换方式，如今每一次setState 产生的组件更新，都会被groupSetData合并到一次操做里面，这样大大减小了setData次数。

初始化组件优化

组件的初始化过程和更新略有不一样，更加复杂一些。考虑如下的状况：

当react层计算出全部组件的渲染须要的数据的时候，首先刷数据给 L1, L1渲染完成，Alita获取到L21, L22实例，刷数据，L21结束，获取L31, L32。。。这里的刷数据存在着时序上的前后，很难经过groupSetData一次性的把全部数据传递给L1,L21 ... L34。

这里假定组件树结构有n层，咱们最少是能够作到n次 groupSetData， 对应这里：

1. 第一次： L1
2. 第二次： L21， L22
3. 第三次： L31， L32， L33， L34

Alita尝试过这个方案，在测试了几个业务以后，发现这个方案有两个问题，通常首屏页面初始会有7，8层，这样会有7，8次groupSetData，致使页面TTI（首次可交互时间）变长。 更加严重的是假如后面的组件结构很浅，前面的组件结构很深，会致使后面的组件先渲染完成，形成页面的抖动。

因此最终Alita也并无采用上面的方案。 Alita的方案以下： Alita会把全部数据集合到一块儿L1， 经过L1的一次设置，渲染出L1， L21， L22...L34。 当这个过程结束的时候， Alita持有了全部组件， 会在进行一次groupSetData修正一下数据。 这个方案只会固定的执行两次groupSetData。另外因为全部组件在一次groupSetData里面完成，故而不会有抖屏。

减小每次setData数据

Alita 1.2 精简了react层产生的数据描述结构，减小了描述数据的层级。补偿性的，把不少数据计算放在了wxs脚本里面

其余改动

1. 减小生成小程序包体积

2. 从新实现componentWillUnmount生命周期，再也不依赖微信小程序detached回调

3. 修改自定义组件render返回null的时候，微信小程序组件依然存在的bug

4. 修复componentGenerics 字段的在老开发者工具下的警告，在新的开发者工具下的报错

5. 修复文件后缀为jsx的时候，转化产生的bug

6. 其余平常bug修复

更多详情移步Github Alita，感谢 star

关注 ARES Labs 公众号