Kuikly 是腾讯基于 Kotlin Multiplatform (KMP) 构建的全平台高性能开发框架，覆盖 Android、iOS、HarmonyOS、H5、微信小程序、Mac 六大平台，主打一码多端、极致易用与动态化。
Kuikly 借助 Kotlin/Native 编译产物与原生渲染管线，已经具备原生级性能。为了进一步压榨首屏体验，我们推出了 TurboDisplay 加速方案，通过节点缓存、主线程端侧直出与双线程并行渲染，在二次打开场景下实现“秒开”，并在 QQ 游戏、输入法、腾讯地图等线上业务中取得 60%–80% 以上的耗时优化。本文将深入解析其设计思路与核心机制。
一、运行效果展示
TurboDisplay 是 Kuikly 自研的首屏加速方案，在页面二次打开场景下实现了“秒开”。运行效果对比如下：
二、为什么要做首屏加速
页面打开耗时是移动客户端长期面临的共性体验问题。从用户点击入口到首屏呈现，链路依次经历“容器初始化、运行时与渲染引擎准备、业务代码执行、数据请求与解析、布局测量、节点构建与最终上屏”，任何一环的耗时累加都转化为可感知的等待。
这并非某一类技术栈的专属问题，即便纯原生开发也无法回避业务复杂度、网络波动、设备性能差异等客观因素。Kuikly 虽然通过 Kotlin/Native 编译产物与原生渲染管线获得了原生级执行性能，但同样走在这条串行链路上——单纯优化“代码执行更快”已逼近收益上限。若想从根本上加速首屏，必须跳出执行效率本身，从渲染链路的调度方式上寻找突破口。
三、传统方案为什么都不够
围绕首屏加速，业界已经积累了不少通用优化手段。它们从不同链路切入，在各自适用的场景下都能带来一定收益，但无论是原生开发还是跨端框架，都难以做到真正的“秒开”体验。
要真正实现“打开即可见、可交互”，缓存的对象就不能只是图像或数据，而应该深入到框架自身的渲染产物——缓存构建好的渲染节点，从而在下一次打开时跳过中间环节，直接以可交互的形态呈现。那么，Kuikly 在这条路上应该怎么走？
四、方案选型
4.1 好的首屏加速方案长什么样
理想的首屏缓存加速方案应同时满足三个要求：业务无侵入——不依赖业务的具体实现，接入成本尽可能小；渲染及时——呈现的首屏必须是业务真实逻辑的严格对应；可信任——能在生产环境稳定工作。三者共同决定了加速方案是“普惠加速”还是“个例 trick”。
4.2 最容易想到的方案：节点直出，够用吗？
顺着“缓存渲染节点”的思路，最自然的做法就是节点直出：把渲染节点的结构、属性、样式持久化，下次打开时读出并直接重建视图，跳过“执行业务代码 → 布局测量 → 节点构建”这一段。在 Kuikly 中，页面最终上屏时会被抽象为一组低阶渲染节点与基本渲染指令，节点直出能自然适配这套管线。
但节点直出只覆盖了跨端侧的业务执行与节点构建阶段，前置的引擎初始化操作仍然无法省略，仍会延缓首屏展示。所以，直接套用节点直出方案，距离“页面打开即可见、可交互”仍有明显差距。要再往前走，必须对方案本身做根本性改造。
4.3 最终思路：把缓存恢复从主链路中拆出
节点直出只是缩短了链路，并未重构链路——缓存恢复仍然嵌套在业务逻辑执行的链路中。真正的加速，不再只是“把原链路做快一点”，而是要把缓存恢复从原链路中拆出来，形成一条独立执行路径。实现这条路径，需要解决三个关键问题：缓存恢复如何提前发生、缓存内容如何持续更新、以及缓存首屏如何与真实页面平滑衔接。
五、方案设计
围绕这三个问题，TurboDisplay 的核心设计拆成三部分：双线并行、节点采集和增量更新。前两者解决“如何更早展示”和“展示什么”，后者解决“如何在不中断交互的前提下切回真实页面”。此外，TurboDisplay 还设置了缓存一致性、兜底写入等机制，提供了强制刷新、节点树结构捕捉等业务控制项，以及面向特殊场景的拓展。受篇幅所限，下文将聚焦三个核心机制及特殊场景的拓展支持，阐明 Kuikly 的节点直出首屏加速方案。
5.1 设计骨架：三项核心机制
先看 Kuikly 如何通过双线并行、节点采集以及增量更新，使缓存恢复成为一条独立快速路径。
5.1.1 双线并行
在 Kuikly 的视角里，“缓存恢复成为独立快速路径”就是把“页面完整执行链路”内构建首屏的执行过程搬到端侧，让它提前跑一遍：
- 端侧承载容器及根视图构建完成后，直接读取本地缓存并转换为节点树，产生渲染指令，让首屏快速在端侧上屏；
- 原本的执行链路则保持不变，端侧调度线程后，跨端侧仍按正常流程在后台执行这一轮真实页面的业务逻辑、布局测量与节点构建，再产生批量渲染指令并生成一颗端侧的真实页面节点树，等待后续与缓存节点树比对差异，更新实际的首屏渲染内容。
5.1.2 节点采集
TurboDisplay 所存储的节点是端侧节点树上的完整信息，包括每个节点的属性、事件、布局 frame、Shadow 信息、节点上的方法调用，以及节点树结构的变化。采集时，TurboDisplay 能够系统地比较缓存首屏与真实页面节点树在树形、节点内容之间的差异，将差异更新至缓存节点树，然后自动、周期限频地把缓存节点树写盘。
此外，节点采集还支持业务自定义是否需要捕捉节点树之间的结构差异；若未开启此能力，则缓存的始终是业务真实首屏所对应的节点及其最新内容。
5.1.3 增量更新
TurboDisplay 在快速直出首屏之外，最关键的一环是如何让真实页面逻辑平稳地覆盖到端侧已展示的缓存首屏上。为避免业务真实逻辑与缓存首屏之间的数据差异造成闪屏和跳变，局部更新是最稳妥的方式。
跨端侧调度主线程后，端侧批量执行渲染指令，先建立业务真实首屏对应的节点树，然后执行与缓存节点树之间的属性、布局 frame 及调用方法参数等内容的差异比较，全量回放首屏过程中记录的交互事件，并直接新建此前不存在的节点。这样，在不抖动屏幕内容的情况下，局部增量地更新业务的实际首屏内容，实现缓存首屏与真实首屏的平滑切换。
5.2 拓展支持：状态恢复与事件保序
三项核心机制支撑了节点直出快速显示 Kuikly 页面首屏，但真实页面并不会总停留在初始位置。缓存首屏展示后，用户可能已经发生交互，列表页也可能需要恢复到上一次访问位置，这会带来端侧已展示内容与跨端侧默认首屏的错位。如果不加以处理，直接执行 diff，就可能出现首屏跳变回默认内容，甚至内容落在屏幕之外而出现白屏。
5.2.1 为什么 diff 增量更新会成为问题？
TurboDisplay 的“端侧直出 + 跨端侧后台构建”并行设计，意味着缓存首屏比真实业务首屏出现得更早——这个“更早”，正是问题的根源。
端侧直出后，无论是恢复到历史位置还是响应用户交互，端侧都已经呈现了非默认状态；但跨端侧构建的真实页面仍处于默认位置，尚未感知这些变化。当真实页面通过 diff 准备在端侧展示时，对比的是“端侧已恢复/交互后的状态”与“真实页面默认状态”，差异被全量更新，导致端侧已呈现的内容被覆盖回默认效果，表现为位置跳变或交互结果丢失。
要解决这一覆盖问题，关键落在了 diff 何时执行才正确。
5.2.2 解决方案：由跨端侧调度 diff
为了找到正确的 diff 时机，我们先后尝试了两种方案：
两次尝试的失败指向同一个根因：端侧无法预知跨端侧的真实页面何时构建完成，无论用延时还是用本地信号，都无法在端侧找到一个稳定的执行时机。这个根因反过来也给出了方向——既然端侧无法判断，那就让拥有完整时序信息的跨端侧来负责调度恢复。
具体做法是，将 Diff 的执行时机从“真实页面到达端侧即执行”延后为“恢复内容生效后再执行”，也就是延迟 Diff。跨端侧在构建真实节点树时精确感知自身进度，在生成渲染指令前先执行恢复逻辑：将滚动偏移量应用到真实页面节点上，回放缓存首屏期间暂存的交互事件使跨端侧先响应。这样一来，交付给端侧的真实首屏本身已处于恢复后的状态。此时 diff 对比的两端基础一致，非默认内容不再是差异项，自然不会被覆盖。下图即是由跨端侧执行调度后的首屏加载过程，其中红色矩形部分代表页面恢复引入的新变化。
解决了 diff 时机问题后，无论是业务逻辑默认首屏内容，还是交互之后的动态内容，TurboDisplay 都能实现稳定且正确的展示。
六、性能表现与验证
为了验证 TurboDisplay 的实际效果，我们分别从实验室环境与线上真实业务场景两个维度进行了性能测试。结果一致表明，TurboDisplay 在二次打开场景中能够显著加速首屏显示，且在复杂页面中保持稳定的优化收益。
6.1 实验室对比
我们在 iPhone 13 Pro Max 和 iPhone 7 Plus 两种设备上进行了测试，测试场景为页面二次打开。以下 GIF 中第 1 帧延迟 100 毫秒处理，便于观察是否实现首帧即现。
6.2 线上数据验证
TurboDisplay 已经在 QQ 游戏、输入法以及腾讯地图等诸多业务场景上线，并取得了 65%–80% 的耗时优化，以下为部分页面实际线上对比数据：（注：优化前页面的代码与数据均已本地缓存，启动过程无网络耗时，均为本地逻辑耗时）
七、如何体验
TurboDisplay 在设计之初便考虑了业务接入的轻量化。实际使用中，业务侧仅需实现开关接口 TurboDisplayKey，即可为 Kuikly 页面开启首屏加速，典型接入代码如下：
// Native端侧页面容器 KuiklyRenderViewController.m
// 实现TurboDisplay开关接口
- (NSString *)turboDisplayKey {
return pageName;
}
其他业务控制项的使用方式及相关细节，可参考 官方文档 作进一步了解。
八、后续规划
目前 TurboDisplay 主要聚焦于页面二次打开场景的优化，针对首次打开场景，团队内部也正在进行方案设计和开发，核心思路：
- 在编译期对首屏逻辑进行静态分析与提取；
- 在运行时通过微指令引擎快速展示首屏；
- 再与原产物执行链路平滑衔接。
欢迎大家保持关注。
九、关于 Kuikly
当前 Kuikly 已经开源，如需体验或贡献代码，可通过以下链接访问仓库和文档，欢迎 Star、Watch 与参与：
本文原载于腾讯技术工程，经云栈社区编辑整理。更多跨平台与开源技术实战，欢迎访问 云栈社区。
发表于 10 小时前
|
查看: 13|
回复: 0
