接口抓取与录制基础:用抓包工具录下真实交互
进入实战环节之前,我们得先解决一个根本问题——数据从哪来。
你写的 Mock 再漂亮,如果跟真实接口对不上,那就是纸上谈兵。我见过不少同学一上来就猛写 Mock 配置,结果跟后端联调时发现字段结构全对不上,那叫一个痛苦。说白了,高质量 Mock 的前提,是高质量的真实数据样本。
今天我们就聊聊,怎么用抓包工具把 SystemUI 的真实接口交互给“录”下来。
4.1 先选一把趁手的“枪”
抓包工具圈子里,主流就这么几把:
| 工具 | 平台 | 适合场景 | 我个人的偏好 |
|---|---|---|---|
| Charles | macOS / Windows | 常规 HTTP/HTTPS、接口断点、Rewrite | 日常开发主力 |
| Fiddler Everywhere | 跨平台 | 团队协作、脚本扩展 | 需要分享配置时用 |
| mitmproxy | 跨平台 CLI | 自动化流程、持续集成 | 管线化录制首选 |
| Wireshark | 跨平台 | 底层 TCP / TLS 分析 | 定位网络层问题时才用 |
我个人习惯把 Charles 当主力,原因很简单——它在 macOS 上的稳定性真的好,而且会话管理能力特别强。不过你要是更熟悉 Fiddler,也没问题,核心逻辑都是相通的。
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 / 太极 等方案
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 的状态查询接口
- 快速设置面板加载时的数据请求
- 点击快捷开关后的控制指令接口
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 录制流程总览
下面这张图,把整个抓包录制流程串了起来。你跟着走一遍,基本不会漏步骤。
4.6 高质量录制的几个习惯
录得多了,你就会发现有些细节真能决定 Mock 回放的成败。
- 标记版本:每次录制后,都在 HAR 文件名的备注里写明系统版本、SystemUI 版本、录制时间。我见过最坑的事,就是用了一个月前的旧数据写 Mock,结果接口结构早变了。
- 录制完整序列:不要只录单次请求。比如下拉状态栏,录下从点击到完全展开的整个过程的请求序列,这样才能还原出真实的时序依赖。
- 检查静态资源:有些接口返回的不是 JSON,而是图片、字体或国际化字符串。这些也要一并保存,否则 Mock 回放时样式会崩。
好了,接口抓取这部分差不多就这些。你拿到原始数据之后,下一件事就是把它整理成结构化的 Mock 配置。不过那就是另一个话题了,咱们先把这步走扎实。