长列表滚动中节点复用不当易致OOM，关键在守住三道防线：视图生命周期可控、数据绑定轻量、资源加载受控；须确保ViewHolder完全复用、图片加载带尺寸约束与内存复用、及时切断强引用链，并辅以监控兜底。
长列表滚动中节点复用本身是为降低内存开销而设计的机制，但若实现不当，反而会引发内存溢出（OOM）。核心问题不在于“是否复用”，而在于“复用过程中是否持续持有无用引用、是否加载未缩放的原始资源、是否遗漏清理逻辑”。关键要守住三道防线：视图生命周期可控、数据绑定轻量、资源加载受控。
确保 ViewHolder 完全复用，避免隐式新建
每次 getView()（Android）或 onBindViewHolder()（RecyclerView）被调用时，必须优先使用传入的 convertView 或 holder.itemView，而非无条件 inflate 新布局。未复用会导致视图对象指数级堆积，尤其在快速滑动时。
- 检查是否在
if (convertView == null)外部又执行了inflater.inflate() - 确认 ViewHolder 中所有子 View 引用都通过
findViewById一次性获取并缓存，不要在绑定时反复调用 - RecyclerView 场景下，禁用
setHasStableIds(false)后未重写getItemId()，可能干扰复用策略
图片加载必须带尺寸约束和内存复用
列表中每项含图片时，OOM 主因往往是 Bitmap 占用失控。一张 4000×3000 的 JPEG 解码成 ARGB_8888，内存达 ~46 MB —— 10 个就超多数 App 堆上限。
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 加载前务必根据 ImageView 实际宽高计算
inSampleSize，跳过完整解码 - Android 4.4+ 推荐启用
inBitmap复用已分配的 native 内存块（需尺寸匹配） - 避免在 ViewHolder 中直接 new Bitmap 或 decodeStream；统一走 BitmapFactory.Options 配置流程
- 不用第三方库时，至少封装一个简易缩略图工具类，强制指定目标尺寸与格式（如 RGB_565）
及时切断数据与视图的强引用链
节点复用后，旧数据残留引用是隐蔽泄漏源。例如：给 ImageView 设置了 Glide 加载任务，但 ViewHolder 被复用时任务未取消；或监听器绑定未解绑；或业务对象持有 Context。
- 在绑定新数据前，清空 ImageView 的 drawable：
imageView.setImageDrawable(null) - 异步任务（如图片加载回调、网络请求）必须在
onViewRecycled()或onDetachedFromWindow()中取消 - 避免在 ViewHolder 内定义非静态内部类监听器（易持 Activity 引用），改用 WeakReference 或 lambda（确保无隐式引用）
- Adapter 中持有的数据源应为轻量结构（如 ID + 简单 DTO），勿存完整实体或 Bitmap 缓存
监控与兜底：让问题可感知、可拦截
靠经验防不住所有边界情况。上线前加入轻量监控，能提前暴露风险。
- 在
onViewAttachedToWindow()中记录当前活跃 ViewHolder 数量，突增即告警 - 对图片加载路径添加日志埋点，统计平均解码耗时与尺寸分布
- 在低内存设备（如 Android Go 版）上启用
isLowRamDevice()分支，自动降级图片质量或禁用圆角等耗资源操作 - 必要时主动触发 GC（仅调试用）：
System.gc()不保证执行，但配合Debug.getNativeHeapAllocatedSize()可辅助验证释放效果
