最新谷歌-在-CI-中使用-Benchmark-进行回归分析，安卓面试项目介绍

总结：

面试是一个不断学习、不断自我提升的过程，有机会还是出去面面，至少能想到查漏补缺效果，而且有些知识点，可能你自以为知道，但让你说，并不一定能说得很好。

有些东西有压力才有动力，而学到的知识点，都是钱（因为技术人员大部分情况是根据你的能力来定级、来发薪水的），技多不压身。

附上我的面试各大专题整理： 面试指南，满满的都是干货，希望对大家有帮助！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

△ RecyclerView、Ads-identifier 以及 Room 的一次基准测试中出现的所有峰值——我们不希望将其作为回归模型报告出来

综上所述，我们不能仅通过第 N 次和 N - 1 次 Build 结果就定位一个测试回归问题——我们需要更多上下文信息来辅助决策。

分步拟合，一个可扩展的解决方案

我们在 Jetpack CI 中进行分步拟合的方法是由 Skia Perf application 提供的。

• Skia Perf applicationhttps://skia.org/dev/testing/skiaperf

这个方法是在基准数据中寻找阶跃函数。当我们检查每个基准测试的结果序列，可以尝试寻找 “阶跃” 的上升或下降的数据点作为特定的 Build 改变基准测试效果的信号。不过我们也要多看几个数据点，以确保我们看到的是多个结果形成的一致的趋势，而不是偶然现象:

△ 上下文可以揭示出性能退化幅度较大的位置可能只是基准化分析结果反复无常的变化而已

那么我们如何挑选出这样一个阶跃呢？我们需要查看变化前后的多个结果:

然后，我们用下面这段代码计算测试回归的权值:

这里操作的原理是，通过检测更改前后的误差，并对该误差的平均值的差进行加权，基准的方差越小，我们就越有信心检测出细微的测试回归。这使得我们可以在一个方差更高的大型 (对于移动平台来说) 数据库基准测试的系统中运行纳秒级精度的微型基准测试。您也可以自己尝试！点击运行按钮，尝试我们 CI 中处理 WorkManager 基准测试产生的数据的算法。它将输出两个链接，一个指向带有测试回归的 build ，另一个指向后续相关的修正 (点击 “View Changes”，来查看该次代码提交的详细内容) 。这些内容与人们在绘制数据时看到的回归和改进相匹配:

• 测试回归

https://ci.android.com/builds/branches/aosp-androidx-master-dev/grid?head=5783944&tail=5783944

• 后续相关的修正

https://ci.android.com/builds/branches/aosp-androidx-master-dev/grid?head=5787972&tail=5787972

根据我们对算法的配置，图中的所有次要噪声都将被忽略。当它开始运行时，您可以尝试用下面两个参数控制算法:

1. 宽度 (WIDTH) — 要涵盖多少个代码提交的结果

2. 阈值 (THRESHOLD) — 达到什么程度时会把回归显示在面板上

增加宽度值会降低不一致性，但是也会导致在结果变动较为频繁时难以发现测试回归——我们当前使用的宽度值是 5。阈值用于整体的敏感性控制——我们当前用的是 25。降低阈值可以看到捕捉更多的测试回归，但是也可能导致更多的误报。

如果想在您自己的 CI 中进行配置，需要:

1. 编写一些基准测试

2. 在真机的 CI 中运行它们, 最好有持续的性能支持

3. 从 JSON 中收集输出指标

4. 当一个结果准备完毕时，检查一下当宽度为两倍时的结果

• 编写一些基准测试 https://developer.android.google.cn/studio/profile/benchmark
• 持续的性能支持https://developer.android.google.cn/studio/profile/benchmark#sustained-perf
• 从 JSON 中收集输出指标https://developer.android.google.cn/studio/profile/run-benchmarks-in-ci

如果有回归或改进，请发出警报 (电子邮件、问题或任何对您有用的措施) 以检查当前 WIDTH 所涵盖的 Build 的性能。

预提交

那么预提交又是什么呢？如果不希望在 Build 中出现测试回归，则可以通过预提交来捕捉回归。在提交前运行基准测试可能是完全防止回归的好方法，但是首先要记住: 基准测试就像 Flaky 测试一样，需要像上述算法这样的基础结构来解决不稳定问题。

对于可能中断提交补丁工作流的预提交测试，您需要对所使用的回归检测有更高的可信度。

由于单次运行基准测试并不能给我们自己带来足够的信心，所以上面的分步拟合算法是必须的。同样，我们可以通过获取更多数据来增加这方面的信心——只需要不加修改地多次运行，来检测补丁是否引入了测试回归即可。

对于每次修改代码然后进行的多次基准测试，都会增加一定的资源消耗，如果您可以接受，那么预提交就能够很好地发挥作用。

全面披露——我们目前没有在 Jetpack 的预提交中使用基准测试，但如果您愿意尝试，以下是我们的建议:

• 不论有无补丁，都要运行基准测试 5 次以上 (后者通常可以缓存，也可以从提交后的结果中获取)；
• 考虑跳过特别慢的基准测试；
• 不要阻止基于结果的补丁提交——只需在代码审查期间考虑结果即可。回归有时会作为改进代码库的一部分！
• 要考虑到以前的结果可能是不存在的。预提交无法检测已添加的基准测试。

结论

Jetpack Benchmark 提供了一种从 Android 设备外获取准确性能指标的简便方法。结合上面的逐步拟合算法，您可以解决不稳定的问题，从而可以在性能问题影响到用户前发现它们的测试回归问题——就像我们在 Jetpack CI 中做的一样。

关于从何处开始的注意事项:

• 在基准测试中捕获关键的滚动界面

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

01)**

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！