排查包装类自动装箱内存抖动，关键在于识别高频路径中基本类型与包装类混用引发的隐式对象创建，如循环add、三元运算、日志拼接等，导致Young GC频繁触发卡顿。
排查包装类自动装箱引发的内存抖动，关键在于识别“看似无害的赋值或运算”背后隐藏的对象创建行为。它不占用大量内存，却因高频、短命、集中触发 Young GC，造成卡顿和锯齿状内存曲线。
盯紧高频调用路径中的基本类型与包装类混用
自动装箱（如 Integer.valueOf(int)）在小值范围（-128 ~ 127）内可复用缓存对象，但超出该范围或使用 new Integer() 会真实 new 对象。问题常出现在：
- 循环体中用 int 变量参与集合操作：例如
list.add(i)（i 是 int），每次都会装箱为 Integer； - 方法参数是包装类型，而调用方传入基本类型：如
processValue(longValue)，而processValue签名是void processValue(Long v)； - 三元运算符隐式装箱：
Integer x = flag ? 1000 : null，1000 超出缓存范围，每次执行都 new； - 日志打印中直接拼接包装类：
Log.d("tag", "value=" + someLong)，触发String.valueOf(Long)→Long.toString()→ 内部 new char[] 等连锁分配。
用 Memory Profiler 定位具体类与调用栈
在 Android Studio Profiler 中录制典型操作（如快速滑动列表、连续点击按钮）：
- 开启 Allocation Tracking 后，筛选 Integer、Long、Boolean、Double 等类，观察其分配次数是否在毫秒级内达数百上千；
- 点击某次分配，查看 Call Stack —— 重点检查是否落在
onBindViewHolder、onDraw、事件回调、网络响应解析等高频方法内； - 对比同一逻辑使用基本类型（如
int）和包装类型（Integer）时的分配数量差异，确认装箱是主因。
通过字节码或日志验证装箱开销
对可疑代码段做轻量级验证：
- 用
javap -c反编译，确认Integer i = 1000;编译后是否为invokestatic java/lang/Integer.valueOf(I)Ljava/lang/Integer;； - 在开发环境开启 ART 的详细 GC 日志（
adb shell setprop dalvik.vm.extra-opts "-XX:+PrintGC -XX:+PrintGCDetails"），观察GC_FOR_ALLOC是否密集伴随Integer分配峰值； - 临时在关键位置插入
Debug.getAllocatedExternalMemorySize()或统计Runtime.getRuntime().totalMemory() - freeMemory()变化，佐证短时突增。
修复策略要直击本质而非表面
避免“换写法但未改语义”的伪优化：
- 集合操作优先用原始类型容器库（如
androidx.collection:collection中的SparseArray、LongSparseArray），或改用基本类型数组 + 手动索引； - 局部计算一律用 基本类型，仅在必须传入泛型/接口时才做一次显式装箱，并尽量复用；
- 禁止在循环、onDraw、动画帧回调中出现
list.add(x)（x 是基本类型）；改用预分配集合或流式处理； - 日志中避免
"val=" + obj，改用占位符格式：Log.d("tag", "val=%d", value)（支持基本类型，不触发装箱）。
