RN 官方框架对 dom 元素的“按需加载”与“按需卸载”支持存在着先天性不足，即“元素从屏幕外滑动到屏幕内”与“元素从屏幕内滑动到屏幕外”处理比较粗暴，不能够很好的做到“按需加载”与“按需卸载”，有大量不在屏幕上的元素被加载渲染，而滑动出屏幕的元素也不能卸载与释放，甚至有些元素一直驻留内存。
小红书 RN 业务（电商、社区）基本都包含大量的图片，上述问题则会导致有大量“冗余”图片被请求加载以及渲染，而滑出屏幕后又不能按需“卸载”。这会带来以下业务痛点：（1）大量冗余网络请求，导致网络流量的浪费；（2）内存的增加，导致 OOM 的增加；（3）冗余图片的加载与渲染，影响图片加载性能。基于以上背景我们提出了“基于 N 叉树快速检测目标是否可见机制”从底层原生框架彻底解决，并且取得了显著的成效。比如 iOS 平台流量节约（仅电商业务商详）大致 8.8%、页面容器内存平均降低 9M 左右等。

演讲提纲：
1. 问题背景

• RN 官方框架对 dom 元素的“按需加载”与“按需卸载”支持存在着先天性不足
• 小红书 RN 业务特点
• 前端方案对元素屏幕外释放机制方案存在缺陷
• 小红书 RN 业务面临痛点
  • 大量冗余网络请求，导致网络流量的浪费
  • 内存的增加，导致 OOM 的增加
  • 冗余图片的加载与渲染，影响图片加载性能
  • 业务侧对 FlatList 屏幕外元素释放优化成本较高

2. 问题分析

• 业务场景分析
  • 规则化长列表场景
  • 无规则化业务场景
  • 动画平移场景
• 问题详细分析
  • 判断节点是否在屏幕内外标准是什么？
  • 哪些节点需要检测是否在屏幕内或者外？
  • 在什么时候对节点检测比较合适？
  • 如何检测节点是否在屏幕内或者外？
• 内存降低效果如何验证？

3. 技术方案

• 目标检测算法
  • 技术方案概述：基于 N 叉树快速检测目标是否可见机制
    • 统计节点包含图片节点数目
    • 确定检测任务执行时机
    • 派发检测任务（子树递归检测任务、移除 dom tree 检测任务）
    • 系统绘制时对标记检测节点执行检测
    • 屏幕内外图片节点分别处理图片相关任务
• 内存统计优化方案

4. 优化效果

• 图片请求流量 iOS 单端电商商详业务节约大致 8.8%
• 内存优化平均降低 8.11M
• 图片加载耗时提升大约 49% 左右
• 全业务无感知，代码无侵入性，节省优化成本
• 算法方案无性能体验负反馈

5. 未来规划

• 该检测算法不局限于图片元素，算法支持指定某类型元素检测（比如视频、文本）
• 算法方案可直接应用到 iOS 原生、算法思想可扩展到其他平台比如 Android、Flutter
• 该算法方案直接可以直接应用到基于 LCP 的可交互性首屏监控
• 其他应用，视图层级统计、垃圾 view 悬挂等

你将获得：

• FlatList 在元素“按需加载”与“按需卸载”方案上深层的先天性不足
• 前端框架实现的 lazyload 方案为什么也不能从本质上解决问题
• RN 与 Weex 在 Dom 元素构造设计上存在着本质差异