1. 为什么你的 App 越用越卡从布局层级到内存泄漏的排查现场Android 性能优化这件事很多人第一反应是「换个好手机就不卡了」但真实情况是同一台设备上有的 App 滑动跟手、页面秒开有的 App 点一下卡半秒、用十分钟就开始发烫掉帧。差距往往不在业务逻辑有多复杂而在布局层级是不是套了五六层、内存里是不是悄悄堆了一堆本该回收的对象。这篇面向已经能写业务代码、但还没系统做过性能排查的 Android 开发者。核心解决三类高频问题布局嵌套过深导致渲染耗时高、内存占用随页面切换持续上涨、以及内存泄漏让 Activity 无法释放。我会给出可以直接复制到项目里的布局检查方式、内存分析配置片段以及一套「优化前后对比帧率、内存曲线、泄漏对象数量」的验证动作。你不需要一开始就上 Profiler 全套先把最常见的几个坑填掉效果就已经很明显。我试过在一个列表页里把三层 LinearLayout 嵌套改成一层 ConstraintLayout滚动时的掉帧次数直接少了一半。下面按「先看布局、再看内存、最后抓泄漏」的顺序展开每一步都配可复制的代码和验证方法。2. 前置准备用 TaoToken 补齐排查思路与配置片段性能优化最耗时间的不是改代码而是「不知道该查什么」。布局层级怎么看、内存曲线怎么读、泄漏对象怎么定位这些经验性的东西如果每次都在搜索引擎里翻半天效率很低。我的做法是先把排查思路和配置片段用模型对话理清楚再动手改。TaoToken 在这里的角色是统一入口它把常用模型的调用收敛成一套 API你不用为每个模型单独维护 Key 和请求格式。对 Android 性能优化这种「需要边查边试」的场景直接开模型对话问「ConstraintLayout 替代嵌套 LinearLayout 后哪些属性要注意」比翻文档快得多。如果你只是临时查几个配置片段用模型对话就够了如果你打算把性能排查脚本、CI 里的静态检查长期跑起来可以看 Coding Plan接入到自己的工具链里则用 API Keys 配好密钥。地址统一走官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 不加 UTM。注意这里只做思路和配置的辅助真正的性能数据必须来自你自己的设备和 Profiler别拿别人的评测数字当结论。3. 布局优化减少嵌套与按需加载的可复制配置3.1 先量化布局层级别凭感觉改改布局之前先拿到数据。Android Studio 自带的 Layout Inspector 可以看层级树但更轻量的方式是在代码里打印测量耗时。下面这段放在 Activity 的onCreate之后能粗略看出根布局测量花了多久// 在 setContentView 之后调用观察测量布局耗时 window.decorView.post { val start System.nanoTime() window.decorView.measure( View.MeasureSpec.makeMeasureSpec(window.decorView.width, View.MeasureSpec.EXACTLY), View.MeasureSpec.makeMeasureSpec(window.decorView.height, View.MeasureSpec.EXACTLY) ) val cost (System.nanoTime() - start) / 1_000_000 Log.d(PerfLayout, decorView measure cost ${cost}ms) }实测下来一个正常页面这个值应该在个位数毫秒。如果超过 16ms基本可以确定布局有问题接下来用 Layout Inspector 数层级从根节点到最深的叶子节点超过 10 层就要警惕。3.2 用 ConstraintLayout 压平嵌套最常见的坏味道是「LinearLayout 套 LinearLayout 再套 RelativeLayout」。每多一层测量和布局就要多走一遍。把下面这种结构!-- 优化前三层嵌套 -- LinearLayout android:orientationvertical ... LinearLayout android:orientationhorizontal ... ImageView ... / LinearLayout android:orientationvertical ... TextView ... / TextView ... / /LinearLayout /LinearLayout /LinearLayout改成一层 ConstraintLayout!-- 优化后单层约束 -- androidx.constraintlayout.widget.ConstraintLayout ... ImageView android:idid/avatar app:layout_constraintStart_toStartOfparent app:layout_constraintTop_toTopOfparent ... / TextView android:idid/title app:layout_constraintStart_toEndOfid/avatar app:layout_constraintTop_toTopOfid/avatar ... / TextView android:idid/subtitle app:layout_constraintStart_toStartOfid/title app:layout_constraintTop_toBottomOfid/title ... / /androidx.constraintlayout.widget.ConstraintLayout层级从 4 层降到 1 层测量次数明显减少。注意 ConstraintLayout 不是越多越好它自身测量比 LinearLayout 略重所以只在「确实需要压平嵌套」时用。3.3 ViewStub 按需加载低频布局有些布局比如空状态、错误提示、详情展开区首屏根本用不到却跟着一起 inflate。用 ViewStub 延迟加载ViewStub android:idid/stub_error android:layoutlayout/layout_error_tip android:layout_widthmatch_parent android:layout_heightwrap_content /// 真正需要时才加载 val stub findViewByIdViewStub(R.id.stub_error) stub.inflate() // 只调用一次重复调用会抛异常这样首屏 inflate 的 View 数量减少冷启动和页面切换都会更快。4. 内存优化从占用曲线到泄漏对象的排查配置4.1 先看内存曲线判断是「占用高」还是「泄漏」打开 Android Studio 的 Profiler选 Memory 面板反复进出同一个页面 5 次。如果每次退出后内存都能回落到接近进入前的水平说明只是正常占用如果每次都比上一次高、且不回落那就是泄漏。判断标准很直接连续进出 5 次如果最终内存比初始高出一大截且 GC 后不降基本可以锁定泄漏。下面这段代码可以在页面销毁时主动触发一次 GC 观察override fun onDestroy() { super.onDestroy() // 仅用于调试生产环境不要保留 Runtime.getRuntime().gc() Log.d(PerfMem, after gc, used ${ (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory()) / 1024 / 1024 }MB) }4.2 静态变量持有 Context 是最隐蔽的坑静态变量生命周期和进程一样长一旦它持有 Activity 或 ViewActivity 就永远回收不了。典型错误// 错误静态变量持有 Activity companion object { var sInstance: MainActivity? null }改成持有 ApplicationContext或者干脆不持有// 正确需要 Context 时用 applicationContext companion object { private var appContext: Context? null fun init(context: Context) { appContext context.applicationContext } }4.3 Bitmap、Cursor、动画三类高频泄漏Bitmap 泄漏通常是大图没回收或缓存没上限用BitmapFactory.Options的inSampleSize做下采样缓存用 LruCache 设上限。Cursor 泄漏是查询后忘了close()用use {}自动关闭contentResolver.query(uri, null, null, null, null)?.use { cursor - while (cursor.moveToNext()) { // 读取数据 } } // 自动 close动画泄漏最容易被忽略ObjectAnimator启动后如果页面销毁时没取消动画会一直持有 ViewView 又持有 Activity。务必在onDestroy里取消private var animator: ObjectAnimator? null override fun onDestroy() { animator?.cancel() // 关键不取消就会泄漏 animator null super.onDestroy() }5. 验证请求与成功结果对比优化前后的三组数据改完必须验证否则不知道有没有效果。下面给出三组对比动作。第一组帧率对比。用adb shell dumpsys gfxinfo 包名拿到绘制耗时或者用 GPU 渲染模式分析。优化前记录一次滑动 10 秒的掉帧数优化后再记录一次掉帧数下降即有效。第二组内存曲线对比。Profiler 里反复进出页面 5 次优化前如果内存阶梯式上涨优化后应该能看到回落。把两次的曲线截图放一起趋势一目了然。第三组泄漏对象数量。用 LeakCanary 接入后优化前会报出具体泄漏引用链优化后同样的操作不再报泄漏。LeakCanary 依赖debugImplementation com.squareup.leakcanary:leakcanary-android:2.14接入后不需要写任何代码进出页面时如果发生泄漏通知栏会直接弹出引用链告诉你「谁持有了谁」。修完再看通知不再出现就是成功。如果你在验证阶段想快速确认某个 API 的用法或配置参数可以直接用模型对话问比翻源码快。地址https://taotoken.net/api 不加 UTM。6. 本篇常见错排查布局改了但没效果先确认改的是真正耗时的页面用 Layout Inspector 对比改前改后的层级数别改了个不相关的子布局。内存曲线还是涨检查是不是有静态集合只增不减比如static List一直 add 从不 remove这种不是「泄漏」但效果一样。LeakCanary 没报但内存不降可能是大对象缓存没上限或者线程池里的任务持有外部引用用 Profiler 的 Heap Dump 手动看支配树。动画取消后仍泄漏确认取消的是同一个 animator 实例如果每次 new 一个再启动取消的是旧实例新的还在跑。ViewStub inflate 崩溃ViewStub 只能 inflate 一次第二次调用会抛IllegalStateException用前先判空或置 null。7. 把排查动作固化下来性能优化不是一次性任务而是每次提测前的固定动作。我的习惯是新页面写完先跑一次布局层级检查超过 10 层就重构涉及图片和动画的页面进出 5 次看内存曲线发版前用 LeakCanary 跑一遍主流程。这三步花不了多少时间但能挡掉大部分线上卡顿和 OOM 投诉。需要长期把这些检查脚本和静态规则跑在 CI 里的话可以看 Coding Plan只是临时查配置和排查思路模型对话就够用。密钥在 API Keys 页面配好接入文档里有完整的请求示例。地址统一从官网进https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。
 是怎么计算的)
