第29章性能优化与测试

课程目录第29章性能优化与测试

第29章性能优化与测试：自动化性能测试框架与CI/CD集成

性能优化做到最后，你会发现一个尴尬的现实——优化一时爽，回归火葬场。我自己就吃过这个亏。有一回我花了两周把启动速度优化了30%，结果同事合入一个第三方SDK，一夜回到解放前。更惨的是，这个问题直到上线前才被发现。

所以，性能优化必须配上自动化测试。没有门禁的优化，说白了就是自我感动。今天我们就聊聊怎么搭建一套靠谱的自动化性能测试体系。

29.1 自动化性能测试框架选型

市面上能用的框架不少，我重点说说两个：Macaca 和 Airtest。这两个我都深度用过，各有千秋。

29.1.1 Macaca：适合深度定制

Macaca 是阿里开源的一套自动化方案。它的核心思路是「统一驱动层」，底层支持 iOS、Android、Web。对于性能测试来说，它的优势在于可以拿到非常细粒度的系统数据。

我的经验：Macaca 的 app-inspector 工具特别好用。你可以用它定位到任意一个控件，然后直接获取它的渲染耗时。我曾经用它抓过一个列表卡顿的问题——定位到是某个自定义 View 的 onDraw 里做了太多计算。

一个典型的 Macaca 性能测试脚本长这样：

const wd = require('macaca-wd');
const driver = wd.promiseChainRemote('http://localhost:3456');

// 启动应用
await driver.init({
  platformName: 'Android',
  app: '/path/to/your.apk',
  udid: 'emulator-5554'
});

// 启动性能采集
await driver.startPerformance({
  packageName: 'com.example.app',
  types: ['cpu', 'memory', 'fps', 'network']
});

// 执行核心操作
await driver.elementById('btn_login').click();
await driver.sleep(2000);

// 获取性能数据
const perfData = await driver.getPerformance();
console.log('CPU:', perfData.cpu);
console.log('Memory:', perfData.memory);
console.log('FPS:', perfData.fps);

// 断言：FPS 不能低于 30
assert.ok(perfData.fps.average >= 30, 'FPS 不达标！');

嗯，这里要注意：Macaca 的 startPerformance 接口在部分国产 ROM 上可能拿不到数据。我遇到过小米 MIUI 上 FPS 始终返回 0 的情况，后来发现是权限问题，需要手动开启「开发者选项」里的「GPU 渲染模式分析」。

29.1.2 Airtest：适合快速验证

Airtest 是网易开源的，基于图像识别。它的好处是「所见即所得」——你不需要关心控件 ID，直接截图匹配就行。对于性能测试，Airtest 提供了 perf 模块，可以一键采集。

from airtest.core.api import *
from airtest.core.android.perf import Perf

# 连接设备
connect_device('Android:///')

# 启动应用
start_app('com.example.app')

# 创建性能采集器
perf = Perf()
perf.start('com.example.app')

# 执行操作
touch(Template('login_btn.png'))
sleep(2)

# 停止采集并输出
perf.stop()
print(perf.get_results())

避坑指南：我曾经用 Airtest 做回归测试，发现不同分辨率的手机上截图匹配失败。后来我改用「多分辨率截图 + 相似度阈值」的方式解决。具体做法是：准备 3 套截图（1080p、1440p、720p），匹配时取相似度最高的那个。

29.2 CI/CD 流水线集成性能门禁

自动化测试只是第一步。真正让团队不掉坑的，是性能门禁。说白了，就是每次提交代码，CI 自动跑性能测试，不达标就不让合入。

29.2.1 门禁指标怎么定？

我建议不要贪多。一开始只盯 3 个核心指标：

指标	阈值	说明
冷启动时间	< 2.5s	从点击图标到首帧渲染
内存峰值	< 200MB	常规操作场景下的最大内存
FPS 低值	>= 25	1% 低帧率不低于 25

为什么是这三个？因为这三个指标直接关联用户体验。启动慢用户会卸载，内存高会被系统杀，掉帧多用户会卡到骂娘。

29.2.2 Jenkins Pipeline 示例

我团队用的是 Jenkins + GitLab CI。下面是一个简化的 Pipeline 配置：

pipeline {
    agent any

    stages {
        stage('Build') {
            steps {
                sh './gradlew assembleDebug'
            }
        }

        stage('Performance Test') {
            steps {
                sh 'python3 run_perf_test.py --apk app-debug.apk'
            }
            post {
                success {
                    // 解析性能报告
                    script {
                        def report = readJSON file: 'perf_report.json'
                        def startupTime = report.startup_time
                        def memoryPeak = report.memory_peak
                        def fpsLow = report.fps_low

                        // 门禁检查
                        if (startupTime > 2.5) {
                            error "冷启动时间 ${startupTime}s 超过阈值 2.5s"
                        }
                        if (memoryPeak > 200) {
                            error "内存峰值 ${memoryPeak}MB 超过阈值 200MB"
                        }
                        if (fpsLow < 25) {
                            error "FPS 低值 ${fpsLow} 低于阈值 25"
                        }
                    }
                }
            }
        }

        stage('Deploy') {
            when {
                branch 'master'
            }
            steps {
                sh './deploy.sh'
            }
        }
    }
}

注意：门禁阈值不要设得太死。我见过一个团队把冷启动时间设为 1.5s，结果每次 CI 都挂，开发直接绕开门禁合代码。后来我建议他们设一个「警告线」和「红线」——超过警告线发通知，超过红线才阻止合入。这样既保住了底线，又不至于让流程形同虚设。

29.3 回归测试策略

性能回归测试，最怕的就是「跑一次要半小时」。你想想看，开发改一行代码，等半小时才知道有没有问题，谁受得了？

我的策略是分层回归：

29.3.1 第一层：快速冒烟（2分钟）

只测 3 个核心场景：冷启动、列表滑动、页面跳转
只采集 3 个指标：启动时间、FPS、内存
触发条件：每次提交

29.3.2 第二层：完整回归（15分钟）

覆盖 20+ 个核心场景
采集 CPU、内存、FPS、网络、磁盘 I/O
触发条件：每日构建 / 合入 master 前

29.3.3 第三层：全量回归（1小时）

覆盖所有页面和交互
包含压力测试、长时间运行测试
触发条件：每周 / 发版前

这样做的好处是：开发提交代码后，2 分钟就能知道有没有「炸」。如果冒烟没过，直接打回，不用等完整回归。我团队用这个策略后，性能回归的反馈时间从 40 分钟降到了 3 分钟以内。

29.4 知识体系总览

下面这张图总结了本章的核心逻辑：

29.5 落地建议

最后，给你几个实操建议：

先跑通一个场景。别一上来就想覆盖所有页面。先选一个核心场景（比如冷启动），把整个链路跑通——从脚本编写到 CI 触发到门禁拦截。跑通了再扩展。
性能基线要动态调整。我习惯每周自动更新一次基线。比如这周的平均启动时间是 2.1s，那门禁阈值就设为 2.1s * 1.2 = 2.52s。这样基线会随着优化逐步收紧。
测试设备要固定。不同设备的性能差异很大。我建议选一台中低端机作为「基准设备」，所有性能测试都在它上面跑。高端机可以辅助验证，但门禁只看基准设备的数据。
失败时保留现场。性能测试失败时，自动保存 logcat、截图、性能 dump 文件。这样开发拿到失败通知后，可以直接看现场，不用复现。

一个小技巧：在 CI 脚本里加一个「对比模式」。每次测试结果自动和上一次对比，如果某个指标恶化超过 10%，即使没超过门禁阈值，也发一个警告。这样可以在问题变严重之前就发现它。我团队用这个方式提前发现了 3 次内存泄漏。

好了，自动化性能测试这块就聊到这儿。记住一句话：没有门禁的优化，都是假把式。把流程建起来，让机器替你把关，你才能腾出手来做更有价值的事情。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录