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版本在小程序的运行性能上做了很多改进,性能优化是个长期且细致的事情,在微信小程序上主要的手段就是。
- 减少setData次数,
- 减少每次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
, 对应这里:
- 第一次:
L1
- 第二次:
L21
,L22
- 第三次:
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
脚本里面
其他改动
-
减少生成小程序包体积
-
重新实现
componentWillUnmount
生命周期,不再依赖微信小程序detached
回调 -
修改自定义组件
render
返回null
的时候,微信小程序组件依然存在的bug -
修复componentGenerics 字段的在老开发者工具下的警告,在新的开发者工具下的报错
-
修复文件后缀为jsx的时候,转化产生的bug
-
其他日常bug修复
更多详情移步Github Alita,感谢 star
关注 ARES Labs 公众号