接口抓取与录制基础:用抓包工具录下真实交互

进入实战环节之前,我们得先解决一个根本问题——数据从哪来。

你写的 Mock 再漂亮,如果跟真实接口对不上,那就是纸上谈兵。我见过不少同学一上来就猛写 Mock 配置,结果跟后端联调时发现字段结构全对不上,那叫一个痛苦。说白了,高质量 Mock 的前提,是高质量的真实数据样本。

今天我们就聊聊,怎么用抓包工具把 SystemUI 的真实接口交互给“录”下来。

4.1 先选一把趁手的“枪”

抓包工具圈子里,主流就这么几把:

工具 平台 适合场景 我个人的偏好
Charles macOS / Windows 常规 HTTP/HTTPS、接口断点、Rewrite 日常开发主力
Fiddler Everywhere 跨平台 团队协作、脚本扩展 需要分享配置时用
mitmproxy 跨平台 CLI 自动化流程、持续集成 管线化录制首选
Wireshark 跨平台 底层 TCP / TLS 分析 定位网络层问题时才用

我个人习惯把 Charles 当主力,原因很简单——它在 macOS 上的稳定性真的好,而且会话管理能力特别强。不过你要是更熟悉 Fiddler,也没问题,核心逻辑都是相通的。

小贴士:如果你在团队里做 Mock 回放,建议统一工具版本。我在项目里吃过亏,有人用 Charles 4.x,有人用 5.x,导出的 .chlsj 会话文件格式不一致,折腾了半天。

4.2 抓包的两大核心动作

不管用哪款工具,你都要做两件事:代理配置 和 HTTPS 解密。

4.2.1 配置代理——让流量经过你的机器

说白了,就是让你的手机或模拟器把网络请求转发到你电脑上的抓包工具。以 Charles 为例:

1. Charles → Proxy → Proxy Settings
   - HTTP Proxy 端口设为 8888
   - 勾选 "Enable transparent HTTP proxying"

2. 手机连接同一 Wi-Fi
   - 设置 → 网络 → 修改代理为【手动】
   - 主机名填你电脑 IP,端口 8888

3. 验证连接
   - Charles 会弹窗 "Connection from xxx"
   - 点击 Allow

嗯,这里要注意:有些手机系统会限制代理对某些端口或协议的使用。我在项目中遇到过小米手机连代理后部分系统应用请求不走代理的情况,后来只能在路由器层面做透明代理才解决。

4.2.2 HTTPS 解密——撕开加密的外衣

现在大部分接口都走 HTTPS,抓包工具默认只能看到乱码。你需要安装并信任 Charles 的根证书。

1. Charles → Help → SSL Proxying → Install Charles Root Certificate
   - 先在电脑端信任

2. 手机端证书安装
   - 手机浏览器访问:chls.pro/ssl
   - 下载 .pem 文件
   - 前往设置 → 安全 → 从存储设备安装

3. Android 7+ 额外处理(重点!)
   - 系统默认不信任用户安装的 CA
   - 需要将证书推送到系统分区:
   adb root
   adb remount
   adb push cert.der /system/etc/security/cacerts/xxxxx.0
   - 或者使用 VirtualXposed / 太极 等方案
避坑指南:Android 7 以上对用户证书的限制特别烦人。我曾经花了整整一个下午,才发现抓不到 SystemUI 接口是因为证书没推送到系统目录。建议你在一开始就把证书装进系统分区,省得后面排查到怀疑人生。

4.3 过滤与录制——从噪音里捞出金子

手机上的网络请求多得像瀑布,你需要精准地只抓到 SystemUI 相关接口。

我的做法是这样的:

  • 域名过滤:在 Charles 的 Filter 输入框中输入 SystemUI 相关的域名。比如状态栏数据通常来自 xxx.status,通知服务来自 xxx.notification。
  • 进程过滤:如果你用 mitmproxy 配合 Python 脚本,可以根据 User-Agent 或进程 ID 筛选。Charles 的话,可以通过 SSL Proxying Settings 添加指定域名。
  • 录制操作:确定过滤规则后,清除会话历史(Charles → Session → Clear),然后真实地操作一遍 SystemUI 功能。

举个例子。我想录制锁屏界面下拉通知栏的接口交互:

操作步骤:
1. 手机锁屏
2. 唤醒屏幕(不解锁)
3. 下拉通知栏(看快速设置面板)
4. 点击某个快捷开关(如 Wi-Fi)
5. 上滑收起通知栏
6. 解锁进入桌面

抓包目标:
- 锁屏状态下 StatusBar 的状态查询接口
- 快速设置面板加载时的数据请求
- 点击快捷开关后的控制指令接口
关键指标:一次高质量的录制,应该包含 3 轮以上 相同操作序列的重复数据。这样你才能分辨出哪些字段是稳定的,哪些是动态变化(比如时间戳、)的。

4.4 保存与导出——把你的战利品收好

录完之后,记得把会话保存下来。

  • Charles 导出 .chlsj:File → Export Session,选 JSON 格式。这个文件包含了请求/响应的完整细节。
  • Fiddler 导出 .saz:类似 ZIP 包,里面有每个请求的 .txt 和 .dat 文件。
  • mitmproxy 导出 .har:通过 mitmweb 的 Web 界面可以下载 HAR 文件。

我个人强烈推荐 HAR(HTTP Archive)格式。它是开放的 W3C 标准,几乎所有工具都支持导入导出。你想想看,如果团队里有人用 Charles,有人用 Fiddler,都保存成 HAR 就不会打架了。

一个典型的 HAR 文件结构是这样的:

{
  "log": {
    "version": "1.2",
    "creator": { "name": "Charles", "version": "4.6.3" },
    "entries": [
      {
        "request": { "method": "GET", "url": "...", "headers": [...], "postData": ... },
        "response": { "status": 200, "headers": [...], "content": { "text": "..." } },
        "startedDateTime": "2024-01-15T10:23:00.000Z",
        "time": 123
      }
    ]
  }
}

4.5 录制流程总览

下面这张图,把整个抓包录制流程串了起来。你跟着走一遍,基本不会漏步骤。

接口抓包录制完整流程 阶段一:环境构建 1. 选择抓包工具 2. 配置代理端口 3. 连接设备(手机/模拟器) 4. 安装系统根证书 5. 验证连通性 阶段二:流量录制 1. 设置域名过滤 2. 清除历史会话 3. 操作 SystemUI 功能 4. 重复 3+ 轮操作 5. 检查覆盖率 阶段三:导出管理 1. 选择导出格式 2. 导出 HAR / chlsj / saz 3. 添加元数据描述 4. 版本归档(v1.0/v1.1) 5. 分发给团队 🔑 关键活动节点(每个阶段都必须完成的动作) 证书安装 → 过滤配置 → 重复录制 → HAR/HAR 格式导出 → 版本标记 推荐工具:Charles 自动化:mitmproxy 团队协作:Fiddler ⚠️ 常见问题与应对 • Android 7+ 证书问题 → 必须将 CA 推送到系统证书目录 • 某些系统应用不走代理 → 使用透明代理 / iptables 强制转发 • 接口字段动态变化 → 录制 3+ 轮,标记出必变字段与稳定字段 • 导出的 HAR 文件过大 → 使用 mitmproxy 的 filters 预剪裁 • 团队协作时格式冲突 → 统一使用 HAR 作为交换格式

4.6 高质量录制的几个习惯

录得多了,你就会发现有些细节真能决定 Mock 回放的成败。

  • 标记版本:每次录制后,都在 HAR 文件名的备注里写明系统版本、SystemUI 版本、录制时间。我见过最坑的事,就是用了一个月前的旧数据写 Mock,结果接口结构早变了。
  • 录制完整序列:不要只录单次请求。比如下拉状态栏,录下从点击到完全展开的整个过程的请求序列,这样才能还原出真实的时序依赖。
  • 检查静态资源:有些接口返回的不是 JSON,而是图片、字体或国际化字符串。这些也要一并保存,否则 Mock 回放时样式会崩。
血的教训:我去年做一个深色模式切换的 Mock,录的时候忘记保存返回的 icon 图片资源。结果 Mock 回放时,状态栏的图标全是空的,查了半天才发现是图片资源没录进去。嗯,从那以后我每次录完都会检查一遍 —— 响应里是不是只有 JSON?

好了,接口抓取这部分差不多就这些。你拿到原始数据之后,下一件事就是把它整理成结构化的 Mock 配置。不过那就是另一个话题了,咱们先把这步走扎实。