简介：面向 Android 应用与系统开发者的性能优化文档，聚焦 PAD 与车机场景下的启动、响应、内存、稳定性、数据传输、流量、存储及模块功耗问题，适合具备一定系统开发基础、需要排查卡顿与资源消耗的工程师参考。压缩包内含 1 个 docx 文件，大小约 10.32MB，内容以优化思路、测试项、检查清单与 adb 调试命令整理为主，便于按模块查阅和对照实践。已有 687 人学习下载。文档围绕开机速度、应用响应、内存管理、系统稳定性等八个方向展开，包含桌面、电话、相机等 14 类集成应用的响应时间测试与冷热启动差异分析，也涉及内存泄露、ANR、Crash、Monkey/CTS 测试、WIFI/蓝牙传输、流量控制、存储清理和模块功耗等检查点；同时汇总常用 adb 与 adb shell 命令，可作为性能调试、问题定位和优化方案梳理的参考。

1. 车机与 PAD 的性能优化：从开机到功耗的八条主线

车机项目最容易被误判的一点是功耗：设备烧油不靠电池，很多人第一反应是把功耗优化整章砍掉。我见过一个团队真这么干了，结果音视频编解码和背光模块的温升把主板烤到降频，开机时间和响应速度反而一起恶化。所以这套 Android 性能优化方案把功耗保留为第八条主线，只是调整了权重。方案面向的是做 PAD 与车机整机交付的工程师，以及要交一份完整性能优化课程设计或毕设的同学：以开机速度、响应速度、内存管理、系统稳定性、数据传输、数据流量、存储容量、模块功耗八块为骨架，用 adb 工具链做测量，用可复现的步骤做验证，而不是凭感觉调参数。

1.1 先划清边界：PAD 与车机的优化权重怎么分

两个产品的硬件形态决定了优化清单不能照抄。PAD 的 BSP 是内嵌打包式 Bin，模块功耗基本无解，能做的只是横向对比不同 BSP 版本的功耗是否达标，属于「验证」而非「改造」；车机虽然不缺电，但对启动速度和长时间运行的稳定性要求远高于消费电子，冷启动多一秒就是可感知的体验倒退。所以通常的做法是：PAD 侧重内存、存储容量与响应速度，车机侧重开机速度、系统稳定性与长时间功耗表现。

这张表是后面所有章节的分配依据。权重低不等于不做，而是出问题时优先怀疑权重高的那几块。

1.2 测量先于优化：把 adb 工具链当成唯一的尺子

性能优化最怕的就是「改完感觉快了」。这个项目里所有结论都必须落到数字上，工具就是 adb。刷机后第一件事是确认设备在线、分区可写、能拿到 root：adb devices看序列号，adb root提权，adb remount把 system 分区挂成可写，这三步不通，后面的裁剪和替换全是空谈。开机时间的采集用adb shell logcat -v time抓 boot 阶段时间戳，配合adb shell dmesg看内核侧耗时，两个时间轴对齐才能定位是 kernel 慢还是 Android 服务慢。响应速度用高速摄像机拍冷启动和热启动两轮，代码侧再用am start -W打点交叉验证。内存和进程用procrank、dumpsys meminfo、top三个命令互相印证，单看一个必然翻车。

2. 开机速度优化：从 kernel 到首次启动的四层裁剪

2.1 四层裁剪的先后顺序

开机慢的原因绝大多数不是某一处特别慢，而是每一处都慢一点点。理顺顺序很关键：先 kernel，再 init，然后 Android 服务，最后是应用层预加载。顺序反了会出现「服务删了但驱动还在等」的假优化。

第一层是日志。kernel、init 进程、Android 服务启动过程中的日志输出会带来大量 IO 与串口写操作，量产版本应把 loglevel 降下来，串口控制台在正式版关闭。第二层是驱动模块，kernel 里编译进去但硬件上根本不存在的驱动要摘掉，这一步收益往往最大，因为驱动 probe 失败还会重试。第三层是 Android 服务，system_server里启动的服务有一堆在车机和 PAD 上用不到，比如某些传感器服务、打印服务。第四层是 preload-class，预加载类越多，Zygote 孵化越慢，开机扫描的类和预装 APK 也要同步削减。

# 采集开机各阶段时间戳，用于四层裁剪前后的对比 adb root adb remount adb shell dmesg -v time > kernel_boot.log # kernel 侧时间轴 adb shell logcat -v time -b all > android_boot.log # Android 侧时间轴 adb shell getprop | grep -E "boot|init" # 查看 boot 相关属性

dmesg -v time输出的是内核环形缓冲区里的带时间戳记录，能看清驱动 probe 的先后与耗时；logcat -b all把 main、system、events、radio 全部缓冲区一起抓，避免漏掉 init 阶段的日志。两次采集必须在同一台机器、同一版本、同样的冷启动条件下做，否则数据没有可比性。

2.2 删服务与删预加载类的具体判断

删服务不能靠猜。通常的做法是先adb shell service list把所有服务列出来，再对照硬件 BOM 逐条确认哪些服务背后没有真实硬件。删 preload-class 更稳妥的方式是做对照实验：先备份/system/framework/下相关配置文件，改一版刷一版，用同一套开机时间采集脚本跑三遍取中间值。少一个类省下的时间可能只有几十毫秒，但 preload 动辄上千个类，累计收益是可观的。

提示：刷机后的首次启动加载时间要单独测量，它包含数据分区初始化，和后续正常启动不是一个量级，混在一起算平均值会把优化效果稀释掉。

2.3 预装 APK 与扫描类削减

PAD 和车机上预装的应用数量直接影响 PackageManager 的扫描时间。做法是列出/system/app与/system/priv-app下所有 APK，按「必须预装 / 可延后安装 / 可删除」三类标注。必须预装的保留，可延后的移到 data 分区首次开机后再装，可删除的直接从镜像里移除。注意删除时同步清理对应的权限配置与共享库引用，否则会留下一堆启动时报错的空引用，反而拖慢开机。

3. 响应速度优化：14 类集成应用的可量化测试

3.1 为什么锁定这 14 个 APK

桌面、电话、联系人、短信、相机、相册、云邮箱、音乐、视频、应用中心、安全精灵、主题中心、设置、文件浏览器，这 14 个集成应用是用户高频触达的入口，且都涉及大数据的导入导出与频繁数据交互，是最容易暴露加载瓶颈的地方。像闹钟、计算器、录音机、便签、日历、浏览器、输入法、天气这类轻应用以及第三方应用和游戏，本身逻辑简单或性能由外部决定，不列入本轮优化范围。

测试必须区分冷启动和热启动。冷启动包含进程创建、类加载、资源初始化；热启动只是把已存在的进程拉到前台。两者混测会得到一个既不代表冷也不代表热的中间数，工程上毫无意义。我一般会要求每个应用至少采 5 组冷启动、5 组热启动，取中位数。

# 用 am start -W 量化单个应用的启动耗时 adb shell am force-stop com.android.settings # 强制停止，制造冷启动条件 adb shell am start -W -n com.android.settings/.Settings # 输出中的 TotalTime 为本次启动总耗时，WaitTime 为命令等待耗时

-W让 am 命令等待应用启动完成并打印 ThisTime、TotalTime、WaitTime 三项。ThisTime 只算最后一个 Activity 的绘制，TotalTime 才是从发起到可交互的完整耗时，工程上以 TotalTime 为准。force-stop是制造冷启动的必要动作，缺了它测出来的全是热启动数据。这套命令跑一轮 14 个应用下来不到十分钟，做成脚本可以每天回归一次。

3.2 锁屏解锁与框架层检查

锁屏和解锁的耗时容易被忽略，但它的构成很具体：播放锁屏与解锁音效、解除和重新加载功耗锁。音效文件如果放在慢速存储上，或者解码链路重，单次就有可观延迟。做法是把音效预加载到内存、缩短功耗锁的持有窗口。另一块是虚拟机与框架本身，因为这套 codebase 建立在自有虚拟机之上，并非原生 Android 代码，必须做完整回归：重点看虚拟机启动参数、JIT 策略、GC 触发频率三处，任何一处配置偏离都会整体拖慢响应。

3.3 主芯片与整机响应能力评估

应用层优化做到头，剩下的瓶颈就在芯片和整机。评估方法是跑基准测试与真实场景双轨：基准看 CPU 单核多核、内存带宽，真实场景看 14 个应用的 TotalTime 分布。如果基准分数正常但应用启动普遍偏慢，问题通常在 IO 或调度策略；如果基准本身就偏低，那就要回到 BSP 层看频率配置与温控策略，别在应用层白费力气。

4. 内存与稳定性：把崩溃、ANR、泄漏压到可控

4.1 内存泄漏与空指针的排查路径

Java 有垃圾回收不等于没有泄漏。对象已经不用了但仍有引用指向它，GC 就回收不了，运行久了内存被吃光就是 OOM。Android 每个应用跑在独立 Dalvik 虚拟机实例里，堆上限一般 16M 到 24M，超限就被系统 kill，影响限于自身进程；但 system_process 出问题会直接导致系统重启，这是稳定性红线。

排查用dumpsys meminfo看 PSS 变化趋势，用procrank按 USS 排序找异常进程，再用showmap定位到具体内存段。VSS、RSS、PSS、USS 四个指标含义不同，工程上判断真实占用看 PSS 和 USS，看共享库影响看 RSS，VSS 基本只做参考。

adb shell dumpsys meminfo com.example.app # 单应用内存明细 adb shell procrank -u # 按独占物理内存降序排列 adb shell showmap -w <pid> # 定位进程内具体内存段 adb shell cat /proc/meminfo # 系统整体内存分布

/proc/meminfo里系统可用空间约等于 MemFree 加 Cached，设置里的「运行中」显示值还要再减掉 SECONDARY_SERVER_MEM，两者对不上是正常的，别当成 bug 去查。

4.2 ANR 与 Crash 的日志闭环

ANR 日志在/data/anr/，Crash 与 tombstone 在/data/tombstones/，内核日志在/proc/kmsg和/proc/last_kmsg。tombstone 里是一串十六进制地址，必须用工具翻译才有意义：arm-eabi-addr2line -e libxxx.so 0x00012345定位到文件与函数，arm-eabi-nm -l -C -n -S列出符号表，arm-eabi-objdump -C -d反汇编看指令上下文。这三件套是 native crash 分析的标准流程，缺一环就只能看着地址干瞪眼。日志采集建议做成批处理脚本一次抓全，避免现场反复让人配合。

4.3 Monkey 与 CTS 作为稳定性闸门

稳定性不能靠人工点。Monkey 用adb shell monkey -v -p 包名 事件数跑随机事件流，跑之前记下起点，跑完统计 ANR 与 Crash 次数，达标线由项目自己定但必须写进验收单。CTS 用来兜底兼容性，尤其是第三方应用兼容性，因为车机和 PAD 的定制改动多，很容易在标准用例上翻车。另外数据区要及时删除、进程要归并，长期运行设备上堆积的僵尸进程和冗余数据本身就是不稳定源。

5. 传输、流量与存储：容易被忽视的三块体验

5.1 数据传输的多链路测量

数据传输要分链路测：WIFI 连接速度与 AP 切换重连速度、蓝牙传输与配对速度、无线移动传输速度、云同步速度、内外置 SD 卡读取速度。每条链路的测试方法都不同，WIFI 重点看重连耗时，蓝牙重点看配对握手，SD 卡重点看小文件随机读。PAD 部分机型不支持电话短信，移动通信流量不涉及，重心落在 WIFI 上；车机则更关注云同步和本地存储读取，因为地图与媒体数据量大。

5.2 数据流量管控与存储容量维护

流量管控的目标不是省流量，而是防偷跑。做法是逐个 APK 检查网络访问权限与实际请求行为，应用退出时网络连接必须释放，发现后台偷跑的要限期整改。存储容量靠定时清理：内置与外置 SD 卡的冗余数据按周期清理，安全小精灵这类工具负责及时释放内存与缓存。清理策略要设白名单，别把用户数据和地图离线包一起清了。

5.3 模块功耗：能改的改，改不了的对比验证

功耗模块集中在音视频编解码、背光、LCD 与触摸屏刷新频率、modem。PAD 因为 BSP 内嵌打包，模块功耗只能做版本间对比，确认新 BSP 是否达标；能在应用层做的是降低刷新频率、缩短背光高亮时长、控制编解码并发数。车机不缺电但怕热，功耗优化的实际收益体现在温升与降频上，这一条在第一章的权重表里已经埋好伏笔。

6. 避坑清单：五个最容易翻车的点

第一，改完不测基线。现象是优化后开机反而慢了；原因是没在改动前采集基线，无法判断波动来自改动还是环境；解决办法是每次改动前先跑三遍采集取中位数，改动后再跑三遍对比。

第二，用热启动数据冒充冷启动。现象是报告里启动时间漂亮得不像话；原因是漏了am force-stop；解决办法是把强制停止写进测试脚本，不给人工操作留空间。

第三，日志抓不全。现象是分析到一半发现缺 radio 缓冲区或缺 last_kmsg；原因是只抓了默认 main 缓冲区；解决办法是logcat -b all加/proc/last_kmsg一起抓，批处理脚本固化。

第四，删服务删出空引用。现象是开机变快但启动后频繁报错甚至重启；原因是删服务时没同步清理依赖配置；解决办法是删一项验一项，每轮改动单独出包回归 Monkey。

第五，功耗只看平均值。现象是平均功耗达标但用户反馈发烫；原因是峰值功耗和持续高负载场景被平均掉了；解决办法是同时记录峰值与温升曲线，把持续高负载场景单独拉出来测。

7. 验收与答辩：用一张回归表把优化讲清楚

性能优化最难的从来不是改，而是证明改对了。我一般会要求每个优化项都配一行验收记录：优化项、基线值、优化后值、测量方法、复现步骤。答辩或交付评审时，评委问「快了没有」，你直接把这张表投出来，比讲十分钟原理管用。

表里的数值一律留空让你自己填，因为不同硬件平台差异太大，抄别人的数字没有意义。答辩时被追问细节，重点讲三件事：测试条件怎么控制（同机同版本同冷启动）、数据怎么取（多轮取中位数）、异常怎么归因（日志闭环）。如果评委问「某个应用为什么还是慢」，正确的回答是拿出它的 TotalTime 分布和 dumpsys 输出，指出瓶颈在 IO 还是类加载，而不是说「已经优化过了」。

有一个习惯我从项目里带出来就再没改过：任何一次性能改动，都必须先跑基线、再改、再跑回归，三份数据缺一份就不算完成。血泪经验是早年一次「顺手」删了几个预加载类，没留基线，后来开机慢了半分钟，全组查了两天才定位到是另一个改动引起的，白折腾。从那以后我每次动性能配置都强制走一遍基线、改动、回归这三步，宁可慢一点，也不给自己留查不清的账。希望这套八条主线的拆法能帮到你，拿去改成自己项目的验收表就能直接用。

本文还有配套的精品资源，点击获取