1. 项目概述与核心挑战

在移动应用开发这个行当里，我们每天都在和性能、流畅度、内存占用这些指标较劲，但有一个指标，它直接关系到用户会不会在关键时刻骂娘然后卸载你的应用，那就是 能耗 。电池续航是智能手机体验的基石，一个应用功能再炫酷，如果半小时就能把电量从100%干到20%，那它离被抛弃也就不远了。我见过太多团队，在冲刺功能、修复崩溃、优化UI上投入巨大，却往往把能耗问题留到“以后再说”，或者干脆依赖用户反馈——等用户抱怨手机发烫、电量尿崩时，问题往往已经积重难返。

问题的根源在于，能耗优化长期以来缺乏一个 可量化、自动化、且能融入快速开发流程 的检测手段。开发者知道要省电，但具体是哪次代码提交引入了问题？是哪个模块、哪个API调用导致了异常耗电？传统方法，比如基于CPU、GPU、网络等硬件组件利用率的建模，存在明显短板。它们很难准确刻画像“尾能耗”（Tail Energy）这样的非线性现象——比如网络请求结束后，射频模块仍会保持高功率状态一段时间才进入休眠。此外，静态代码分析工具虽然能发现一些明显的“坏味道”，比如未关闭的传感器或Wifi锁，但对于更复杂的、由特定代码逻辑组合引发的能耗峰值，往往力不从心。

这就引出了我们这次要深入探讨的核心思路： 基于系统调用（System Call）的能耗建模 。系统调用是应用程序与操作系统内核交互的唯一接口，任何对硬件资源（文件、网络、传感器等）的访问，最终都会转化为一系列系统调用。因此，系统调用的类型、频率和模式，是刻画应用能耗行为的更底层、更精确的“指纹”。结合 机器学习 ，我们可以从海量的系统调用数据中，自动学习出这个“指纹”与真实能耗之间的映射关系，从而构建一个预测模型。这个模型的价值在于，它不仅能评估现有版本的能耗，更能像一位不知疲倦的测试员，在每次代码提交后，自动预测其能耗变化，精准定位引入“能耗缺陷”（Energy Bug）的那次提交。

2. 核心原理：为什么是系统调用与机器学习？

2.1 从硬件利用率到系统调用：建模精度的跃迁

要理解为什么系统调用是更好的建模基础，我们得先看看传统方法的局限。假设你的应用播放了一段视频。一个基于CPU利用率的模型可能会记录：“CPU占用率70%，持续10秒”。但这70%的占用率，具体是花在了视频解码、音频渲染，还是UI线程的无效等待上？模型无法区分。更重要的是，它完全忽略了播放结束后，视频解码器、音频驱动等硬件可能仍处于活跃状态所消耗的“尾能耗”。

系统调用视角则截然不同。它会记录下这样一串事件： open() 打开视频文件， mmap() 将文件映射到内存，一系列 ioctl() 调用控制解码器硬件， write() 向音频缓冲区写入数据， poll() 等待渲染完成，最后是 close() 关闭文件描述符。这个过程精确描述了应用 做了什么 ，而不仅仅是硬件 有多忙 。通过统计不同系统调用的次数（例如， read / write 的次数反映I/O强度）以及进程占用CPU的时间片（jiffies），我们就能构建一个特征向量，这个向量直接关联了软件行为意图与最终的能耗结果。

2.2 机器学习作为“模式识别器”的角色

有了系统调用特征和对应的真实能耗数据（作为标签），我们就拥有了一个标准的 监督学习 问题。机器学习模型在这里扮演一个复杂的、非线性的“模式识别器”和“拟合器”。它的任务不是让我们去理解每条系统调用具体消耗了多少焦耳的能量（那几乎是不可能的），而是从历史数据中学习出一个函数 f(特征向量) ≈ 能耗值 。

这个过程的核心优势在于 自动化 和 数据驱动 。我们不需要手动为每个系统调用或API编写能耗成本表（这在不同芯片架构、系统版本上差异巨大）。我们只需要收集足够多的、覆盖不同场景的（应用行为，能耗）数据对，然后让算法自己去发现其中的统计规律。当模型训练好后，对于一段新的、从未见过的代码所产生的系统调用序列，模型就能给出一个可靠的能耗预测值。这为在持续集成（CI）流水线中嵌入能耗回归测试提供了技术基础。

2.3 能耗缺陷的检测逻辑：在版本历史中定位异常

将上述模型应用于开发实践，就形成了我们的核心工作流。假设我们有一个应用，它有从v1.0到v5.0的数百个提交（commit）。对于每个提交版本编译出的APK，我们都可以通过自动化测试，运行相同的测试用例，并收集其产生的系统调用特征向量。然后，将特征向量输入训练好的能耗预测模型，得到该版本的 预测能耗值 。

同时，如果条件允许，我们可以用精密的硬件设备（如Monsoon电源监测仪或通过USB端口监测）测量该版本的 真实能耗值 ，但这通常成本高昂且无法全量进行。更实用的场景是，我们只对少数关键版本或怀疑有问题的版本进行真实测量。

检测逻辑如下：我们绘制出每个提交版本对应的预测能耗曲线。在正常的开发迭代中，这条曲线应该是相对平稳或有规律地小幅波动。一旦某个提交引入了能耗缺陷（例如，新增了一个循环中未释放的传感器监听器），该提交版本的预测能耗值就会出现一个 显著的尖峰或跃升 。通过与代码变更记录（Git Diff）结合，开发者就能迅速定位到是哪些代码修改导致了这个问题。这相当于为能耗问题安装了一个“烟雾报警器”。

3. 实操构建：从数据到模型的完整链路

3.1 数据采集：构建可靠的能耗特征库

一切模型的基础都是数据。我们的数据来源需要包含两部分： 特征（X） 和 标签（y） 。

特征采集（系统调用与资源使用） ： 我们主要依赖 strace 工具。这是一个强大的Linux诊断工具，可以跟踪一个进程执行期间发出的所有系统调用。在Android环境下，可以通过 adb shell 在设备上运行。一个简化的采集脚本示例如下：

#!/bin/bash
# 启动应用并获取其PID
adb shell am start -n com.example.app/.MainActivity
sleep 2 # 等待应用启动
PID=$(adb shell pidof com.example.app)

# 使用strace跟踪该进程，统计系统调用次数
# -c 参数表示统计摘要，-p 指定进程ID
adb shell strace -c -p $PID -o /data/local/tmp/trace_output.txt &
STRACE_PID=$!

# 运行自动化测试（例如，通过UIAutomator遍历主要功能）
adb shell uiautomator runtest your_test.jar -c com.example.Test

# 停止strace
kill $STRACE_PID
wait $STRACE_PID 2>/dev/null

# 将结果拉取到本地
adb pull /data/local/tmp/trace_output.txt .

得到的 trace_output.txt 文件会包含类似下面的摘要，这就是我们原始的特征：

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 45.32    0.123456         102      1201           read
 22.15    0.060123          50      1202           write
 10.05    0.027345         273       100           poll
 ... (其他系统调用)
------ ----------- ----------- --------- --------- ----------------
100.00    0.272456                  4321           total

我们需要提取每个系统调用的调用次数（calls列）。同时，还需要从 /proc/[pid]/stat 等文件获取进程��整个测试周期内消耗的CPU时间（以jiffies为单位）。最终，我们将所有测试用例（对应不同应用或同一应用的不同版本）的 系统调用次数向量 和 CPU时间 拼接成一个大的特征矩阵，每一行代表一次测试，每一列代表一个特征（如 read 调用次数、 write 调用次数、CPU jiffies等）。

标签采集（真实能耗值） ： 这是最耗时但也是最关键的一步。为了获得ground truth，需要硬件级的测量。学术界常用的是搭建一个“硬件在环”的测试床：

1. 设备 ：一台被测Android手机。
2. 供电 ：断开手机电池，通过一个可编程的直流电源（如Agilent N6705B）或专用的高精度电源监测仪（如Monsoon Power Monitor）为手机供电。
3. 测量 ：电源设备可以实时测量并记录流入手机的电压和电流，从而精确计算出瞬时功率（P=UI）和一段时间内的总能耗（E=∫P dt）。
4. 同步 ：通过脚本控制，在开始运行自动化测试用例的同时，开始记录功耗数据。测试结束后，将功耗数据与系统调用特征数据在时间线上对齐，计算出该测试用例的总能耗（单位：焦耳），这就是该行特征对应的标签 y 。

实操心得 ：数据质量决定模型上限。测试用例的设计要尽可能覆盖应用的各种状态（前台、后台、网络交互、传感器使用、音视频播放等）。每个测试用例应独立、可重复。采集过程中，要确保手机处于飞行模式（仅测试时打开必要网络）、固定屏幕亮度、关闭无关后台服务，以降低环境噪声。一次完整的数据采集可能需要数天甚至数周，但这是构建可靠模型的必要投入。

3.2 特征工程：降维与筛选的平衡艺术

原始数据采集后，我们可能得到上百个特征（122个，如论文所述）。直接用于训练容易导致“维度灾难”和过拟合。因此， 特征选择（Feature Selection） 至关重要。我们的目标不仅是减少特征数量，更是要找出那些真正对能耗有显著影响的“驱动因子”。

论文中提出了一种 “平衡递归特征消除与交叉验证” 的方法。我们来拆解一下这个听起来很复杂的技术：

1. 递归特征消除（RFE） ：其核心思想是“逐步淘汰”。首先用所有特征训练一个模型（例如Lasso回归，因为它本身具有特征选择能力）。然后，根据模型给出的特征重要性排序（例如，Lasso回归中系数绝对值的大小），淘汰掉最不重要的一个或一批特征。用剩下的特征重新训练模型，再次排序淘汰。如此递归，直到剩下指定数量的特征。

2. 结合交叉验证（CV） ：单纯的RFE可能不稳定。为了获得更鲁棒的特征子集，我们将交叉验证融入循环。在每一轮淘汰中，我们不是用全部数据训练一次模型来排序，而是进行K折交叉验证（比如5折）。在每一折中，我们用训练集训练模型并得到特征重要性，在验证集上评估用当前特征子集训练的模型性能。最后，综合K次的结果，选择平均性能最好时对应的特征子集。

3. “平衡”策略 ：为了进一步避免随机性，将上述“RFE+CV”的整个过程重复执行M次（例如10次）。统计每个特征在这M次独立实验中被选入最终优秀特征子集的次数。次数越多的特征，其重要性越稳定、越可靠。最终，我们可以根据这个“入选频率”对所有特征进行排名，并选择一个阈值（比如频率>5次）来确定最终的特征集合。

通过这个过程，我们可能从122个特征中筛选出15-20个关键特征。论文中的结果显示， 测试用例执行时长、软件中断（software interrupt）次数、上下文切换（context switch）次数、以及某些特定的I/O系统调用 是影响能耗的最主要因素。这为开发者提供了明确的优化方向：减少不必要的线程切换、优化I/O操作模式、避免频繁的中断等。

3.3 模型选型与超参数调优：寻找最佳预测器

特征准备好之后，下一步就是选择并训练机器学习模型。我们面对的是一个 回归问题 （预测连续的能耗值）。论文中对比了七种模型，我们在实际工作中也可以以此为参考：

模型类别	具体模型	核心思想与适用场景	关键超参数
线性模型	线性回归（Lasso/Ridge）	寻找特征与能耗间的线性关系。Lasso（L1正则化）能自动将不重要特征的系数压缩为0，兼具特征选择功能。Ridge（L2正则化）能防止系数过大，稳定模型。	alpha ：正则化强度。Lasso的alpha通常很小（如0.001），Ridge的alpha范围更广。
线性模型	随机梯度下降回归（SGD）	适用于海量数据。通过迭代分批更新模型参数，效率高。也可搭配L1/L2正则化。	alpha ：正则化强度； learning_rate ：学习率； max_iter ：最大迭代次数。
支持向量机	支持向量回归（SVR）	寻找一个“管道”（epsilon-tube）使得尽可能多的样本落在管内，对异常值相对不敏感。可使用线性或RBF核处理非线性。	C ：惩罚系数（容错程度）； epsilon ：管道宽度； kernel ：核函数； gamma （RBF核）：影响单个样本的影响范围。
集成学习	AdaBoost回归	串行集成。依次训练多个弱学习器（如决策树桩），每个新的学习器都更关注前一个学习器预测错误的样本。	n_estimators ：弱学习器数量； learning_rate ：学习率，控制每个弱学习器的贡献权重。
集成学习	随机森林回归	并行集成。构建多棵决策树，每棵树用随机采样的数据和随机选取的特征训练，最终结果取平均。抗过拟合能力强。	n_estimators ：树的数量； max_depth ：树的最大深度； max_features ：每棵树考虑的最大特征数。
集成学习	梯度提升树回归	串行集成。每一棵树都在学习前一棵树预测结果的残差（梯度方向），是当前许多竞赛的常用模型。	n_estimators ：树的数量； learning_rate ：学习率； max_depth ：树的最大深度。

超参数调优实战 ： 我们以Lasso回归为例，演示如何使用网格搜索（Grid Search）与交叉验证寻找最优 alpha 。

from sklearn.linear_model import Lasso
from sklearn.model_selection import GridSearchCV
from sklearn.preprocessing import StandardScaler
from sklearn.pipeline import Pipeline

# 假设 X_train, y_train 是我们的训练数据和标签
# 1. 创建管道：先标准化，再应用Lasso
pipeline = Pipeline([
    ('scaler', StandardScaler()), # 特征标准化至关重要
    ('lasso', Lasso(max_iter=10000)) # 增加迭代次数确保收敛
])

# 2. 设置超参数网格
param_grid = {
    'lasso__alpha': [0.0001, 0.0005, 0.001, 0.005, 0.01, 0.05, 0.1]
}

# 3. 创建GridSearchCV对象，使用5折交叉验证，以负均方误差为评分标准
grid_search = GridSearchCV(pipeline, param_grid, cv=5, scoring='neg_mean_squared_error', verbose=1, n_jobs=-1)

# 4. 在训练数据上执行搜索
grid_search.fit(X_train, y_train)

# 5. 输出最佳参数和对应的交叉验证分数
print(f"Best alpha: {grid_search.best_params_['lasso__alpha']}")
print(f"Best CV score (negative MSE): {grid_search.best_score_}")

# 获取最佳模型
best_lasso_model = grid_search.best_estimator_

注意事项 ：一定要在 训练集 上进行特征缩放（如Z-score标准化）和超参数调优，然后用同样的缩放器去变换 验证集和测试集 ，避免数据泄露。 GridSearchCV 的 scoring 参数可以根据需求选择，常用 'neg_mean_squared_error' （负均方误差，越大越好）或 'r2' （R平方）。

根据论文中的实验结果，在他们的数据集上， 经过L1正则化的线性回归（Lasso）模型表现最佳 。这其实给了我们一个很重要的启示：对于系统调用和CPU时间这类特征，能耗与它们之间的关系很可能 接近线性 ，或者主要的线性部分已经被特征选择捕捉到了。复杂的非线性模型（如带RBF核的SVR或深度树模型）反而可能因为引入不必要的复杂度而降低了泛化能力。在实际项目中，从简单的线性模型开始尝试，是一个明智且高效的选择。

4. 模型评估与能耗缺陷检测实战

4.1 如何科学地评估你的能耗模型？

模型训练好后，我们不能只看它在训练集上的表现。需要用未见过的数据来评估其泛化能力。通常我们将数据分为三部分：训练集（60%）、验证集（20%）、测试集（20%）。验证集用于调参，测试集用于最终评估。

评估回归模型，常用以下指标：

• 均方误差（MSE）与均方根误差（RMSE） ：衡量预测值与真实值之间的平均平方差异。RMSE与目标变量单位相同，更易解释。值越小越好。
• 平均绝对误差（MAE） ：衡量预测值与真实值之间的平均绝对差异。对异常值不如MSE敏感。值越小越好。
• 决定系数（R²） ：表示模型能够解释的目标变量方差的比例。范围在0到1之间，越接近1说明模型拟合越好。

在能耗预测场景中， MAE 是一个非常直观的指标。例如，如果MAE是50毫焦耳（mJ），这意味着模型对一次测试用例能耗的预测，平均会偏离真实值50mJ。你需要结合应用的实际能耗水平来判断这个误差是否可接受。如果一次典型操作的能耗是500mJ，那么10%的误差可能尚可；如果是50mJ，那这个模型就基本不可用了。

4.2 在版本历史中定位能耗缺陷：一个模拟案例

假设我们有一个开源天气应用“SunnyWeather”，我们获取了它从v1.0到v3.0的共30个提交版本。我们对每个版本都编译APK，并运行一套固定的自动化测试（例如：启动App、定位刷新天气、切换城市、查看逐小时预报、退出）。对于每个版本，我们收集系统调用特征，并用训练好的Lasso模型预测其能耗。

我们得到了一条预测能耗曲线。同时，我们挑选了v1.5， v2.0， v2.5， v3.0这四个关键版本，用硬件设备进行了真实的能耗测量。

提交版本	预测能耗 (mJ)	真实能耗 (mJ)	代码变更摘要
...	...	...	...
v2.3	420	N/A	修复了城市列表滚动卡顿问题（优化了RecyclerView的onBindViewHolder逻辑）
v2.4	680	N/A	新增了背景动态天气效果（使用了Canvas持续绘制）
v2.5	650	660	优化了动态效果的帧率
v2.6	430	N/A	移除了有问题的动态效果，回滚到v2.3的UI
...	...	...	...

分析过程 ：

1. 观察预测曲线 ：从v2.3到v2.4，预测能耗出现了一个巨大的跃升（420mJ -> 680mJ）。这是一个强烈的异常信号。
2. 关联代码变更 ：查看v2.4的提交记录，发现引入了“背景动态天气效果”，这涉及到持续的UI重绘（ Canvas 绘制），会导致大量的 syscall （如 write 到帧缓冲区）和CPU占用，与模型识别出的高能耗特征（图形相关系统调用、高CPU jiffies）吻合。
3. 验证 ：v2.5版本的预测能耗（650mJ）与真实测量值（660mJ）非常接近，误差在可接受范围内，证明了模型预测的准确性。同时v2.5的提交说明是“优化帧率”，但预测能耗并未显著下降，说明这种优化治标不治本。
4. 结论与行动 ：v2.4的提交引入了 能耗缺陷 。开发团队在代码审查时，如果集成了这个能耗预测模型，就能在合并请求（Merge Request）阶段收到警报：“此提交可能导致能耗增加超过60%”。开发者可以立即审视这段新增的动画代码，考虑是否必须，或者寻找更高效的实现方式（例如使用硬件加速、降低刷新频率）。最终在v2.6版本，团队决定移除该特性，能耗回归正常水平。

4.3 基于特征重要性的代码优化建议

模型不仅给出了预测，其本身也包含了知识。Lasso模型筛选出的重要特征，直接指明了能耗的“热点区域”：

1. context_switch （上下文切换）次数高 ：这通常意味着线程管理有问题。检查是否创建了过多不必要的线程，或者线程间通信（如Handler）过于频繁。可以考虑使用线程池，或将短任务合并。
2. poll / select 等系统调用频繁 ：这通常意味着I/O操作（尤其是网络）存在阻塞或轮询。优化网络请求，使用更高效的数据格式（如Protocol Buffers替代JSON），合并请求，或采用非阻塞I/O与回调机制。
3. 特定文件操作（如 open / close ）频繁 ：检查是否有在循环中重复打开关闭文件、数据库连接未复用等情况。使用对象池或单例模式管理昂贵资源的生命周期。
4. CPU jiffies（时间片）占用高 ：这是最直接的CPU消耗指标。使用性能分析工具（如Android Profiler的CPU记录）找到热点函数，检查算法复杂度，避免在主线程进行大量计算。

5. 常见问题、挑战与应对策略

5.1 数据收集的挑战与技巧

挑战1：硬件测量成本高且难以规模化。

• 应对 ：对于大部分团队，不具备搭建精密电源监测仪的条件。可以考虑替代方案：
  • 使用Android内置的Battery Historian ：通过 adb bugreport 获取电量消耗估算。虽然精度远低于硬件，且是系统级估算，但作为相对比较（版本A vs 版本B）的参考，在严格控制测试环境（相同设备、相同初始状态、相同测试脚本）的情况下，仍有价值。
  • 利用厂商提供的功耗调试接口 ：一些芯片厂商（如Qualcomm）提供了底层的功耗调试工具（如Trepn Profiler），能提供组件级（CPU cluster， GPU， Modem）的功耗估算，精度尚可。
  • 云端真机测试平台 ：一些云测平台开始提供功耗测试服务。虽然也是估算，但可以作为CI/CD中的一个自动化检查点。

挑战2：测试用例的覆盖度与代表性。

• 应对 ：能耗与用户操作路径强相关。需要构建 用户场景画像 ，设计端到端（E2E）的自动化测试。
  • 关键用户旅程（Critical User Journey） ：梳理出应用最核心的5-10个用户操作流，如“注册-登录-浏览核心内容-下单-退出”。
  • 使用Appium或UIAutomator2 ：编写自动化脚本，模拟这些用户旅程。确保每次测试的路径、等待时间、操作间隔一致。
  • 包含边缘和异常场景 ：如网络从WiFi切换到4G、处理大量数据、后台播放音频等。

5.2 模型泛化与设备碎片化

挑战：在一个设备/系统版本上训练的模型，在另一个设备上预测不准。

• 根本原因 ：不同型号的手机，其芯片架构（ARM big.LITTLE）、制程工艺、屏幕材质（OLED/LCD）、甚至系统调度策略都不同，导致相同的系统调用模式产生的实际功耗存在差异。
• 应对策略 ：
  1. 设备特异性建模 ：为需要重点保障的主流机型分别建立模型。虽然成本高，但结果最准确。
  2. 特征工程增强 ：在特征中加入设备硬件信息（如芯片型号、屏幕分辨率、电池容量）作为静态特征。让模型自己去学习不同硬件下的能耗转换关系。
  3. 迁移学习 ：在一个数据丰富的“源设备”上训练一个基础模型，然后用在“目标设备”上收集的少量数据对这个模型进行微调（Fine-tuning），可以快速获得一个在目标设备上可用的模型。
  4. 关注相对值而非绝对值 ：如果绝对功耗预测困难，可以转而预测 能耗变化率 。例如，模型专注于判断“这次提交相比上个提交，能耗是增加了10%还是减少了5%”。这对于检测引入回归的提交同样有效，且对设备差异的敏感性可能更低。

5.3 集成到开发流程中的实践要点

目标 ：让能耗检测像单元测试一样，成为CI/CD流水线中的一道自动关卡。

1. 轻量级流水线集成 ：

   • 在合并请求（Merge Request）触发构建时，除了运行单元测试和UI测试，新增一个“能耗预测”任务。
   • 该任务自动编译APK，在专用的测试设备（或模拟器）上运行核心场景的自动化测试，通过 strace 收集系统调用特征。
   • 调用部署好的能耗预测模型服务，得到本次提交相对于基准版本的能耗变化预测。
   • 如果预测能耗增幅超过预设阈值（如15%），则在合并请求页面标记警告或直接阻塞合并，要求开发者检查。

2. 结果可视化与反馈 ：

   • 在内部CI平台（如Jenkins、GitLab CI）或监控仪表盘（如Grafana）上，绘制每个版本、每个分支的预测能耗趋势图。
   • 将能耗异常提交与代码变更链接起来，一键跳转查看差异。
   • 定期（如每周）向团队发送能耗报告，标注“能耗热点模块”和“近期能耗回归提交”，提升团队意识。

5.4 模型维护与迭代

模型不是一劳永逸的。随着应用功能迭代、系统版本升级，系统的能耗特性可能会发生漂移。

• 监控模型性能 ：定期（如每季度）用最新的硬件测量数据，验证现有模型的预测准确率（MAE， R²）。如果性能下降超过一定阈值，则需要触发模型重训练。
• 持续数据收集 ：建立一个长期的数据收集机制，将每次正式版本发布前的性能测试数据（包括系统调用和可能的真实功耗数据）归档，作为未来模型迭代的训练数据。
• 概念漂移处理 ：如果发现模型在全新功能（如新增AR模块）上预测完全失灵，说明出现了“概念漂移”。需要针对新功能收集专项数据，并加入到训练集中，重新训练模型。

构建一个基于系统调用和机器学习的Android应用能耗建模与缺陷检测体系，是一项融合了移动开发、系统底层、数据科学和工程实践的综合性工作。它从“事后补救”转向“事前预防”和“事中监控”，将能耗优化从一种模糊的艺术，转变为一项可度量、可分析、可管控的工程实践。虽然起步阶段需要一定的数据积累和工具建设投入，但其带来的长期收益——更优质的用户体验、更低的用户流失风险、以及团队对性能文化的重视——无疑是值得的。最关键的是迈出第一步：开始有意识地收集数据，哪怕是从最简单的版本对比开始。