前阵子做灰度回归测试同学拿着一台中端 Android 手机跑了一轮压测脚本结束后第一个冲我喊了一句“今天这手机我扛了。”听起来像在夸手机实际上是在验证 App——“扛住”的意思是在内存紧张、主线程频繁 GC、后台任务并发挤压的情况下应用没有闪退也没有肉眼可见的卡顿。这其实不是运气而是稳定性工程堆出来的结果。本文就把“如何让手机和 App 扛住压力”这件事拆开整理成一套可落地的 Android 性能与稳定性优化方案。内容覆盖四个核心方向内存优化、卡顿监控、全局崩溃兜底、启动提速。每个方向都会给出可复制的代码和配置并解释为什么要这样做。适合以下读者正在做中低端机型适配的 Android 开发者。负责应用稳定性、崩溃率治理的开发者。想系统了解内存、ANR、闪退、启动优化但还没完整实践过的同学。准备做压测、Monkey 测试、性能回归的测试开发。读完你能掌握一套完整的优化思路也能直接拿代码到自己的项目里做局部验证。1. 手机“扛住”压力到底考验的是什么很多人看到“手机扛住了”会觉得是手机硬件性能好但对移动端开发来说这句话考验的其实是应用工程能力。手机硬件是固定的系统资源是有限的真正决定“扛不扛得住”的是 App 如何分配和使用这些资源。一个 Android 应用运行在手机上主要消耗四类资源内存对象实例、Bitmap、缓存、Activity 界面都会占用内存内存超过系统阈值就会触发 OOM。CPU主线程的任务执行、布局测量、绘制、垃圾回收都会消耗 CPU一旦主线程长时间被占用就会卡顿甚至 ANR。存储 IO读取数据库、加载文件、写日志等操作如果放在主线程同样会阻塞界面。网络与系统调度网络请求超时、后台任务被系统杀死、进程被回收也会影响整体体验。所谓“扛住”就是在这些资源都比较紧张时App 依然能保持基本可用内存不会突然飙升到 OOM。主线程不会长时间卡死。出现异常时不会直接闪退或者至少能记录崩溃现场。冷启动速度在可接受范围内。进一步说Android 碎片化严重中低端机型的内存只有 4GB 甚至更少系统后台还驻留着微信、各类工具应用。你的 App 拿到的可用内存可能只有几百 MB这种情况下还能流畅运行才是真正的稳定。所以从工程角度讲优化目标不是跑分而是在低配置、高负载、多任务竞争环境下应用仍然可维护、可运行、可排查问题。2. 环境准备与示例项目说明本教程以 Android 原生项目为例涉及的开发环境如下。版本不需要完全一致重点看配置思路。环境项说明操作系统Windows / macOS / Linux 均可IDEAndroid Studio建议使用稳定版本JDKJDK 17 或项目实际使用的版本Android SDKcompileSdk 建议 34 或以上具体看本地环境构建工具Gradle版本跟随 Android Gradle Plugin 要求测试机型一台中低端 Android 真机建议开启开发者选项和 USB 调试压测工具adb、Monkey、Android Studio Profiler如果没有现成项目可以新建一个空项目来验证。示例项目结构如下antipressure/ ├── app/ │ ├── build.gradle │ └── src/main/ │ ├── AndroidManifest.xml │ └── java/com/example/antipressure/ │ ├── App.java │ ├── MainActivity.java │ ├── crash/ │ │ └── CrashHandler.java │ └── util/ │ ├── AppExecutors.java │ ├── BitmapSampler.java │ └── BlockDetector.java └── build.gradle包名统一使用com.example.antipressure生产项目中请替换成自己的包名。3. 手机扛不住时的四种典型表现在动手优化之前先要知道“扛不住”具体有哪些表现。每一种表现背后对应的是不同层次的系统资源问题排查手段也不一样。3.1 内存溢出OOM和内存抖动最常见的是内存溢出也就是 App 占用的内存超过了系统给进程分配的上限JVM 或 ART 虚拟机直接抛出OutOfMemoryError。表现通常是图片列表滑动到某个位置突然崩溃。加载大图时页面闪退。Logcat 中看到OutOfMemoryError或Failed to allocate memory。还有一种隐蔽情况是内存抖动短时间内大量创建和销毁对象导致频繁内存分配和 GC。GC 会占用 CPU 时间造成界面掉帧用户感觉就是“滑动不跟手”。3.2 卡顿、掉帧与 ANR手机屏幕每 16ms 刷新一帧如果应用主线程在 16ms 内完不成 measure、layout、draw就会出现掉帧。掉帧多了用户就会感觉页面“有点卡”。如果主线程被某个耗时操作阻塞超过 5 秒不同 Android 版本阈值略有差异系统会弹出 ANR 对话框也就是“应用无响应”。常见原因有主线程做了网络请求或大文件读写。布局层级过深测量耗时。主线程持续处理大量计算。被其他进程的 IO 抢占导致执行变慢。3.3 崩溃闪退未捕获的 RuntimeException、空指针、数组越界、Json 解析失败等一旦出现在主线程且没有兜底处理应用就会直接闪退。闪退的危害不只是体验差更严重的是崩溃现场难定位。没有日志、没有堆栈只能靠用户描述开发效率会非常低。3.4 冷启动慢用户从桌面点击图标到看到第一帧内容这个过程就是冷启动。如果 Application 的onCreate里做了大量初始化比如数据库、图片加载库、网络 SDK、各种业务组件的初始化全部堆在主线程启动时间会被明显拉长。在低端机上这个差距会放大用户可能连续点击图标两次导致重复启动。4. 实战从零搭建一个抗压版 Android 项目下面我们进入实战环节。目标不是做一套完整的大型框架而是把四个核心方向的最小可用代码落地让你能直接复制到项目里验证效果。4.1 项目结构与依赖配置先看app/build.gradle的核心配置plugins { id com.android.application } android { namespace com.example.antipressure compileSdk 34 defaultConfig { applicationId com.example.antipressure minSdk 23 targetSdk 34 versionCode 1 versionName 1.0 } compileOptions { sourceCompatibility JavaVersion.VERSION_17 targetCompatibility JavaVersion.VERSION_17 } buildTypes { release { minifyEnabled true shrinkResources true proguardFiles getDefaultProguardFile(proguard-android-optimize.txt), proguard-rules.pro } } } dependencies { implementation androidx.appcompat:appcompat:1.6.1 implementation com.google.android.material:material:1.11.0 // LeakCanary 只参与 debug 包release 包不建议集成 debugImplementation com.squareup.leakcanary:leakcanary-android:2.12 }两点说明compileSdk 34、targetSdk 34不是固定要求请根据你本地的 SDK 环境调整。如果项目已经有版本体系不要强行升级。LeakCanary 建议只用debugImplementation引入只参与调试包构建不影响线上安装包体积和性能。接下来是AndroidManifest.xmlapplication android:name.App android:allowBackuptrue android:iconmipmap/ic_launcher android:labelstring/app_name android:themestyle/Theme.AppCompat.DayNight.NoActionBar activity android:name.MainActivity android:exportedtrue intent-filter action android:nameandroid.intent.action.MAIN / category android:nameandroid.intent.category.LAUNCHER / /intent-filter /activity /application这里把 Application 类指定为.App后续的启动优化和崩溃处理器都会在 App 类里统一接入。4.2 第一关内存压力控制内存优化不是一句“少 new 对象”就能覆盖的实际工程里最容易出问题的是Bitmap 加载、列表缓存、页面级数据缓存三块。4.2.1 Bitmap 采样加载很多 OOM 都发生在图片加载。一张 4000×3000 的图片按 ARGB_8888 计算每个像素占 4 字节直接解码进内存会占用约 48MB。如果在列表中同时滑出多张图内存直接顶不住。正确做法是按需采样。下面是最基础的采样加载工具package com.example.antipressure.util; import android.graphics.Bitmap; import android.graphics.BitmapFactory; public class BitmapSampler { public static Bitmap decodeSampledBitmap(String path, int reqWidth, int reqHeight) { // 第一次只读取宽高不真正解码像素内存占用极低 BitmapFactory.Options options new BitmapFactory.Options(); options.inJustDecodeBounds true; BitmapFactory.decodeFile(path, options); int inSampleSize calculateInSampleSize(options, reqWidth, reqHeight); // 第二次按采样比例正式解码 options.inJustDecodeBounds false; options.inSampleSize inSampleSize; return BitmapFactory.decodeFile(path, options); } private static int calculateInSampleSize(BitmapFactory.Options options, int reqWidth, int reqHeight) { int width options.outWidth; int height options.outHeight; if (reqWidth 0 || reqHeight 0) { return 1; } int inSampleSize 1; // 约束条件采样后的宽高都要小于目标值 while ((width / inSampleSize) reqWidth || (height / inSampleSize) reqHeight) { inSampleSize * 2; } return inSampleSize; } }关键点inJustDecodeBounds true时decodeFile只解析图片头信息不会分配像素内存。inSampleSize必须是 2 的幂系统会对它做向下取整处理。实际项目中更推荐使用 Glide、Coil 等图片加载库内部已经做了采样和缓存可以极大降低手动处理成本。4.2.2 避免内存抖动内存抖动常见于循环内创建对象、字符串拼接、频繁创建监听器。例如for (int i 0; i list.size(); i) { String text item.getTitle() - i; // 这里每次都创建新字符串 holder.textView.setText(text); }如果列表不断刷新这里会创建大量临时字符串触发频繁 GC。优化思路是尽量复用对象。尤其是RecyclerView的onBindViewHolder中不要每次创建新的监听器可以把监听器缓存在 ViewHolder 里。4.2.3 用 LeakCanary 定位内存泄漏内存泄漏不像崩溃那样能立刻看到但它会悄悄蚕食应用内存。LeakCanary是业内常用的内存泄漏检测工具在 debug 包中集成后它会自动监听 Activity 和 Fragment 的销毁发现疑似泄漏时通知你查看堆栈。使用方式非常简单依赖已经加过了只要 debugImplementation 引入LeakCanary 会通过 ContentProvider 自动初始化不需要手动调用初始化方法。当你 debug 运行时发生泄漏通知栏会出现一条“LeakCanary 检测到内存泄漏”的通知里面会显示完整的引用链。需要注意的是LeakCanary 只用于开发调试不能用于线上监控。它的存在本身会占用一定内存和 CPU。4.3 第二关渲染与卡顿监控4.3.1 主线程的职责边界主线程只做一件事处理 UI 事件和绘制。任何耗时操作都不应该出现在主线程上包括网络请求、JSON 解析、数据库查询、Bitmap 解码、文件写入。实际项目中数据库查询是最容易踩坑的点。一条慢 SQL 可能耗时 200ms如果你在 Activity 的onCreate里查一次列表再在onResume里查一次启动过程就多了 400ms用户感知非常明显。4.3.2 用 Looper 监听主线程耗时消息Android 主线程本质是消息循环所有 UI 任务都被封装成 Message 消息。系统提供了Looper.getMainLooper().setMessageLogging()可以打印每条消息的分发和完成时间。我们可以利用这个机制做卡顿监控package com.example.antipressure.util; import android.os.Looper; import android.util.Log; import android.util.Printer; public class BlockDetector { public interface OnBlockListener { void onBlock(long blockTime); } private static final String TAG BlockDetector; private static final long BLOCK_THRESHOLD_MS 300L; private long startTime 0L; private boolean inMessage false; public void start(OnBlockListener listener) { Looper.getMainLooper().setMessageLogging(new Printer() { Override public void println(String log) { if (log null) { return; } // 消息开始分发打印的日志包含标记串 if (log.contains( Dispatching)) { startTime System.currentTimeMillis(); inMessage true; } else if (log.contains( Finished)) { if (inMessage) { long cost System.currentTimeMillis() - startTime; if (cost BLOCK_THRESHOLD_MS) { Log.w(TAG, main thread block: cost ms); if (listener ! null) { listener.onBlock(cost); } } inMessage false; } } } }); } }这个工具的用途是在开发和测试阶段一旦主线程单条消息执行超过 300ms就输出警告。你可以把阈值调低到 100ms 来更早发现卡顿隐患。注意setMessageLogging是全局设置如果项目里其他地方也在设置日志 Printer会互相覆盖。生产环境不建议长期开启适合在压测和调优阶段使用。4.3.3 用线程池替代裸 new Thread很多开发者习惯直接 new Thread但每次创建线程的代价很大而且并发线程数量不受控制。推荐使用统一线程池package com.example.antipressure.util; import java.util.concurrent.ExecutorService; import java.util.concurrent.LinkedBlockingQueue; import java.util.concurrent.ThreadFactory; import java.util.concurrent.ThreadPoolExecutor; import java.util.concurrent.TimeUnit; public final class AppExecutors { private static final int CPU_COUNT Runtime.getRuntime().availableProcessors(); private static final int CORE_POOL_SIZE Math.max(2, Math.min(CPU_COUNT - 1, 4)); private static final int MAX_POOL_SIZE Math.max(CORE_POOL_SIZE * 2, 8); private static final int KEEP_ALIVE_SECONDS 30; private static final ExecutorService IO_EXECUTOR new ThreadPoolExecutor( CORE_POOL_SIZE, MAX_POOL_SIZE, KEEP_ALIVE_SECONDS, TimeUnit.SECONDS, new LinkedBlockingQueue(128), new BaseThreadFactory(app-io), new ThreadPoolExecutor.DiscardPolicy() ); private AppExecutors() { } public static ExecutorService io() { return IO_EXECUTOR; } private static class BaseThreadFactory implements ThreadFactory { private final String prefix; private int sequence 0; BaseThreadFactory(String prefix) { this.prefix prefix; } Override public Thread newThread(Runnable r) { Thread thread new Thread(r, prefix - sequence); thread.setPriority(Thread.NORM_PRIORITY); return thread; } } }这个线程池的核心逻辑corePoolSize根据 CPU 核心数计算避免线程过多。队列容量限制为 128超过部分执行DiscardPolicy即丢弃任务并静默返回。这样做的目的是“丢任务不丢进程”相比AbortPolicy抛异常更适合非核心业务。线程池统一命名后续定位问题时可以在Thread名称中直接看出是哪个池子里的线程。调用方式很简单AppExecutors.io().execute(() - { // 在后台线程执行耗时任务 String result queryDatabase(); runOnUiThread(() - uiView.setText(result)); });4.4 第三关全局崩溃兜底4.4.1 为什么要做全局崩溃捕获即使代码写得再小心线上环境依然可能出现空指针、解析异常、资源找不到等问题。全局崩溃捕获的意义不是“不让 App 退出”而是在崩溃发生前保存现场给开发者留下可分析的日志。没有现场日志线上崩溃基本只能靠猜。需要说明的是不建议通过try-catch吞掉所有异常来阻止闪退。崩溃发生后线程栈可能已经处于不稳定状态强行继续运行容易出现二次崩溃而且会掩盖真实问题。更稳妥的方案是记录崩溃信息然后按系统默认流程退出或谨慎地重启一次。4.4.2 自定义 CrashHandler 实现下面是一个完整的全局崩溃处理器package com.example.antipressure.crash; import android.content.Context; import android.os.Process; import android.util.Log; import java.io.File; import java.io.FileWriter; import java.io.IOException; import java.io.PrintWriter; import java.io.StringWriter; import java.io.Writer; import java.text.SimpleDateFormat; import java.util.Date; import java.util.Locale; public class CrashHandler implements Thread.UncaughtExceptionHandler { private static final String TAG CrashHandler; private static final String FILE_NAME_PREFIX crash_; private final Thread.UncaughtExceptionHandler defaultHandler; private final Context appContext; public CrashHandler(Context context) { this.appContext context.getApplicationContext(); // 保留系统默认处理器避免破坏系统流程 this.defaultHandler Thread.getDefaultUncaughtExceptionHandler(); } public void register() { Thread.setDefaultUncaughtExceptionHandler(this); } Override public void uncaughtException(Thread thread, Throwable throwable) { // 1. 记录崩溃现场 String crashInfo buildCrashInfo(thread, throwable); saveCrashLog(crashInfo); // 2. 先让系统默认处理器处理最终会正常结束进程 if (defaultHandler ! null) { defaultHandler.uncaughtException(thread, throwable); } else { Process.killProcess(Process.myPid()); System.exit(1); } } private String buildCrashInfo(Thread thread, Throwable throwable) { StringWriter sw new StringWriter(); PrintWriter pw new PrintWriter(sw); pw.println(Thread: thread.getName() ( thread.getId() )); pw.println(Time: new SimpleDateFormat(yyyy-MM-dd HH:mm:ss, Locale.getDefault()).format(new Date())); pw.println(Process: Process.myPid()); throwable.printStackTrace(pw); pw.close(); return sw.toString(); } private void saveCrashLog(String content) { File dir new File(appContext.getExternalFilesDir(null), crash_logs); if (!dir.exists() !dir.mkdirs()) { Log.e(TAG, create crash log dir failed); return; } String fileName FILE_NAME_PREFIX System.currentTimeMillis() .txt; File file new File(dir, fileName); try (Writer writer new FileWriter(file)) { writer.write(content); } catch (IOException e) { Log.e(TAG, write crash log failed, e); } } }这段代码做了三件事获取系统默认的UncaughtExceptionHandler保存引用。在自定义处理器中把线程名、时间、进程号、完整堆栈写入本地文件。然后交回默认处理器保证进程按系统逻辑退出。日志写到getExternalFilesDir(null)目录下这是应用专属外部存储不需要额外申请权限卸载时也会自动清理适合保存日志但不适合长期敏感数据。在App类里注册package com.example.antipressure; import android.app.Application; import com.example.antipressure.crash.CrashHandler; public class App extends Application { Override public void onCreate() { super.onCreate(); new CrashHandler(this).register(); } }如果要实现“崩溃后自动重启一次”可以在此基础上增加一个崩溃次数标记。核心思路是把defaultHandler.uncaughtException替换成自己的重启逻辑但必须加上防循环保护——如果 App 启动后 5 秒内再次崩溃说明启动路径有问题此时应该直接退出避免反复重启。4.4.3 线上采集的合规提醒崩溃日志里通常会包含设备型号、系统版本、应用版本、堆栈信息这些属于用户设备信息。如果要把日志上传到自己的服务器必须遵循最小必要原则并确保用户知情同意。建议只采集崩溃堆栈和基本设备信息不要采样用户的账号、手机号、定位等隐私字段。4.5 第四关启动速度优化4.5.1 冷启动流程分析冷启动的耗时点主要在三处Application 的onCreate。首屏 Activity 的onCreate、onStart、onResume。首帧绘制完成之前的布局初始化。很多团队会把所有 SDK 初始化都堆在 Application 里public class App extends Application { Override public void onCreate() { super.onCreate(); initCrash(); initHttp(); initDatabase(); initPush(); initImageLoader(); initTracker(); initReactNative(); } }这样的结果是用户点击图标后要等这些初始化全部跑完才进入主页面启动时间很容易超过 2 秒甚至更长。4.5.2 异步初始化示例优化的核心思路是只把最必要的初始化放在主线程其余全部放到后台线程。package com.example.antipressure; import android.app.Application; import com.example.antipressure.crash.CrashHandler; import com.example.antipressure.util.AppExecutors; public class App extends Application { Override public void onCreate() { super.onCreate(); new CrashHandler(this).register(); // 非关键路径放到后台线程执行 AppExecutors.io().execute(this::initOnBackground); } private void initOnBackground() { // 例如预创建数据库、预加载配置、上报启动日志等 } }需要区分“必须同步”和“可以异步”崩溃捕获必须尽早注册放在第一行防止早期异常丢失。数据库如果首屏强依赖可以等真正使用时再打开不用提前初始化。推送 SDK、统计 SDK、广告 SDK一般都可以异步初始化。但要注意异步初始化不能和首屏逻辑产生竞态。如果某个 SDK 必须在某个页面使用前完成初始化就需要在页面访问时做懒加载等待而不是简单丢到后台线程。4.5.3 首屏布局瘦身启动时建议对首屏 Activity 做布局精简。能用ConstraintLayout减少层级就减少层级首屏不展示的 View 不要一次性全部 inflate使用ViewStub延迟加载。例如首页底部的弹窗、广告位、用户协议面板都不需要出现在首帧布局中。4.6 运行压测与验证上面这些代码都接好后怎么验证效果推荐使用 adb 命令配合真机做两轮对比优化前跑一轮优化后跑一轮。4.6.1 冷启动时间adb shell am start -W -n com.example.antipressure/.MainActivity输出关键信息TotalTime整体启动耗时。WaitTime包含系统启动 Activity 的时间。重复执行几次取平均值对比优化前后的差异。4.6.2 内存占用adb shell dumpsys meminfo com.example.antipressure重点看TOTAL和Native Heap、Java Heap三个指标。如果优化后整体内存下降说明 Bitmap 采样和对象复用起了作用。4.6.3 卡顿和掉帧adb shell dumpsys gfxinfo com.example.antipressure该命令会输出渲染统计信息包括每帧绘制耗时、janky 帧数等。不同 Android 版本输出格式有差异重点看Janky frames这一项数值越高说明掉帧越严重。4.6.4 Monkey 压力测试adb shell monkey -p com.example.antipressure 2000Monkey 会随机发送触摸、点击、滑动事件。跑完后查看崩溃日志目录里是否有新增的 crash 文件同时观察设备是否有 ANR 弹窗。注意Monkey 属于破坏性测试请使用测试机型或测试环境避免对用户的真实数据造成影响。压测前最好备份数据并且关闭开发者选项中的“不保留活动”等设置保证测试结果可对比。5. 常见问题与排查思路实际操作中大家容易遇到下面这些问题。问题现象常见原因解决思路应用内存不断上涨最终 OOM存在内存泄漏或缓存无上限用 LeakCanary 定位泄漏点检查 LruCache 大小限制内存缓存滑动列表掉帧主线程做耗时操作或图片加载未复用检查主线程日志把耗时操作移到线程池图片统一走加载库主线程被阻塞后出现 ANR主线程执行了网络请求/数据库操作使用 StrictMode 辅助排查强制把耗时操作放到后台线程集成 LeakCanary 后 debug 包启动变慢LeakCanary 本身有性能开销只保留在 debugImplementationrelease 包不引入CrashHandler 没有生效初始化太晚或有多处设置默认 Handler在 Application 第一行注册不要覆盖其他框架的 Handler异步初始化导致页面数据为空初始化与业务使用存在竞态对强依赖初始化做懒加载等待或启动守卫另外还有两个高频问题需要单独说明。问题一为什么全局捕获了崩溃应用还是闪退了因为Thread.setDefaultUncaughtExceptionHandler只能捕获 Java 层未处理异常对于 native 层崩溃、系统杀进程、OOM 导致的 abortJava 层 Handler 不一定能收到。这是正常的。对于 native 崩溃需要接入 breakpad 等工具做符号化分析。问题二LeakCanary 检测不到泄漏怎么办可以先确认是否真的发生泄漏方法是进入页面退出页面重复 3-5 次然后观察 LeakCanary 通知。如果一直没有通知可能是检测因混淆或依赖冲突被禁用。检查 debug 包日志中是否有 LeakCanary 初始化失败的异常。排查时可以按这个顺序来确认崩溃或卡顿能不能稳定复现。看 Logcat 中的关键异常堆栈定位到具体类和方法。检查是否在主线程执行了耗时操作。检查图片相关代码是否有采样和缓存。检查是否有静态变量持有 Activity 或 Context。修复后重复压测确认问题不再出现。6. 最佳实践与工程建议优化做一次不难难的是在后续迭代中保持稳定。下面这些工程经验是我在实际项目里比较推荐的做法。6.1 建立内存和启动基线每次版本发布前在固定机型上跑一遍启动时间、内存占用、Monkey 测试记录数据。发布后如果某个指标突然恶化就可以快速定位是哪个版本引入的。测试机型建议选择中低端机因为高端机的性能余量会掩盖很多问题。优化以低端机为基准高端机体验自然会更好。6.2 把监控工具做成可配置像 BlockDetector 这样的工具不要写死在 Application 里。可以通过开关控制只在 debug 包或灰度包开启if (BuildConfig.DEBUG) { new BlockDetector().start(blockTime - Log.w(BlockMonitor, block blockTime ms) ); }生产环境如果要长期监控可以接入独立的 APM 框架而不是自己造轮子。6.3 崩溃日志的保存策略崩溃日志文件要控制数量和大小。建议每个版本只保留最近 10 个崩溃日志单文件超过 512KB 时做截断。日志太多也会占满存储空间导致另一类性能问题。上传日志时要做去重和采样避免同一类崩溃重复上报浪费服务器资源也干扰排查。6.4 灰度发布和回归测试稳定性优化最怕“改一处坏一片”。每次改动都要经过小范围灰度验证确认没有新增崩溃和卡顿后才全量发布。灰度阶段重点观察崩溃率是否上升。ANR 率是否上升。启动耗时是否变长。核心页面是否出现白屏或跳帧。6.5 不要过度优化优化的目的是保障用户体验不是追求极致的指标。比如把 5ms 的耗时优化到 1ms用户感知不出来却增加了代码复杂度这种优化意义不大。优先解决影响面大的问题闪退 ANR 卡顿 启动慢。一个稳定的应用胜过功能丰富但频繁崩溃的应用。6.6 权限和数据采集边界日志、崩溃信息、性能数据都属于用户数据。采集前要注意只在用户同意隐私政策后开始采集。采集内容最小化能不要的字段就不要。数据上传使用加密通道。需要删除相关数据时提供可执行的删除入口。这一点不仅是合规要求也是用户信任的基础。7. 总结与下一步学习路线这篇文章围绕“让手机扛住压力”这个场景完整梳理了 Android 应用稳定性与性能优化的四个核心方向内存控制、卡顿监控、崩溃兜底、启动提速。对应的代码和配置都是可以直接复制到项目里验证的。关键收获可以归纳为三条内存问题的核心是“少分配、及时释放、可复用”。Bitmap 采样是最直接的优化手段。卡顿问题大多数源于主线程耗时操作解决思路是“检测 异步化”先用 BlockDetector 发现再用线程池迁移。崩溃问题要分两层处理用 CrashHandler 保留现场用 LeakCanary 和压测工具从源头减少崩溃。如果继续深入建议按下面的路线学习掌握 Android Profiler、Perfetto、Systrace 的使用学会从系统级 trace 定位卡顿来源。学习 ART 垃圾回收机制理解内存分配和回收对性能的影响。研究 Jetpack App Startup用它统一管理异步初始化任务。尝试接入 Firebase Crashlytics 或自建 APM把崩溃监控从“被动等用户反馈”升级为“主动监控告警”。优化是一套持续跟进的事最好的验证方式就是找一台内存吃紧的中低端真机装上你的 App打开开发者选项里的“不保留活动”再把后台应用驻留拉满最后跑一轮 Monkey。如果这种情况下应用还能稳定存活那才算真正做到了“今天这手机我扛了”。 Android性能与稳定性优化实战：内存、卡顿、崩溃与启动提速
前阵子做灰度回归测试同学拿着一台中端 Android 手机跑了一轮压测脚本结束后第一个冲我喊了一句“今天这手机我扛了。”听起来像在夸手机实际上是在验证 App——“扛住”的意思是在内存紧张、主线程频繁 GC、后台任务并发挤压的情况下应用没有闪退也没有肉眼可见的卡顿。这其实不是运气而是稳定性工程堆出来的结果。本文就把“如何让手机和 App 扛住压力”这件事拆开整理成一套可落地的 Android 性能与稳定性优化方案。内容覆盖四个核心方向内存优化、卡顿监控、全局崩溃兜底、启动提速。每个方向都会给出可复制的代码和配置并解释为什么要这样做。适合以下读者正在做中低端机型适配的 Android 开发者。负责应用稳定性、崩溃率治理的开发者。想系统了解内存、ANR、闪退、启动优化但还没完整实践过的同学。准备做压测、Monkey 测试、性能回归的测试开发。读完你能掌握一套完整的优化思路也能直接拿代码到自己的项目里做局部验证。1. 手机“扛住”压力到底考验的是什么很多人看到“手机扛住了”会觉得是手机硬件性能好但对移动端开发来说这句话考验的其实是应用工程能力。手机硬件是固定的系统资源是有限的真正决定“扛不扛得住”的是 App 如何分配和使用这些资源。一个 Android 应用运行在手机上主要消耗四类资源内存对象实例、Bitmap、缓存、Activity 界面都会占用内存内存超过系统阈值就会触发 OOM。CPU主线程的任务执行、布局测量、绘制、垃圾回收都会消耗 CPU一旦主线程长时间被占用就会卡顿甚至 ANR。存储 IO读取数据库、加载文件、写日志等操作如果放在主线程同样会阻塞界面。网络与系统调度网络请求超时、后台任务被系统杀死、进程被回收也会影响整体体验。所谓“扛住”就是在这些资源都比较紧张时App 依然能保持基本可用内存不会突然飙升到 OOM。主线程不会长时间卡死。出现异常时不会直接闪退或者至少能记录崩溃现场。冷启动速度在可接受范围内。进一步说Android 碎片化严重中低端机型的内存只有 4GB 甚至更少系统后台还驻留着微信、各类工具应用。你的 App 拿到的可用内存可能只有几百 MB这种情况下还能流畅运行才是真正的稳定。所以从工程角度讲优化目标不是跑分而是在低配置、高负载、多任务竞争环境下应用仍然可维护、可运行、可排查问题。2. 环境准备与示例项目说明本教程以 Android 原生项目为例涉及的开发环境如下。版本不需要完全一致重点看配置思路。环境项说明操作系统Windows / macOS / Linux 均可IDEAndroid Studio建议使用稳定版本JDKJDK 17 或项目实际使用的版本Android SDKcompileSdk 建议 34 或以上具体看本地环境构建工具Gradle版本跟随 Android Gradle Plugin 要求测试机型一台中低端 Android 真机建议开启开发者选项和 USB 调试压测工具adb、Monkey、Android Studio Profiler如果没有现成项目可以新建一个空项目来验证。示例项目结构如下antipressure/ ├── app/ │ ├── build.gradle │ └── src/main/ │ ├── AndroidManifest.xml │ └── java/com/example/antipressure/ │ ├── App.java │ ├── MainActivity.java │ ├── crash/ │ │ └── CrashHandler.java │ └── util/ │ ├── AppExecutors.java │ ├── BitmapSampler.java │ └── BlockDetector.java └── build.gradle包名统一使用com.example.antipressure生产项目中请替换成自己的包名。3. 手机扛不住时的四种典型表现在动手优化之前先要知道“扛不住”具体有哪些表现。每一种表现背后对应的是不同层次的系统资源问题排查手段也不一样。3.1 内存溢出OOM和内存抖动最常见的是内存溢出也就是 App 占用的内存超过了系统给进程分配的上限JVM 或 ART 虚拟机直接抛出OutOfMemoryError。表现通常是图片列表滑动到某个位置突然崩溃。加载大图时页面闪退。Logcat 中看到OutOfMemoryError或Failed to allocate memory。还有一种隐蔽情况是内存抖动短时间内大量创建和销毁对象导致频繁内存分配和 GC。GC 会占用 CPU 时间造成界面掉帧用户感觉就是“滑动不跟手”。3.2 卡顿、掉帧与 ANR手机屏幕每 16ms 刷新一帧如果应用主线程在 16ms 内完不成 measure、layout、draw就会出现掉帧。掉帧多了用户就会感觉页面“有点卡”。如果主线程被某个耗时操作阻塞超过 5 秒不同 Android 版本阈值略有差异系统会弹出 ANR 对话框也就是“应用无响应”。常见原因有主线程做了网络请求或大文件读写。布局层级过深测量耗时。主线程持续处理大量计算。被其他进程的 IO 抢占导致执行变慢。3.3 崩溃闪退未捕获的 RuntimeException、空指针、数组越界、Json 解析失败等一旦出现在主线程且没有兜底处理应用就会直接闪退。闪退的危害不只是体验差更严重的是崩溃现场难定位。没有日志、没有堆栈只能靠用户描述开发效率会非常低。3.4 冷启动慢用户从桌面点击图标到看到第一帧内容这个过程就是冷启动。如果 Application 的onCreate里做了大量初始化比如数据库、图片加载库、网络 SDK、各种业务组件的初始化全部堆在主线程启动时间会被明显拉长。在低端机上这个差距会放大用户可能连续点击图标两次导致重复启动。4. 实战从零搭建一个抗压版 Android 项目下面我们进入实战环节。目标不是做一套完整的大型框架而是把四个核心方向的最小可用代码落地让你能直接复制到项目里验证效果。4.1 项目结构与依赖配置先看app/build.gradle的核心配置plugins { id com.android.application } android { namespace com.example.antipressure compileSdk 34 defaultConfig { applicationId com.example.antipressure minSdk 23 targetSdk 34 versionCode 1 versionName 1.0 } compileOptions { sourceCompatibility JavaVersion.VERSION_17 targetCompatibility JavaVersion.VERSION_17 } buildTypes { release { minifyEnabled true shrinkResources true proguardFiles getDefaultProguardFile(proguard-android-optimize.txt), proguard-rules.pro } } } dependencies { implementation androidx.appcompat:appcompat:1.6.1 implementation com.google.android.material:material:1.11.0 // LeakCanary 只参与 debug 包release 包不建议集成 debugImplementation com.squareup.leakcanary:leakcanary-android:2.12 }两点说明compileSdk 34、targetSdk 34不是固定要求请根据你本地的 SDK 环境调整。如果项目已经有版本体系不要强行升级。LeakCanary 建议只用debugImplementation引入只参与调试包构建不影响线上安装包体积和性能。接下来是AndroidManifest.xmlapplication android:name.App android:allowBackuptrue android:iconmipmap/ic_launcher android:labelstring/app_name android:themestyle/Theme.AppCompat.DayNight.NoActionBar activity android:name.MainActivity android:exportedtrue intent-filter action android:nameandroid.intent.action.MAIN / category android:nameandroid.intent.category.LAUNCHER / /intent-filter /activity /application这里把 Application 类指定为.App后续的启动优化和崩溃处理器都会在 App 类里统一接入。4.2 第一关内存压力控制内存优化不是一句“少 new 对象”就能覆盖的实际工程里最容易出问题的是Bitmap 加载、列表缓存、页面级数据缓存三块。4.2.1 Bitmap 采样加载很多 OOM 都发生在图片加载。一张 4000×3000 的图片按 ARGB_8888 计算每个像素占 4 字节直接解码进内存会占用约 48MB。如果在列表中同时滑出多张图内存直接顶不住。正确做法是按需采样。下面是最基础的采样加载工具package com.example.antipressure.util; import android.graphics.Bitmap; import android.graphics.BitmapFactory; public class BitmapSampler { public static Bitmap decodeSampledBitmap(String path, int reqWidth, int reqHeight) { // 第一次只读取宽高不真正解码像素内存占用极低 BitmapFactory.Options options new BitmapFactory.Options(); options.inJustDecodeBounds true; BitmapFactory.decodeFile(path, options); int inSampleSize calculateInSampleSize(options, reqWidth, reqHeight); // 第二次按采样比例正式解码 options.inJustDecodeBounds false; options.inSampleSize inSampleSize; return BitmapFactory.decodeFile(path, options); } private static int calculateInSampleSize(BitmapFactory.Options options, int reqWidth, int reqHeight) { int width options.outWidth; int height options.outHeight; if (reqWidth 0 || reqHeight 0) { return 1; } int inSampleSize 1; // 约束条件采样后的宽高都要小于目标值 while ((width / inSampleSize) reqWidth || (height / inSampleSize) reqHeight) { inSampleSize * 2; } return inSampleSize; } }关键点inJustDecodeBounds true时decodeFile只解析图片头信息不会分配像素内存。inSampleSize必须是 2 的幂系统会对它做向下取整处理。实际项目中更推荐使用 Glide、Coil 等图片加载库内部已经做了采样和缓存可以极大降低手动处理成本。4.2.2 避免内存抖动内存抖动常见于循环内创建对象、字符串拼接、频繁创建监听器。例如for (int i 0; i list.size(); i) { String text item.getTitle() - i; // 这里每次都创建新字符串 holder.textView.setText(text); }如果列表不断刷新这里会创建大量临时字符串触发频繁 GC。优化思路是尽量复用对象。尤其是RecyclerView的onBindViewHolder中不要每次创建新的监听器可以把监听器缓存在 ViewHolder 里。4.2.3 用 LeakCanary 定位内存泄漏内存泄漏不像崩溃那样能立刻看到但它会悄悄蚕食应用内存。LeakCanary是业内常用的内存泄漏检测工具在 debug 包中集成后它会自动监听 Activity 和 Fragment 的销毁发现疑似泄漏时通知你查看堆栈。使用方式非常简单依赖已经加过了只要 debugImplementation 引入LeakCanary 会通过 ContentProvider 自动初始化不需要手动调用初始化方法。当你 debug 运行时发生泄漏通知栏会出现一条“LeakCanary 检测到内存泄漏”的通知里面会显示完整的引用链。需要注意的是LeakCanary 只用于开发调试不能用于线上监控。它的存在本身会占用一定内存和 CPU。4.3 第二关渲染与卡顿监控4.3.1 主线程的职责边界主线程只做一件事处理 UI 事件和绘制。任何耗时操作都不应该出现在主线程上包括网络请求、JSON 解析、数据库查询、Bitmap 解码、文件写入。实际项目中数据库查询是最容易踩坑的点。一条慢 SQL 可能耗时 200ms如果你在 Activity 的onCreate里查一次列表再在onResume里查一次启动过程就多了 400ms用户感知非常明显。4.3.2 用 Looper 监听主线程耗时消息Android 主线程本质是消息循环所有 UI 任务都被封装成 Message 消息。系统提供了Looper.getMainLooper().setMessageLogging()可以打印每条消息的分发和完成时间。我们可以利用这个机制做卡顿监控package com.example.antipressure.util; import android.os.Looper; import android.util.Log; import android.util.Printer; public class BlockDetector { public interface OnBlockListener { void onBlock(long blockTime); } private static final String TAG BlockDetector; private static final long BLOCK_THRESHOLD_MS 300L; private long startTime 0L; private boolean inMessage false; public void start(OnBlockListener listener) { Looper.getMainLooper().setMessageLogging(new Printer() { Override public void println(String log) { if (log null) { return; } // 消息开始分发打印的日志包含标记串 if (log.contains( Dispatching)) { startTime System.currentTimeMillis(); inMessage true; } else if (log.contains( Finished)) { if (inMessage) { long cost System.currentTimeMillis() - startTime; if (cost BLOCK_THRESHOLD_MS) { Log.w(TAG, main thread block: cost ms); if (listener ! null) { listener.onBlock(cost); } } inMessage false; } } } }); } }这个工具的用途是在开发和测试阶段一旦主线程单条消息执行超过 300ms就输出警告。你可以把阈值调低到 100ms 来更早发现卡顿隐患。注意setMessageLogging是全局设置如果项目里其他地方也在设置日志 Printer会互相覆盖。生产环境不建议长期开启适合在压测和调优阶段使用。4.3.3 用线程池替代裸 new Thread很多开发者习惯直接 new Thread但每次创建线程的代价很大而且并发线程数量不受控制。推荐使用统一线程池package com.example.antipressure.util; import java.util.concurrent.ExecutorService; import java.util.concurrent.LinkedBlockingQueue; import java.util.concurrent.ThreadFactory; import java.util.concurrent.ThreadPoolExecutor; import java.util.concurrent.TimeUnit; public final class AppExecutors { private static final int CPU_COUNT Runtime.getRuntime().availableProcessors(); private static final int CORE_POOL_SIZE Math.max(2, Math.min(CPU_COUNT - 1, 4)); private static final int MAX_POOL_SIZE Math.max(CORE_POOL_SIZE * 2, 8); private static final int KEEP_ALIVE_SECONDS 30; private static final ExecutorService IO_EXECUTOR new ThreadPoolExecutor( CORE_POOL_SIZE, MAX_POOL_SIZE, KEEP_ALIVE_SECONDS, TimeUnit.SECONDS, new LinkedBlockingQueue(128), new BaseThreadFactory(app-io), new ThreadPoolExecutor.DiscardPolicy() ); private AppExecutors() { } public static ExecutorService io() { return IO_EXECUTOR; } private static class BaseThreadFactory implements ThreadFactory { private final String prefix; private int sequence 0; BaseThreadFactory(String prefix) { this.prefix prefix; } Override public Thread newThread(Runnable r) { Thread thread new Thread(r, prefix - sequence); thread.setPriority(Thread.NORM_PRIORITY); return thread; } } }这个线程池的核心逻辑corePoolSize根据 CPU 核心数计算避免线程过多。队列容量限制为 128超过部分执行DiscardPolicy即丢弃任务并静默返回。这样做的目的是“丢任务不丢进程”相比AbortPolicy抛异常更适合非核心业务。线程池统一命名后续定位问题时可以在Thread名称中直接看出是哪个池子里的线程。调用方式很简单AppExecutors.io().execute(() - { // 在后台线程执行耗时任务 String result queryDatabase(); runOnUiThread(() - uiView.setText(result)); });4.4 第三关全局崩溃兜底4.4.1 为什么要做全局崩溃捕获即使代码写得再小心线上环境依然可能出现空指针、解析异常、资源找不到等问题。全局崩溃捕获的意义不是“不让 App 退出”而是在崩溃发生前保存现场给开发者留下可分析的日志。没有现场日志线上崩溃基本只能靠猜。需要说明的是不建议通过try-catch吞掉所有异常来阻止闪退。崩溃发生后线程栈可能已经处于不稳定状态强行继续运行容易出现二次崩溃而且会掩盖真实问题。更稳妥的方案是记录崩溃信息然后按系统默认流程退出或谨慎地重启一次。4.4.2 自定义 CrashHandler 实现下面是一个完整的全局崩溃处理器package com.example.antipressure.crash; import android.content.Context; import android.os.Process; import android.util.Log; import java.io.File; import java.io.FileWriter; import java.io.IOException; import java.io.PrintWriter; import java.io.StringWriter; import java.io.Writer; import java.text.SimpleDateFormat; import java.util.Date; import java.util.Locale; public class CrashHandler implements Thread.UncaughtExceptionHandler { private static final String TAG CrashHandler; private static final String FILE_NAME_PREFIX crash_; private final Thread.UncaughtExceptionHandler defaultHandler; private final Context appContext; public CrashHandler(Context context) { this.appContext context.getApplicationContext(); // 保留系统默认处理器避免破坏系统流程 this.defaultHandler Thread.getDefaultUncaughtExceptionHandler(); } public void register() { Thread.setDefaultUncaughtExceptionHandler(this); } Override public void uncaughtException(Thread thread, Throwable throwable) { // 1. 记录崩溃现场 String crashInfo buildCrashInfo(thread, throwable); saveCrashLog(crashInfo); // 2. 先让系统默认处理器处理最终会正常结束进程 if (defaultHandler ! null) { defaultHandler.uncaughtException(thread, throwable); } else { Process.killProcess(Process.myPid()); System.exit(1); } } private String buildCrashInfo(Thread thread, Throwable throwable) { StringWriter sw new StringWriter(); PrintWriter pw new PrintWriter(sw); pw.println(Thread: thread.getName() ( thread.getId() )); pw.println(Time: new SimpleDateFormat(yyyy-MM-dd HH:mm:ss, Locale.getDefault()).format(new Date())); pw.println(Process: Process.myPid()); throwable.printStackTrace(pw); pw.close(); return sw.toString(); } private void saveCrashLog(String content) { File dir new File(appContext.getExternalFilesDir(null), crash_logs); if (!dir.exists() !dir.mkdirs()) { Log.e(TAG, create crash log dir failed); return; } String fileName FILE_NAME_PREFIX System.currentTimeMillis() .txt; File file new File(dir, fileName); try (Writer writer new FileWriter(file)) { writer.write(content); } catch (IOException e) { Log.e(TAG, write crash log failed, e); } } }这段代码做了三件事获取系统默认的UncaughtExceptionHandler保存引用。在自定义处理器中把线程名、时间、进程号、完整堆栈写入本地文件。然后交回默认处理器保证进程按系统逻辑退出。日志写到getExternalFilesDir(null)目录下这是应用专属外部存储不需要额外申请权限卸载时也会自动清理适合保存日志但不适合长期敏感数据。在App类里注册package com.example.antipressure; import android.app.Application; import com.example.antipressure.crash.CrashHandler; public class App extends Application { Override public void onCreate() { super.onCreate(); new CrashHandler(this).register(); } }如果要实现“崩溃后自动重启一次”可以在此基础上增加一个崩溃次数标记。核心思路是把defaultHandler.uncaughtException替换成自己的重启逻辑但必须加上防循环保护——如果 App 启动后 5 秒内再次崩溃说明启动路径有问题此时应该直接退出避免反复重启。4.4.3 线上采集的合规提醒崩溃日志里通常会包含设备型号、系统版本、应用版本、堆栈信息这些属于用户设备信息。如果要把日志上传到自己的服务器必须遵循最小必要原则并确保用户知情同意。建议只采集崩溃堆栈和基本设备信息不要采样用户的账号、手机号、定位等隐私字段。4.5 第四关启动速度优化4.5.1 冷启动流程分析冷启动的耗时点主要在三处Application 的onCreate。首屏 Activity 的onCreate、onStart、onResume。首帧绘制完成之前的布局初始化。很多团队会把所有 SDK 初始化都堆在 Application 里public class App extends Application { Override public void onCreate() { super.onCreate(); initCrash(); initHttp(); initDatabase(); initPush(); initImageLoader(); initTracker(); initReactNative(); } }这样的结果是用户点击图标后要等这些初始化全部跑完才进入主页面启动时间很容易超过 2 秒甚至更长。4.5.2 异步初始化示例优化的核心思路是只把最必要的初始化放在主线程其余全部放到后台线程。package com.example.antipressure; import android.app.Application; import com.example.antipressure.crash.CrashHandler; import com.example.antipressure.util.AppExecutors; public class App extends Application { Override public void onCreate() { super.onCreate(); new CrashHandler(this).register(); // 非关键路径放到后台线程执行 AppExecutors.io().execute(this::initOnBackground); } private void initOnBackground() { // 例如预创建数据库、预加载配置、上报启动日志等 } }需要区分“必须同步”和“可以异步”崩溃捕获必须尽早注册放在第一行防止早期异常丢失。数据库如果首屏强依赖可以等真正使用时再打开不用提前初始化。推送 SDK、统计 SDK、广告 SDK一般都可以异步初始化。但要注意异步初始化不能和首屏逻辑产生竞态。如果某个 SDK 必须在某个页面使用前完成初始化就需要在页面访问时做懒加载等待而不是简单丢到后台线程。4.5.3 首屏布局瘦身启动时建议对首屏 Activity 做布局精简。能用ConstraintLayout减少层级就减少层级首屏不展示的 View 不要一次性全部 inflate使用ViewStub延迟加载。例如首页底部的弹窗、广告位、用户协议面板都不需要出现在首帧布局中。4.6 运行压测与验证上面这些代码都接好后怎么验证效果推荐使用 adb 命令配合真机做两轮对比优化前跑一轮优化后跑一轮。4.6.1 冷启动时间adb shell am start -W -n com.example.antipressure/.MainActivity输出关键信息TotalTime整体启动耗时。WaitTime包含系统启动 Activity 的时间。重复执行几次取平均值对比优化前后的差异。4.6.2 内存占用adb shell dumpsys meminfo com.example.antipressure重点看TOTAL和Native Heap、Java Heap三个指标。如果优化后整体内存下降说明 Bitmap 采样和对象复用起了作用。4.6.3 卡顿和掉帧adb shell dumpsys gfxinfo com.example.antipressure该命令会输出渲染统计信息包括每帧绘制耗时、janky 帧数等。不同 Android 版本输出格式有差异重点看Janky frames这一项数值越高说明掉帧越严重。4.6.4 Monkey 压力测试adb shell monkey -p com.example.antipressure 2000Monkey 会随机发送触摸、点击、滑动事件。跑完后查看崩溃日志目录里是否有新增的 crash 文件同时观察设备是否有 ANR 弹窗。注意Monkey 属于破坏性测试请使用测试机型或测试环境避免对用户的真实数据造成影响。压测前最好备份数据并且关闭开发者选项中的“不保留活动”等设置保证测试结果可对比。5. 常见问题与排查思路实际操作中大家容易遇到下面这些问题。问题现象常见原因解决思路应用内存不断上涨最终 OOM存在内存泄漏或缓存无上限用 LeakCanary 定位泄漏点检查 LruCache 大小限制内存缓存滑动列表掉帧主线程做耗时操作或图片加载未复用检查主线程日志把耗时操作移到线程池图片统一走加载库主线程被阻塞后出现 ANR主线程执行了网络请求/数据库操作使用 StrictMode 辅助排查强制把耗时操作放到后台线程集成 LeakCanary 后 debug 包启动变慢LeakCanary 本身有性能开销只保留在 debugImplementationrelease 包不引入CrashHandler 没有生效初始化太晚或有多处设置默认 Handler在 Application 第一行注册不要覆盖其他框架的 Handler异步初始化导致页面数据为空初始化与业务使用存在竞态对强依赖初始化做懒加载等待或启动守卫另外还有两个高频问题需要单独说明。问题一为什么全局捕获了崩溃应用还是闪退了因为Thread.setDefaultUncaughtExceptionHandler只能捕获 Java 层未处理异常对于 native 层崩溃、系统杀进程、OOM 导致的 abortJava 层 Handler 不一定能收到。这是正常的。对于 native 崩溃需要接入 breakpad 等工具做符号化分析。问题二LeakCanary 检测不到泄漏怎么办可以先确认是否真的发生泄漏方法是进入页面退出页面重复 3-5 次然后观察 LeakCanary 通知。如果一直没有通知可能是检测因混淆或依赖冲突被禁用。检查 debug 包日志中是否有 LeakCanary 初始化失败的异常。排查时可以按这个顺序来确认崩溃或卡顿能不能稳定复现。看 Logcat 中的关键异常堆栈定位到具体类和方法。检查是否在主线程执行了耗时操作。检查图片相关代码是否有采样和缓存。检查是否有静态变量持有 Activity 或 Context。修复后重复压测确认问题不再出现。6. 最佳实践与工程建议优化做一次不难难的是在后续迭代中保持稳定。下面这些工程经验是我在实际项目里比较推荐的做法。6.1 建立内存和启动基线每次版本发布前在固定机型上跑一遍启动时间、内存占用、Monkey 测试记录数据。发布后如果某个指标突然恶化就可以快速定位是哪个版本引入的。测试机型建议选择中低端机因为高端机的性能余量会掩盖很多问题。优化以低端机为基准高端机体验自然会更好。6.2 把监控工具做成可配置像 BlockDetector 这样的工具不要写死在 Application 里。可以通过开关控制只在 debug 包或灰度包开启if (BuildConfig.DEBUG) { new BlockDetector().start(blockTime - Log.w(BlockMonitor, block blockTime ms) ); }生产环境如果要长期监控可以接入独立的 APM 框架而不是自己造轮子。6.3 崩溃日志的保存策略崩溃日志文件要控制数量和大小。建议每个版本只保留最近 10 个崩溃日志单文件超过 512KB 时做截断。日志太多也会占满存储空间导致另一类性能问题。上传日志时要做去重和采样避免同一类崩溃重复上报浪费服务器资源也干扰排查。6.4 灰度发布和回归测试稳定性优化最怕“改一处坏一片”。每次改动都要经过小范围灰度验证确认没有新增崩溃和卡顿后才全量发布。灰度阶段重点观察崩溃率是否上升。ANR 率是否上升。启动耗时是否变长。核心页面是否出现白屏或跳帧。6.5 不要过度优化优化的目的是保障用户体验不是追求极致的指标。比如把 5ms 的耗时优化到 1ms用户感知不出来却增加了代码复杂度这种优化意义不大。优先解决影响面大的问题闪退 ANR 卡顿 启动慢。一个稳定的应用胜过功能丰富但频繁崩溃的应用。6.6 权限和数据采集边界日志、崩溃信息、性能数据都属于用户数据。采集前要注意只在用户同意隐私政策后开始采集。采集内容最小化能不要的字段就不要。数据上传使用加密通道。需要删除相关数据时提供可执行的删除入口。这一点不仅是合规要求也是用户信任的基础。7. 总结与下一步学习路线这篇文章围绕“让手机扛住压力”这个场景完整梳理了 Android 应用稳定性与性能优化的四个核心方向内存控制、卡顿监控、崩溃兜底、启动提速。对应的代码和配置都是可以直接复制到项目里验证的。关键收获可以归纳为三条内存问题的核心是“少分配、及时释放、可复用”。Bitmap 采样是最直接的优化手段。卡顿问题大多数源于主线程耗时操作解决思路是“检测 异步化”先用 BlockDetector 发现再用线程池迁移。崩溃问题要分两层处理用 CrashHandler 保留现场用 LeakCanary 和压测工具从源头减少崩溃。如果继续深入建议按下面的路线学习掌握 Android Profiler、Perfetto、Systrace 的使用学会从系统级 trace 定位卡顿来源。学习 ART 垃圾回收机制理解内存分配和回收对性能的影响。研究 Jetpack App Startup用它统一管理异步初始化任务。尝试接入 Firebase Crashlytics 或自建 APM把崩溃监控从“被动等用户反馈”升级为“主动监控告警”。优化是一套持续跟进的事最好的验证方式就是找一台内存吃紧的中低端真机装上你的 App打开开发者选项里的“不保留活动”再把后台应用驻留拉满最后跑一轮 Monkey。如果这种情况下应用还能稳定存活那才算真正做到了“今天这手机我扛了”。