我们构建 index→${widget.key}→List<element>的映射关系：在 widget 创建处建立index→${widget.key}映射，在 element 应该被销毁移除的逻辑处，将 element 缓存至${widget.key}映射的List<element>处（注意 renderObject 对象需要从父节点移除）。列表滑动过程中，优先根据映射关系找到缓存中的 element 并使用（注意更新 element.renderObject.parentData 中的 index 值）
4.3 复杂 Widget 分帧上屏
以上全部优化手段尝试后，在闲鱼的详情页和搜索页上还是远没有达到预期。原因是猜你喜欢卡片和搜索页卡片本身就足够复杂，另外由于我们引入 DX 技术让 Widget 进一步变得巨大，最终导致的结果是：即便高端机，也无法在一帧时间内完成渲染。然而抛开技术视角，从业务视角看，卡片展现内容和 DX 的动态能力都是必需的。那如何在满足业务诉求的情况下，实现超大 Widget 的高性能呢？
业务侧仅需 Text，但在 DX 技术中使用的是 DXTextWidget
猜你喜欢卡片在 红米 K30Pro（CPU 骁龙 865）的 Timeline 图
搜索结果卡片 Timeline 图，补充了 performLayout、updateChild、Widget build
在已知常见优化手段无法满足的情况下，我们回归 GUI 系统性能优化的起点去思考问题。流畅度优化思路，大体可以分为 3 个方向：
多线程方案
在 Android 原生开发中很常见。但在 dart 世界中，不同线程（isolate）的内存是隔离的，此外由于 flutter 渲染流程三棵树，我们不好直接操作 RenderObject，多线程方案在 flutter 中较难实施（排除 IO 更新数据后显示等常规场景）
优化每个任务，挤压 CPU 运算量，保证一帧时间（16.6 ms）完成任务
flutter 中的主流优化思路，前面的优化手段都是这个思路
快速响应用户，让用户觉得够快，不阻塞用户的交互
即一帧时间内还有任务没有完成，则停止执行，保证列表先执行滑动，未执行任务在后续帧时间片上执行 参考 React Fiber 框架，基于时间分片的思路，协调阶段将一颗任务树转为一条任务链（parent 节点 → child 节点 → sibling 节点 → parent 节点），满足了任务链可中断执行，提前提交渲染，最后实现了将一条任务链拆解到多帧时间分片中消化。
