[QQ 优化图片上屏策略]
2）可视区域按需渲染
- DOM 元素数量
在 DOM 元素使用数量我们也有严格的控制，总体采用”所见即占用“的 DOM 渲染策略。在 QQ 大面板中只有视口所见的内容才会渲染对应 DOM 元素。其他所有组件在不渲染展示时，均会移除组件及其 DOM 元素来避免其内存开销。
[大虚拟列表控制 DOM 数量]
尤其对于各个大列表模块，比如联系人列表和群成员列表，DOM 元素都非常多。最开始的内测版本中，使用有大量好友和群聊的 QQ 号，窗口平均 DOM 数达到 13000。我们将 QQ 所有的普通分页列表替换为虚拟滚动列表，并且对列表滚动 buffer 进行极限压缩甚至是 0 buffer 。由于不再一味采取空间换时
间，没有 buffer 的情况下必然面对列表滑动性能挑战，因此也需不断优化各类 item 组件渲染性能。
此外，我们还通过精简组件 DOM 层级，移除非核心组件 keep-alive (重新优化渲染性能) 等方式，大账号使用下整体的 DOM 数量从 13000 减少到控制在平均 4000 以内，这部分优化减少约 20M 内存。
- 渲染图层
渲染图层方面，在渲染时满足某些特殊条件的渲染层，会被浏览器自动提升为合成层，达到提升渲染性能的目的。但是每个合成层都占用额外的内存，应当去掉过量且不必要的合成层来控制图层带来的内存占用。当然结合渲染性能考量，对于高频且列表等核心模块，是可以单独提升合成层。
[QQ 对于渲染合成层的优化处理]
在桌面端 QQ 中通过超级调色盘可以为进行色彩换肤，在这个场景中全局各模块有不少单独提升的合成层来实现毛玻璃、渐变和纹理效果。另外还有许多不经意间被提升的隐式合成层。通过对不必要的合成层进行移除与合并，整体也优化了约 9.3M 内存。
- 结构化消息
QQ 支持丰富的消息类型，从简单的文本、图文消息，到复杂的 lottie 表情、下图所示的业务可定制的结构化消息等。我们知道 JavaScript 是单线程的，这些消息同时上屏的时候可能会出现过长的上屏任务而导致 UI 卡顿，给到用户的感受就是切换消息列表卡顿，消息上屏慢等糟糕的体验。
新版 QQ 针对这类复杂消息上屏，使用了 JavaScript 事件机制结合 WebWorker 来实现消息异步上屏，并使用 OffscreenCanvas Worker 池绘制来提升渲染性能。
[QQ 结构化消息的处理方案]
为了在 Canvas 中实现 CSS 的 Flex 布局效果，我们采用了跨平台的布局解决方案，将 Yoga 编译成 WebAssembly 运行在 WebWorker 中。Yoga 官方编译采用的是 asm.js 的方案， 这种方案不支持动态分配内存，可以看到它默认分配了一个较高的内存，达到了 128M。
