Android性能优化这件事说大不大说小不小。每个做Android开发的人迟早都会遇到三类问题应用冷启动白屏时间太长、内存占用居高不下导致被系统杀掉、列表滑动时掉帧卡顿。这三个问题看似独立实际上经常互相纠缠——启动时加载太多资源导致内存峰值过高内存频繁GC又反过来造成卡顿。我这些年在这三个方向上踩过的坑比写过的业务代码还多。这篇内容就是把我实际排查过程中用到的思路、工具、命令和判断标准整理出来给正在被这些问题困扰的同行一个可以直接参考的排查路径。不管你是刚接触性能优化的初中级开发还是已经做过几轮优化但总觉得不够系统的资深工程师下面这些实操细节应该都能对上你的某些场景。1. 冷启动耗时到底耗在了哪里1.1 启动过程的三个阶段与可优化窗口Android应用的冷启动从用户点击桌面图标到看到第一帧内容系统层面经历了进程创建、Application初始化、Activity创建与布局渲染这几个大阶段。很多文章把启动优化简单归结为减少Application里的初始化工作这话没错但太粗。实际排查时你需要把启动时间线拆得更细才能定位到真正的瓶颈。我通常把冷启动划分为三个可观测的阶段进程创建到Application.onCreate()之前这段时间主要消耗在系统fork进程、加载dex、初始化ClassLoader上。如果这个阶段耗时超过300ms通常意味着你的dex文件太大或者MultiDex没有做好优化。Application.onCreate()到Activity.onCreate()之前这是大多数团队集中优化的区域第三方SDK初始化、埋点注册、全局配置加载都在这里。Activity.onCreate()到首帧绘制完成包括setContentView的布局解析、View的measure/layout/draw、以及首屏数据的同步加载。判断瓶颈在哪个阶段最直接的办法是用adb shell am start -W命令看三个时间指标adb shell am start -W -n com.example.app/.MainActivity输出里的TotalTime是应用层看到的启动耗时WaitTime包含了系统调度的时间。如果TotalTime和WaitTime差距很大说明系统层面有调度压力不完全是你的代码问题。如果两者接近但数值都很大那就得往应用内部查。更精细的分析需要用Systrace或Perfetto抓取启动过程的完整trace。我一般用Perfetto的命令行模式抓前5秒perfetto -c -o /data/misc/perfetto-traces/trace.perfetto-trace \ -t 5s sched freq idle am wm gfx view binder_driver hal dalvik camera input res抓完之后把文件拉到本地用Perfetto UI打开重点看主线程的slice分布。你会很直观地看到哪些方法是又长又粗的块——那些就是需要干掉或异步化的目标。1.2 用启动窗口和ReportFullyDrawn量化首帧体验有一个容易被忽略的点用户感知到的启动完成和开发者认为的启动完成往往不是一回事。系统在进程创建后会先显示一个启动窗口Starting Window通常是主题里设置的windowBackground。如果你的主题背景是纯白色而实际内容页是深色用户就会看到一闪的白屏。解决白屏有两种思路。第一种是把启动主题的windowBackground设置成和首页背景一致的颜色或图片这样启动窗口到真实内容之间过渡自然。第二种是设置windowDisablePreview为true直接不显示预览窗口但这会导致点击图标后有一段无反馈的等待期体验反而更差一般不推荐。style nameLaunchTheme parentAppTheme item nameandroid:windowBackgrounddrawable/launch_bg/item /style量化首帧之后的内容加载时间可以用reportFullyDrawn()方法。在首屏真正对用户可交互的时候调用它Override public void onWindowFocusChanged(boolean hasFocus) { if (hasFocus !isFullyDrawnReported) { reportFullyDrawn(); isFullyDrawnReported true; } }然后在logcat里过滤Fully drawn关键字就能看到从启动到完全可用的总耗时。这个数据比am start -W的TotalTime更贴近用户真实感受因为TotalTime只统计到首帧绘制不包含后续的数据填充。1.3 启动阶段初始化的分级策略我在多个项目里用过的初始化分级方案核心思路是把所有初始化任务按是否阻塞首帧分成三档优先级判断标准处理方式典型任务P0不初始化会导致崩溃或首屏无数据主线程同步执行崩溃监控、核心配置、首屏缓存读取P1首帧不需要但短时间内会用到首帧后异步执行埋点SDK、图片库配置、网络库初始化P2可以延迟到用户触发时才初始化懒加载或空闲时执行分享SDK、推送注册、非核心第三方库P1级别的任务可以用Handler.postDelayed或者IdleHandler来调度。IdleHandler的好处是它会在主线程消息队列空闲时才执行不会和首帧渲染抢CPULooper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() { Override public boolean queueIdle() { // 执行P1级别的初始化 initAnalytics(); initImageLoader(); return false; // 返回false表示只执行一次 } });P2级别的任务我通常封装一个懒加载工具类在真正调用某个SDK的API时才触发初始化。比如分享功能用户不点分享按钮就永远不初始化。注意异步初始化时要特别小心线程安全问题。有些SDK的初始化方法内部依赖主线程Looper放到子线程会直接抛异常。我遇到过某地图SDK必须在主线程初始化的情况这种就只能老老实实放主线程但可以通过延迟到首帧之后来减少对启动时间的影响。1.4 启动优化的实测数据与常见误区在一个中等规模的电商App上我做过一轮完整的启动优化数据变化如下优化前冷启动TotalTime1850ms异步化P1任务后1320ms首屏数据改用缓存异步刷新后980ms启动主题改为与首页一致的背景后用户感知白屏时间从600ms降到接近0但这里有个误区值得说不是所有启动时间都能压到很低。有些App首屏必须展示实时数据那就必须等网络请求回来这种情况下你能做的是用骨架屏或缓存数据先占位而不是硬等。我见过有团队为了追求启动速度指标把首屏数据改成纯缓存结果用户看到的是过期价格投诉反而更多。性能优化永远要服务于用户体验不是服务于数字。另一个常见误区是过度依赖AsyncTask或裸线程做初始化。线程创建本身有开销大量并发线程反而会加剧CPU竞争。推荐用统一的线程池来管理初始化任务控制并发数量。2. 内存问题不只是泄漏两个字2.1 先搞清楚是泄漏还是抖动很多人一遇到OOM就说是内存泄漏但实际上内存问题至少分两种泄漏Leak和抖动Churn。泄漏是指对象不再使用但无法被GC回收内存占用持续上升抖动是指短时间内大量对象被创建和销毁导致GC频繁触发表现为卡顿而非OOM。区分方法很简单连续操作某个页面多次比如进出详情页10次然后手动触发GC观察内存是否回到基线水平。如果每次进出后内存基线都在抬高那就是泄漏如果基线稳定但GC次数很多那就是抖动。手动触发GC可以用Android Studio的Profiler也可以通过adb命令adb shell am dumpheap com.example.app /data/local/tmp/heap.hprof拿到hprof文件后用MAT或Android Studio的Heap Analyzer打开看Dominator Tree里占用最大的对象。但要注意hprof文件默认包含所有对象分析起来很重。可以在dump之前先触发一次GCadb shell am send-trim-memory com.example.app RUNNING_CRITICAL2.2 LeakCanary之外的手动排查路径LeakCanary确实是好工具但有些场景它覆盖不到比如系统框架层的泄漏、或者需要特定操作序列才能复现的泄漏。这时候手动排查能力就很重要。我的手动排查流程一般是这样的用Profiler的Memory视图记录一段操作前后的内存快照对比两次快照中Activity/Fragment实例的数量如果某个Activity实例数量大于1说明有泄漏在Heap Analyzer里查看该实例的GC Roots引用链根据引用链定位到持有它的对象常见的泄漏引用链有几种典型模式静态变量持有Activity比如单例模式里传了Context结果传的是Activity而不是ApplicationContext非静态内部类/匿名类Handler、Runnable、AsyncTask内部类隐式持有外部类引用未注销的监听器EventBus、广播接收器、传感器监听没有在onDestroy里反注册资源未关闭Cursor、InputStream、Bitmap没有及时recycle// 典型泄漏写法 public class MainActivity extends Activity { private static Handler sHandler new Handler() { Override public void handleMessage(Message msg) { // 隐式持有MainActivity引用 } }; } // 修正写法 public class MainActivity extends Activity { private static class SafeHandler extends Handler { private final WeakReferenceMainActivity mRef; SafeHandler(MainActivity activity) { mRef new WeakReference(activity); } Override public void handleMessage(Message msg) { MainActivity activity mRef.get(); if (activity null || activity.isFinishing()) return; // 安全操作 } } }2.3 Bitmap和图片库的内存陷阱图片是Android内存占用的大头没有之一。我见过一个页面因为加载了十几张未压缩的高清大图直接吃掉200MB内存。图片内存优化的核心原则是按需加载按显示尺寸解码。很多团队用Glide或Coil加载图片觉得用了图片库就万事大吉。但图片库只负责缓存和生命周期管理不负责帮你决定解码尺寸。如果你给ImageView设置的尺寸是100x100但加载的原图是2000x2000Glide默认会按ImageView的实际尺寸做下采样但前提是ImageView的宽高已经确定。如果ImageView的宽高是wrap_contentGlide就无法预知目标尺寸只能按原图解码。// 推荐明确指定尺寸 Glide.with(context) .load(url) .override(200, 200) // 明确目标尺寸 .into(imageView); // 或者确保ImageView尺寸确定 ImageView android:layout_width100dp android:layout_height100dp android:scaleTypecenterCrop /另外Bitmap的inPreferredConfig也值得关注。如果图片不需要透明度用RGB_565代替ARGB_8888可以节省一半内存。但要注意RGB_565不支持透明度如果原图有透明通道会显示异常。Glide.with(context) .load(url) .format(DecodeFormat.PREFER_RGB_565) .into(imageView);2.4 内存抖动GC日志里的真相内存抖动比泄漏更隐蔽因为它不会导致OOM但会让你的应用滑动起来像PPT。判断抖动的方法是看GC日志。在logcat里过滤art或dalvikvm标签你会看到类似这样的输出I/art: Background concurrent copying GC freed 32045(2MB) AllocSpace objects, 45% free, 8MB/15MB, paused 1.2ms total 45ms如果这种日志频繁出现比如每秒好几次而且每次freed的对象数量都很大说明你的代码在短时间内创建了大量临时对象。常见的抖动来源在onDraw里创建对象Paint、Rect、Path等对象应该在构造函数里创建而不是每次绘制都new字符串拼接循环里用拼接字符串会创建大量StringBuilder和中间String对象自动装箱在循环里使用Integer、Long等包装类型会频繁触发valueOf的装箱操作onMeasure/onLayout里分配数组自定义View时在测量布局阶段创建临时数组// 抖动写法onDraw里创建对象 Override protected void onDraw(Canvas canvas) { Paint paint new Paint(); // 每次绘制都创建 paint.setColor(Color.RED); canvas.drawCircle(cx, cy, radius, paint); } // 修正提前创建 private final Paint mPaint new Paint(); Override protected void onDraw(Canvas canvas) { mPaint.setColor(Color.RED); canvas.drawCircle(cx, cy, radius, mPaint); }提示Android Studio的Profiler里有一个Memory Churn视图可以直观看到对象分配的频率和类型。如果你看到某个类在短时间内被分配了成千上万个实例那就是抖动的源头。3. 卡顿排查从帧率到调用栈3.1 帧率不是唯一指标说到卡顿很多人第一反应是看帧率FPS。但FPS有个问题它只告诉你平均每秒画了多少帧不告诉你哪一帧超时了。一个页面可能平均FPS有55但每隔几秒就掉到20用户感知就是一卡一卡的。更准确的指标是帧耗时分布。Android系统要求每帧在16.67ms内完成60Hz屏幕如果某帧耗时超过这个值就会掉帧。用Choreographer可以监控每帧的耗时public class FrameMonitor { private long mLastFrameTime 0; private static final long FRAME_THRESHOLD 16; // ms public void start() { Choreographer.getInstance().postFrameCallback(new Choreographer.FrameCallback() { Override public void doFrame(long frameTimeNanos) { if (mLastFrameTime ! 0) { long frameCost (frameTimeNanos - mLastFrameTime) / 1_000_000; if (frameCost FRAME_THRESHOLD) { Log.w(FrameMonitor, 掉帧: frameCost ms); } } mLastFrameTime frameTimeNanos; Choreographer.getInstance().postFrameCallback(this); } }); } }这个监控本身有轻微开销建议只在Debug包或灰度环境开启。3.2 Systrace/Perfetto抓取卡顿现场当用户反馈滑动卡顿时你需要抓到卡顿发生时的现场。Perfetto是目前最推荐的抓取工具它比老版Systrace更强大支持更长的抓取时间和更多的数据源。抓取滑动卡顿的典型命令perfetto -c -o /data/misc/perfetto-traces/swipe.perfetto-trace \ -t 10s sched freq idle am wm gfx view binder_driver hal dalvik input res抓完后在Perfetto UI里打开重点看主线程通常叫main或应用包名的slice。你会看到几种典型的卡顿模式长耗时方法某个方法执行了几百毫秒阻塞了主线程锁等待主线程在等子线程释放锁表现为monitor contentionGC暂停GC相关的slice出现在主线程上布局嵌套过深measure和layout的slice特别长我遇到过一个典型案例列表滑动时每隔几帧就卡一下Perfetto里看到主线程频繁出现String.format的调用。原因是列表项里显示价格时用了String.format(¥%.2f, price)每次绑定数据都格式化一次。改成预格式化或缓存后卡顿消失。3.3 布局层级与过度绘制布局问题导致的卡顿往往在启动和滑动时都会出现。检查布局层级可以用Layout Inspector也可以用adb命令adb shell dumpsys activity top | grep -A 50 View Hierarchy但更直观的是开启GPU过度绘制调试在开发者选项里打开调试GPU过度绘制屏幕会用颜色标注过度绘制程度。蓝色表示绘制一次绿色两次粉色三次红色四次以上。红色区域就是需要优化的地方。减少过度绘制的常用手段移除不必要的background设置特别是嵌套布局里每层都设背景用clipRect或canvas.clipRect()限制绘制区域用merge标签减少布局层级用ViewStub延迟加载不可见布局!-- 优化前三层嵌套 -- LinearLayout FrameLayout LinearLayout TextView / ImageView / /LinearLayout /FrameLayout /LinearLayout !-- 优化后用ConstraintLayout扁平化 -- androidx.constraintlayout.widget.ConstraintLayout TextView / ImageView / /androidx.constraintlayout.widget.ConstraintLayout3.4 主线程任务的识别与迁移卡顿的根本原因只有一个主线程被阻塞了。所以排查卡顿的最终落脚点永远是找出主线程上不该做的事。我常用的主线程任务审计方法是在Debug包里给主线程的Looper设置一个自定义的Printer打印每条消息的处理耗时if (BuildConfig.DEBUG) { Looper.getMainLooper().setMessageLogging(new Printer() { private long mStartTime 0; Override public void println(String x) { if (x.startsWith( Dispatching)) { mStartTime System.currentTimeMillis(); } else if (x.startsWith( Finished)) { long cost System.currentTimeMillis() - mStartTime; if (cost 50) { Log.w(MainThread, 消息处理耗时: cost ms); } } } }); }这个方法的局限是只能看到消息级别的耗时看不到具体是哪个方法。要定位到方法级别还是得靠Perfetto的调用栈。常见的主线程耗时操作包括文件读写SharedPreferences的commit、数据库查询网络请求同步请求绝对不能在主线程大量数据的JSON解析复杂的计算逻辑加密、排序、图片处理频繁的View属性更新每次setText都可能触发requestLayout迁移到子线程时要注意Android的View操作必须在主线程执行。子线程计算完数据后通过runOnUiThread或Handler切回主线程更新UI。4. 工具链的实战组合与数据解读4.1 Android Studio Profiler的正确打开方式Android Studio自带的Profiler是日常排查的首选工具但很多人只用了它10%的功能。我分享一下我的使用习惯。CPU Profiler抓取方法调用栈时选择Trace Java Methods模式采样间隔建议设为1000微秒默认是1000但有些场景可以调到500获得更精细的数据。抓取时不要只抓几秒钟至少覆盖一个完整的操作周期比如从进入页面到页面稳定。Memory Profiler看内存曲线时重点关注三个指标——Java堆、Native堆、Graphics。如果Graphics持续增长不回落说明有Bitmap没释放如果Native堆异常大可能是so库或Native代码的问题。Network Profiler虽然和性能优化不直接相关但它能帮你发现启动时是否有不必要的网络请求。我见过有App在Application.onCreate里发了一个配置请求结果这个请求的超时时间设了30秒直接拖慢了启动。4.2 Perfetto的高级用法自定义Track和SQL查询Perfetto除了看trace还支持用SQL查询trace数据。这对于批量分析特别有用。比如你想找出所有超过50ms的主线程sliceSELECT s.name, s.ts, s.dur / 1000000 AS dur_ms FROM slice s JOIN thread_track tt ON s.track_id tt.id JOIN thread t ON tt.thread_id t.id WHERE t.name main AND s.dur 50000000 ORDER BY s.dur DESC LIMIT 20;这个查询会列出主线程上耗时最长的20个slice直接告诉你优化目标在哪里。另外Perfetto支持添加自定义Track。你可以在代码里用Trace.beginSection()和Trace.endSection()埋点然后在Perfetto里看到自定义的sliceTrace.beginSection(loadUserData); // 加载用户数据 Trace.endSection();注意beginSection和endSection必须成对出现而且不能跨线程。在Release包里这些调用会被自动忽略不影响性能。4.3 线上性能监控的数据采集策略本地的Profiler和Perfetto只能覆盖开发和测试阶段线上用户的真实性能数据需要专门的监控方案。我一般会采集以下几类数据启动耗时通过reportFullyDrawn或自定义埋点上报帧率/掉帧率用Choreographer监控按分钟聚合上报内存占用定期采样Runtime.getRuntime().totalMemory() - freeMemory()以及Debug.getPss()ANR率通过FileObserver监控/data/anr/traces.txt的变化采集频率要控制好太频繁会影响性能本身。我的经验是启动数据每次冷启动都上报帧率数据每分钟聚合一次内存数据每30秒采样一次。// 内存采样示例 public class MemorySampler { public static void sample() { Runtime runtime Runtime.getRuntime(); long usedMemory runtime.totalMemory() - runtime.freeMemory(); long maxMemory runtime.maxMemory(); float usageRatio (float) usedMemory / maxMemory; if (usageRatio 0.8) { // 上报高内存警告 reportMemoryWarning(usedMemory, maxMemory); } } }4.4 排查手册的落地从发现问题到验证修复最后说一下完整的排查闭环。我通常按这个流程走发现问题线上监控报警或用户反馈复现问题在测试机上按用户操作路径复现确认问题稳定出现抓取数据用Perfetto/Profiler抓取问题发生时的trace和内存快照定位根因分析trace找到耗时方法分析hprof找到泄漏引用链制定方案根据根因确定修复方案异步化、缓存、对象复用等验证修复在相同条件下重新抓取数据对比修复前后的指标灰度上线先在小流量验证确认无副作用后全量持续监控上线后观察线上指标是否改善这个流程里最容易出问题的是第6步。很多人改完代码觉得应该好了但没有做量化对比。我的习惯是每次修复都必须有前后数据对比哪怕只是本地测试的数据。没有数据支撑的优化等于没做。另外性能优化不是一次性的工作。业务在迭代代码在变化今天优化好的启动速度可能下个版本加了新功能又退回去了。所以线上监控和定期回归测试是必须的。我一般会在每个版本提测前跑一轮性能基准测试和上个版本对比发现退化就及时排查。提示性能基准测试要在同一台设备、同一网络环境、同一操作路径下进行否则数据没有可比性。我见过有团队用不同机型的数据做对比得出的结论完全不可靠。5. 那些只有踩过才知道的细节5.1 SharedPreferences的apply和commit差异SharedPreferences的commit()是同步写磁盘apply()是异步写内存后异步落盘。在启动阶段如果用commit()写大量数据会直接阻塞主线程。但apply()也不是完全没有开销它虽然异步落盘但内存中的写入是同步的而且如果频繁调用apply()会积压大量待落盘的任务。我的做法是启动阶段只读不写如果必须写用apply()并且合并多次写入为一次。另外SharedPreferences的第一次getSharedPreferences()会加载整个文件到内存如果文件很大比如存了几百个key这个加载过程也会耗时。可以考虑用MMKV等替代方案或者把大文件拆分成多个小文件按需加载。5.2 数据库查询的索引与事务SQLite查询在没有索引的情况下会全表扫描数据量大了之后查询耗时可能从几毫秒变成几百毫秒。我遇到过一个案例本地缓存表有5万条记录查询某个字段时没建索引单次查询耗时200ms放在启动阶段直接让启动时间翻倍。建索引的原则是在WHERE、ORDER BY、JOIN用到的字段上建索引。但索引不是越多越好每个索引都会增加写入时的开销。对于读多写少的缓存表可以适当多建对于写多的表要谨慎。另外批量插入数据时一定要用事务。不用事务的话每条insert都会触发一次磁盘同步1万条数据可能要几十秒。用事务包起来后通常能降到几百毫秒。db.beginTransaction(); try { for (Data data : dataList) { db.insert(table, null, data.toContentValues()); } db.setTransactionSuccessful(); } finally { db.endTransaction(); }5.3 线程池的合理配置启动阶段的异步任务如果都丢给Executors.newCachedThreadPool()会创建大量线程导致CPU频繁切换反而拖慢启动。我一般会根据任务类型配置不同的线程池CPU密集型任务JSON解析、加密线程数设为CPU核心数1IO密集型任务文件读写、网络请求线程数可以设为CPU核心数的2倍串行任务有依赖关系的初始化用单线程池保证顺序// CPU密集型 private static final ExecutorService CPU_POOL new ThreadPoolExecutor( 0, Runtime.getRuntime().availableProcessors() 1, 30, TimeUnit.SECONDS, new LinkedBlockingQueue()); // IO密集型 private static final ExecutorService IO_POOL new ThreadPoolExecutor( 0, Runtime.getRuntime().availableProcessors() * 2, 30, TimeUnit.SECONDS, new LinkedBlockingQueue());5.4 内存泄漏的预防比排查更重要与其等泄漏发生了再去排查不如在编码阶段就做好预防。我总结了几条团队里推行的编码规范单例模式如果需要Context只传getApplicationContext()内部类如果需要引用外部类用static修饰WeakReference所有注册的监听器、广播、EventBus订阅必须在对应的生命周期方法里反注册图片加载必须指定尺寸大图必须做下采样避免在循环里创建对象尤其是字符串拼接和自动装箱这些规范看起来简单但真正执行到位需要Code Review时严格把关。我见过太多团队规范写得漂亮但Review时没人看最后还是靠LeakCanary兜底。5.5 性能优化中的度最后说一个容易被忽视的问题性能优化不是越极致越好。我见过有团队为了把启动时间从800ms压到600ms把首屏数据全部改成缓存结果用户看到的是过期数据也见过为了减少内存占用把图片质量压得很低用户抱怨图片模糊。性能优化的目标是提升用户体验不是追求某个数字的极致。在启动速度、内存占用、功能完整性、开发成本之间永远需要权衡。我的原则是先解决用户能明显感知到的问题比如白屏超过1秒、滑动明显掉帧、频繁被系统杀掉再去抠那些用户感知不强的细节。另外优化要有优先级。启动、内存、卡顿三个方向通常启动优化的投入产出比最高因为用户对启动速度最敏感内存问题如果没到OOM的程度优先级可以适当降低卡顿问题要看具体场景列表滑动卡顿比页面切换卡顿更影响体验。我在实际项目中的体会是性能优化最难的从来不是技术方案而是推动团队持续关注和投入。很多时候你优化好了过几个版本又退回去了。所以建立性能基准测试和线上监控机制比单次优化本身更重要。有了数据支撑你才能说服产品经理和项目经理给性能优化留出排期而不是永远被业务需求挤到最后。