Performance on zed的博客

Android 包体积优化：从 APK 分析到 R8、资源和 ABI

Sun, 15 Jun 2025 23:19:59 +0800

包体积优化不能只靠“开混淆”。正确路径是先知道体积花在哪里，再按代码、资源、原生库、Assets、动态模块逐项处理。

核心结论

先用工具看 APK/AAB 构成，再决定优化方向。
R8 的主要价值是裁剪、优化和混淆，其中裁剪对体积影响最大。
资源优化重点是删除无用资源、压缩图片和控制多套资源。
原生库要重点检查 ABI、重复 .so 和调试符号。
大功能可以考虑 Play Feature Delivery 或按需下载，不要全部塞进首包。

分析入口

常用工具：

Android Studio Build > Analyze APK
Android Studio App Size Analyzer
Gradle 构建输出和依赖报告
bundletool 分析 AAB 生成的设备 APK

先看四类占比：

classes.dex -> Java/Kotlin 字节码
res/resources -> Android 资源
lib/*.so -> Native 库
assets -> 原始资产文件

代码体积

R8 可以完成三件事：

Shrinking：删除未使用类、方法和字段；
Optimization：内联、常量传播、简化控制流；
Obfuscation：缩短名称，提高逆向成本。

配置入口通常是：

android {
 buildTypes {
 release {
 isMinifyEnabled = true
 isShrinkResources = true
 proguardFiles(
 getDefaultProguardFile("proguard-android-optimize.txt"),
 "proguard-rules.pro"
 )
 }
 }
}

注意点：

不要盲目 -keep 整个包；
反射、序列化、JNI、路由框架需要明确 keep 边界；
先看 R8 输出，再判断哪些规则过宽；
Debug 包不要拿来评估最终体积。

资源体积

资源优化重点：

开启 shrinkResources；
删除未使用资源；
图片优先使用 WebP 或 VectorDrawable；
控制多语言、多密度、多主题资源；
避免把临时大图、设计稿、日志文件放进 assets。

排查命令：

./gradlew lintRelease

图片策略：

类型	建议
简单图标	VectorDrawable
照片类图片	WebP
透明图片	WebP lossless 或 PNG
大型离线素材	按需下载或独立资源包

Native 库体积

原生库常见体积来源：

多 ABI 同时打包；
.so 中包含调试符号；
第三方 SDK 带入重复库；
Rust/C++ 静态链接带来额外体积。

可以按目标市场控制 ABI：

android {
 defaultConfig {
 ndk {
 abiFilters += listOf("arm64-v8a", "armeabi-v7a")
 }
 }
}

如果使用 AAB，Google Play 会按设备拆分 ABI，首包压力会小很多。

Assets 和动态能力

assets 不会像普通资源那样参与细粒度优化，放进去的文件通常会原样进入包体。

适合放在 assets 的内容：

小型配置文件；
必须随包内置的模型或规则；
首次启动必须可用的轻量数据。

不适合：

大视频；
大型模型；
可在线更新的内容；
调试文件和临时数据。

回看清单

体积优化先分析构成，不要凭感觉删。
R8 的体积收益主要来自裁剪，不是混淆本身。
shrinkResources 要和 R8 一起开启才更有效。
Native 体积重点看 ABI 和符号。
大资源优先考虑按需下载或动态交付。

Android 内存管理：泄漏、缓存与排查工具

Sun, 15 Jun 2025 13:05:49 +0800

Android 内存问题通常分两类：一类是对象本来应该被释放却仍被引用，也就是内存泄漏；另一类是对象没有泄漏，但占用过大或释放不及时，导致频繁 GC、卡顿甚至 OOM。

核心结论

泄漏本质是生命周期较长的对象持有了生命周期较短的对象。
Activity、Fragment、View、Context 是最常见的泄漏对象。
Bitmap、大集合、缓存和 Native 资源要主动控制大小和释放时机。
onTrimMemory() 是系统给应用释放资源的信号，不应该忽略。
排查时先用 LeakCanary 找引用链，再用 Profiler/MAT 分析大对象和堆占用。

常见泄漏来源

Context 泄漏

不要让单例、静态变量、长生命周期任务持有 Activity Context。

object ImageLoader {
 private lateinit var appContext: Context

 fun init(context: Context) {
 appContext = context.applicationContext
 }
}

Handler 和回调泄漏

如果延迟任务持有 View 或 Activity，页面销毁后任务仍在队列中，就可能导致泄漏。

处理方式：

在 onDestroy() / onDestroyView() 移除回调；
避免匿名内部类长期持有页面；
协程场景使用生命周期绑定的 scope。

override fun onDestroyView() {
 handler.removeCallbacksAndMessages(null)
 super.onDestroyView()
}

注册未反注册

常见对象：

BroadcastReceiver
监听器
EventBus / Flow collector
Sensor callback
Location callback

原则：在哪里注册，就要有清晰的反注册位置。

大对象和缓存

Bitmap

Bitmap 是 Android 内存问题高发点。

建议：

使用 Glide/Coil 这类成熟图片库；
按目标尺寸加载，不加载原图；
避免在列表中持有大量 Bitmap；
大图预览要关注采样率和生命周期。

缓存

缓存不是越大越好。缓存应该有上限、淘汰策略和内存压力响应。

常用策略：

内存缓存用 LruCache；
磁盘缓存用成熟库或明确目录；
收到 onTrimMemory() 时主动降级或清理；
不把页面对象放进全局缓存。

onTrimMemory

onTrimMemory(level) 表示系统希望应用释放一部分内存。

常见处理：

override fun onTrimMemory(level: Int) {
 super.onTrimMemory(level)
 if (level >= TRIM_MEMORY_RUNNING_LOW) {
 imageCache.trimToSize(imageCache.size() / 2)
 }
}

需要关注的信号：

level	含义	建议
`TRIM_MEMORY_UI_HIDDEN`	UI 不可见	释放 UI 相关缓存
`TRIM_MEMORY_RUNNING_LOW`	运行中内存偏低	降低缓存
`TRIM_MEMORY_RUNNING_CRITICAL`	内存非常紧张	尽可能释放非必要资源

排查工具

LeakCanary

适合自动发现 Activity、Fragment、ViewModel 等对象泄漏。

debugImplementation("com.squareup.leakcanary:leakcanary-android:2.x")

重点看：

泄漏对象是什么；
GC Root 到泄漏对象的引用链；
哪个长生命周期对象持有了它。

Android Studio Profiler

适合观察：

堆内存变化；
GC 频率；
对象分配热点；
Heap Dump。

MAT

适合分析复杂堆快照：

Dominator Tree 看谁占用最大；
Path to GC Roots 看为什么无法释放；
Histogram 看对象数量是否异常。

回看清单

生命周期长的对象不要持有生命周期短的对象。
页面销毁时清理 Handler、监听器、Receiver 和异步任务。
大图和缓存必须有大小上限。
系统内存压力回调要释放非必要资源。
泄漏看引用链，OOM 看对象占用和分配趋势。

Android View 性能优化：从测量、绘制到过度绘制

Fri, 13 Jun 2025 23:55:35 +0800

View 性能问题通常不是单点问题，而是发生在一帧渲染链路中的某个阶段：测量太重、布局太深、绘制指令太多、GPU 重复填充，或者动画过程中反复触发布局。

这篇笔记的目标是把优化动作放回渲染链路里理解，而不是只记一堆零散技巧。

核心结论

布局阶段看层级和测量次数：减少嵌套，避免无意义的二次测量。
绘制阶段看 onDraw() 成本：不要在绘制路径里分配对象、做 I/O 或触发布局。
GPU 阶段看过度绘制和混合：减少被完全覆盖的背景和大面积半透明。
动画阶段看是否触发重新布局：优先使用 translationX/Y、alpha、scale 等属性动画。
硬件层只作为优化选项：具体原理和使用边界放到《Android 硬件加速》里单独整理。

一帧里的性能检查点

输入事件 / 状态变化
 -> measure
 -> layout
 -> draw / record DisplayList
 -> GPU rasterize
 -> SurfaceFlinger 合成
 -> 显示

优化时先判断卡顿发生在哪一段：

阶段	常见问题	典型优化
measure	布局层级深、权重布局二次测量	减少嵌套，使用 `ConstraintLayout`，缓存测量结果
layout	频繁 `requestLayout()`	避免在动画中改变布局参数
draw	`onDraw()` 分配对象或复杂计算	复用 `Paint/Path/Rect`，提前计算
GPU	过度绘制、半透明混合	移除无效背景，控制透明层
合成	大量离屏图层	谨慎使用硬件层和裁剪

布局优化

布局优化关注 measure 和 layout 两个阶段。

常见策略：

减少布局嵌套

深层嵌套会增加遍历和测量成本。简单页面可以用 ConstraintLayout 合并层级，但不要为了“扁平”制造过度复杂的约束。
避免 LinearLayout 权重滥用

layout_weight 可能导致额外测量。列表项、复杂卡片或高频刷新区域要谨慎使用。
使用 <merge> 和 ViewStub

<merge> 适合消除无意义的根容器，ViewStub 适合延迟加载低频出现的内容。
自定义 ViewGroup 缓存测量结果

如果子 View 尺寸和约束稳定，可以缓存中间计算，避免每次 onMeasure() 重复推导。

绘制优化

onDraw() 会在一帧内被频繁调用，必须保持轻量。

不要在 onDraw() 中做这些事：

创建 Paint、Path、Bitmap、Rect 等对象；
读取文件、解析数据、访问网络；
做复杂业务计算；
调用 invalidate() 或 requestLayout() 形成循环；
绘制屏幕外或被遮挡的内容。

推荐做法：

class ChartView(context: Context) : View(context) {
 private val linePaint = Paint(Paint.ANTI_ALIAS_FLAG)
 private val contentRect = RectF()

 override fun onSizeChanged(w: Int, h: Int, oldw: Int, oldh: Int) {
 contentRect.set(0f, 0f, w.toFloat(), h.toFloat())
 }

 override fun onDraw(canvas: Canvas) {
 if (canvas.quickReject(contentRect, Canvas.EdgeType.AA)) return
 canvas.drawLine(0f, height / 2f, width.toFloat(), height / 2f, linePaint)
 }
}

过度绘制优化

过度绘制指同一个像素在一帧内被重复绘制多次。它会增加 GPU 填充压力，尤其在列表、复杂卡片和半透明蒙层中很常见。

排查入口：

开发者选项 -> 调试 GPU 过度绘制

优化动作：

移除 Activity 根布局、主题、容器里的重复背景；
删除被完全覆盖的中间层背景；
避免大面积半透明 View；
自定义绘制时使用 clipRect() 限制绘制区域；
对屏幕外区域使用 quickReject() 提前跳过。

硬件层提示

硬件层属于绘制与合成阶段的优化手段，适合短时间属性动画，但不适合长期、大面积启用。这里不展开原理，具体的 CPU/GPU 分工、DisplayList 和硬件层边界，统一放在《Android 硬件加速：CPU、GPU 与硬件层》中整理。

常用工具

Profile GPU Rendering：观察每帧耗时，判断是否超过 16.6ms。
Layout Inspector：查看布局层级、约束和 View 树。
Debug GPU Overdraw：定位重复绘制。
Perfetto / System Trace：分析主线程、RenderThread 和系统调度。
Memory Profiler：排查绘制过程中的异常分配。

回看清单

卡顿先定位阶段，不要一上来就改代码。
布局优化看层级、测量次数和 requestLayout() 触发频率。
绘制优化看 onDraw() 是否分配对象、做计算或绘制不可见区域。
GPU 优化看过度绘制、半透明和离屏图层。
硬件层只作为候选优化项，具体使用边界回到硬件加速笔记判断。

Android 硬件加速：CPU、GPU 与硬件层

Fri, 13 Jun 2025 22:50:57 +0800

硬件加速的核心不是“打开 GPU 就一定更快”，而是把绘制流程拆成两部分：CPU 负责记录绘制命令，GPU 负责把命令转换成像素。

核心结论

硬件加速后，onDraw() 仍然会在主线程执行，但绘制命令会被记录成 DisplayList。
GPU 负责光栅化，把图形命令转换成最终像素。
硬件层可以缓存 View 的绘制结果，适合短期属性动画。
硬件层不是越多越好，大面积或长期启用会增加显存压力。

未启用硬件加速

简化流程：

View 树遍历
 -> measure/layout
 -> CPU 执行 onDraw()
 -> CPU 光栅化
 -> 写入图形缓冲区
 -> 显示

此时 CPU 既要处理业务逻辑、布局计算，也要承担像素计算，复杂页面容易成为瓶颈。

启用硬件加速

简化流程：

View 树遍历
 -> measure/layout
 -> CPU 执行 onDraw() 并记录 DisplayList
 -> RenderThread / GPU 消费绘制命令
 -> GPU 光栅化
 -> 写入 Buffer
 -> SurfaceFlinger 合成显示

这里的关键变化是：Canvas 的很多调用不再立即生成像素，而是记录成绘制指令。GPU 后续可以并行处理这些指令。

DisplayList 的意义

DisplayList 可以理解为 View 绘制结果的命令列表：

drawRect(...)
drawText(...)
drawBitmap(...)
clipPath(...)

如果 View 内容没有变化，系统可以复用已有 DisplayList，减少主线程重复记录绘制命令的成本。

但如果调用了 invalidate()，对应 View 的 DisplayList 仍然需要重新记录。

硬件层

硬件层会把 View 的绘制结果缓存成 GPU 纹理：

View -> DisplayList -> GPU 光栅化 -> 离屏纹理

后续如果只是做平移、缩放、旋转、透明度变化，就可以直接复用纹理合成，不必重新绘制 View 内容。

适合场景：

短时间属性动画；
小面积复杂 View；
内容不变，只做变换。

不适合场景：

大面积列表；
每帧内容都变化的自定义 View；
长期启用的普通控件；
内存紧张的页面。

使用方式

view.setLayerType(View.LAYER_TYPE_HARDWARE, null)

view.animate()
 .translationY(100f)
 .alpha(0f)
 .withEndAction {
 view.setLayerType(View.LAYER_TYPE_NONE, null)
 }

回看清单

硬件加速不是跳过 onDraw()，而是改变绘制命令的执行方式。
CPU 负责记录命令，GPU 负责光栅化和合成。
DisplayList 可以减少重复记录绘制命令。
硬件层适合短期动画缓存，不适合长期全局开启。
判断是否需要硬件层，要看 View 内容是否稳定、面积是否可控、动画是否只做属性变换。

RecyclerView 缓存机制：Scrap、Cache 与 RecycledViewPool

Wed, 11 Jun 2025 15:26:57 +0800

RecyclerView 的性能核心不是“少创建几个 ViewHolder”这么简单，而是通过多级缓存把不同状态的 ViewHolder 放在不同位置，尽量减少创建、绑定和布局成本。

核心结论

屏幕内重新布局优先命中 attachedScrap，通常不需要重新绑定。
屏幕外短距离滑动优先命中 mCachedViews，默认容量较小。
RecycledViewPool 按 viewType 复用 ViewHolder，通常需要重新绑定。
changedScrap 服务于更新动画和局部刷新。
Stable IDs 能让 RecyclerView 在位置变化时仍按数据身份匹配 ViewHolder。

多级缓存模型

RecyclerView.Recycler
├── attachedScrap
│ └── 布局过程中临时保存屏幕内 ViewHolder
├── changedScrap
│ └── 保存发生数据变化、用于动画过渡的 ViewHolder
├── mCachedViews
│ └── 保存刚离开屏幕的 ViewHolder，按 position 优先复用
├── ViewCacheExtension
│ └── 业务自定义缓存入口，较少使用
└── RecycledViewPool
 └── 按 viewType 分类的共享回收池

可以粗略记成：

越靠前，越接近原位置，复用成本越低；
越靠后，越通用，但越可能需要重新绑定。

attachedScrap

attachedScrap 用在布局过程中。

当 RecyclerView 重新布局时，当前可见的 ViewHolder 会先被临时放进 attachedScrap。布局管理器再次需要某个 position 时，可以直接取回来。

特点：

主要服务屏幕内重新布局；
通常按 position 匹配；
命中后一般不需要重新创建，也不需要重新绑定；
成本最低。

changedScrap

changedScrap 主要服务更新动画。

当调用 notifyItemChanged() 或发生可动画的数据变化时，旧 ViewHolder 可能会进入 changedScrap，用于和新状态做动画过渡。

特点：

和 ItemAnimator 关系密切；
可能需要重新绑定；
用于保留变化前后的 ViewHolder 状态；
让局部刷新不至于直接闪烁。

mCachedViews

mCachedViews 保存刚离开屏幕的 ViewHolder，默认容量通常较小。

它的价值在于：用户短距离来回滑动时，刚离开的 item 很可能马上回来。这时直接复用可以避免重新绑定。

特点：

默认容量有限；
更偏向 position 级别复用；
命中后可能不需要重新绑定；
适合处理短距离滚动回退。

RecycledViewPool

RecycledViewPool 是更通用的回收池，按 viewType 分类。

进入这里的 ViewHolder 已经和具体 position 脱钩。复用时只保证类型匹配，不保证数据仍然正确，因此通常要重新执行 onBindViewHolder()。

适合场景：

长列表复用；
多个 RecyclerView 共享同类 item；
ViewHolder 创建成本较高；
页面中存在嵌套列表。

Stable IDs 的作用

默认情况下，RecyclerView 更依赖 position 判断 item 身份。数据插入、删除、排序后，position 会变化，这可能影响动画和复用判断。

启用 Stable IDs 后：

adapter.setHasStableIds(true)

override fun getItemId(position: Int): Long {
 return items[position].id
}

RecyclerView 可以用稳定 ID 判断“这是同一条数据”，即使它的位置变了。

适合：

数据有天然唯一 ID；
列表存在插入、删除、排序；
需要更稳定的变更动画；
配合 DiffUtil 或 ListAdapter 使用。

注意：Stable ID 必须稳定且唯一。如果 ID 错误，复用错乱会更难排查。

回看清单

attachedScrap 解决屏幕内布局复用。
changedScrap 解决变化动画和局部刷新。
mCachedViews 解决短距离滑动回退。
RecycledViewPool 解决跨位置、跨列表的通用复用。
Stable IDs 用数据身份补足 position 的不稳定性。