性能优化离不开度量，而度量的第一手数据往往来自代码级别的微观基准测试。Android Microbenchmark指的是针对单个方法、算法片段或某段业务逻辑进行的细粒度性能测量，它的目标是回答一个具体问题：这段代码在一次调用中到底消耗了多少时间、分配了多少内存。与之相对的是Macrobenchmark，后者关注的是整个应用层面的启动耗时、滚动流畅度等宏观指标。两者不是替代关系，而是互补关系：先用宏观测试发现性能瓶颈的位置，再用微观测试验证某段可疑代码的真实开销，这是一条成熟的性能排查路径。
为什么Microbenchmark容易测不准
很多开发者在没接触过基准测试框架之前，会写一段类似这样的代码来测量耗时：
long start = System.nanoTime();
doSomething();
long cost = System.nanoTime() - start;
System.out.println("耗时: " + cost + " ns");</code>
这种写法在Android上几乎得不到可信的数据。第一个原因是JIT预热，ART虚拟机在代码刚运行时走解释执行，热点方法被调用足够多次后才会编译成本地机器码，前几千次调用和后几千次调用的耗时可能相差一个数量级。只测一两次，拿到的是解释执行阶段的假数据。
第二个原因是死代码消除。编译器发现doSomething()的返回结果没有被使用，且方法本身没有副作用时，可能会直接把它优化掉，最终你测到的耗时接近于零。第三个原因是设备状态的不稳定：CPU频率调节、温控降频、后台进程抢占，都会让同一份代码在不同时刻跑出差异很大的结果。一个合格的基准测试框架必须处理好这三个问题，这也正是JMH和androidx.benchmark存在的意义。
方案一：使用androidx.benchmark进行Microbenchmark
androidx.benchmark是Google官方推出的基准测试库，专门针对Android环境做了适配，包括自动处理CPU频率锁定、禁止设备进入低电量模式等干扰因素。使用它需要新建一个独立的测试模块，在模块的build.gradle中添加依赖：
android {
namespace 'com.example.benchmark'
}
dependencies {
androidTestImplementation 'androidx.benchmark:benchmark-junit4:1.2.3'
androidTestImplementation 'androidx.test.ext:junit:1.1.5'
androidTestImplementation 'androidx.test:runner:1.5.2'
}接着编写具体的测试类，用@Benchmark注解标记要测量的方法：
@RunWith(AndroidJUnit4.class)
class MyBenchmark {
@get:Rule
val benchmarkRule = BenchmarkRule()
@Test
fun measureListSort() {
benchmarkRule.measureRepeated {
// 被测代码：对一个较大的列表进行排序
val data = mutableListOf<Int>()
repeat(10000) { data.add((0..100000).random()) }
data.sort()
}
}
}运行方式是执行./gradlew :benchmark:connectedAndroidBenchmarkAndroidTest，测试完成后Gradle会在模块的build目录下生成一份JSON格式的报告，包含最小耗时、中位数、标准差等统计指标。建议重点关注中位数和标准差：中位数反映典型性能，标准差过大说明测量过程受到干扰，数据不可信。需要注意的一点是，官方建议在测量块内避免生成随机数据之类的准备工作，这类开销会被计入测量结果，更好的做法是提前在measureRepeated外部准备好数据，块内只保留被测逻辑本身。
方案二：使用JMH进行更细粒度的测量
JMH是OpenJDK团队出品的基准测试框架，功能比androidx.benchmark更丰富，支持多种模式（吞吐量、平均耗时、采样耗时），还能通过Blackhole对象消费计算结果来规避死代码消除。要在Android项目中使用JMH，常见做法是单独建一个纯JVM模块，因为算法类的代码通常不依赖Android API，直接在JVM上测量的误差来源更少：
@State(Scope.Thread)
public class StringBenchmark {
private String[] data;
@Setup
public void setup() {
// 准备阶段，不计入测量结果
data = new String[1000];
for (int i = 0; i < data.length; i++) {
data[i] = "item-" + i;
}
}
@Benchmark
public String testStringBuilder(Blackhole bh) {
StringBuilder sb = new StringBuilder();
for (String s : data) {
sb.append(s);
}
// 用Blackhole消费结果，防止死代码消除
bh.consume(sb.toString());
}
@Benchmark
public String testStringConcat(Blackhole bh) {
String result = "";
for (String s : data) {
result = result + s;
}
bh.consume(result);
}
}JMH会自动进行预热轮次，把JIT编译的影响隔离在正式测量之前。@State注解保证了测试数据的初始化隔离，@Setup中的逻辑不会污染计时。上面这个例子对比的是循环中字符串拼接的两种写法，运行后你会直观看到StringBuilder方案比+号拼接快几个数量级，因为后者每次循环都会创建新的String对象。这个结论虽然人尽皆知，但通过基准测试拿到具体倍数，在推动团队修改遗留代码时往往更有说服力。
结果解读与常见实践误区
拿到基准数据后，解读时要坚持几个原则。第一，不要只看平均值，优先看中位数和百分位数据（如P99），平均值容易被少数异常长的耗时拉偏。第二，对比实验必须控制变量，两次测试之间只允许一个差异点，否则结论不可归因。第三，在真机上测得的数据只对那台设备有效，不同SoC、不同Android版本的测试结果可能完全相反，比如某些机型上小对象分配很便宜，另一些机型则开销明显。
还有一些常见误区值得警惕。有人在debug模式下运行基准测试，此时代码没有经过优化，数据没有参考价值，务必使用release或至少关闭debuggable。有人把网络请求、磁盘读写放进Microbenchmark，这类IO操作的波动远大于代码本身的差异，应该用其他手段评估。还有人测出一个方案快5%就匆忙替换线上代码，却忽略了重构带来的可读性损失，微观层面的微小提升是否值得，要结合该代码的调用频率来综合判断，一个每帧只调用一次的方法快5%，对帧率的影响可能微乎其微。
总体来说，Microbenchmark是性能工程中精度最高的测量手段，但它也最容易被误用。建立先测量、再优化、优化后回归测量的工作流，让每一次性能改动都有数据支撑，才能真正发挥它的价值。
Android Microbenchmark代码性能测试Benchmark修改时间：2026-09-12 18:28:38