ByteKMP Compose ArkUI 原生渲染解决方案

主要观点总结

本文介绍了将Compose官方基于Skia的渲染链路替换为基于Native Drawing的渲染方案的过程，解决了因Skia实现带来的包增量和内存问题。文章详细描述了整体架构、项目结构变化、渲染流程、脏区管理等方面的内容，并展望了未来的性能和进一步优化方向。

关键观点总结

关键观点1: 背景

Compose官方使用Skia作为渲染引擎，但在实际使用中发现了创建底层渲染通道会增加额外内存的问题，存在触发OOM的风险。为了解决这个问题，团队决定适配Native Drawing。

关键观点2: 整体架构变化

通过替换渲染引擎，项目的整体架构也发生了变化。Compose作为最外层UI框架，向内管理布局树和更新状态，同时通过Native Drawing进行具体图形渲染。

关键观点3: 项目结构变化

项目结构发生了变化，特别是SourceSet依赖关系进行了调整。为了适配Native Drawing，一些基础库也进行了适配，包括图形接口实现和一些三方库。

关键观点4: 渲染流程

由于更换了渲染引擎，渲染流程也发生了变化。包括内容绑定、帧回调和绘制过程。内容绑定涉及@Composable方法的注册和运行时绑定；帧回调需要处理帧相关能力注入；绘制过程则涉及到C层和Kotlin层的切换调用栈。

关键观点5: 脏区管理

项目采用了PictureRecorder进行脏区管理。在节点首次绘制时录制渲染命令，后续内容无变化时复用录制内容。当节点内容发生变化时，通过RenderNodeLayer的invalidate方法销毁Picture。

关键观点6: 性能与展望

切换Native Drawing后解决了包增量和内存问题，但存在一些性能问题。通过和ArkUI官方技术团队的交流和探讨，缺失的CAPI将在系统大版本升级时补齐，解决内存和FPS问题。最后感谢高迪、耿飞所代表团队的技术支持。