先明确一个现实，混合 App 并不是原生 + Web 各测各的就结束了。
常见的复杂点包括：
- WebView 生命周期和原生页面不同步
- JS Bridge 调用频繁，但日志分散
- 页面跳转涉及原生路由和前端路由
- 性能问题可能出现在 Web 线程，也可能是原生渲染
如果测试只停留在点功能是否正常，这些问题往往要到线上才暴露。
开发阶段先把实际运行过程看清楚
在开发和联调阶段，我会优先做一件事让 App 在真实设备上跑起来，同时能看到实际运行过程和状态变化。
设备连接与基础准备
- 用 USB 或 Wi-Fi 连接 iPhone / iPad
- 启动混合 App，确保能正常加载 H5 页面
- 关闭多余后台应用，减少干扰
此时我会同时打开两类工具：一个看发生了什么，一个看发生时设备状态如何。
Web 调试之外，还需要设备视角
前端同事通常会用 Chrome DevTools 或 Safari Web Inspector 调试 H5，这没问题，但它只能看到 Web 世界。
在测试混合 App 时，我会额外打开 克魔（KeyMob），主要做三件事：
- 持续查看 CPU / 内存变化
- 观察 WebView 页面切换时的资源波动
- 对照原生日志和 JS 行为时间点
操作上很简单：
- 打开克魔，连接设备
- 进入【性能图表】
- 勾选 CPU、内存、FPS
- 选择系统进程 + 当前 App
- 点击开始后不再频繁中断
这样在切换 H5 页面、触发 JS Bridge 调用时，资源变化是连续可见的。
一个常见问题，H5 返回时卡顿
有一次测试中，App 的 H5 页面返回原生列表时偶发卡顿。
从前端看，路由销毁是正常的，从原生代码看，控制器也已经释放。
真正发现问题，是在克魔里看到一个细节，每次返回时，内存都会抬高一点，但不会完全回落。
接下来我做了几步：
- 重复进入 / 返回同一 H5 页面
- 对照实时日志，看 JS Bridge 是否重复注册
- 再用 Xcode 的 Allocations 定位未释放对象
最终发现是 WebView 内部缓存策略的问题，而不是前端代码逻辑。
日志：混合场景下尤其重要
混合 App 的日志往往分散在三处：
- 原生 NSLog
- JS console
- 第三方 SDK 输出
在测试阶段，我会尽量把原生日志集中起来看。
通过克魔的【实时日志】功能，可以：
- 指定 App 查看日志
- 过滤关键词（如 bridge、webview）
- 在非 Xcode 环境下观察输出
尤其在测试包、灰度包阶段，这一点很有用。
不同工具各司其职，而不是“替代”
一套比较稳定的混合 App 测试组合，大致会是：
- Web Inspector / Chrome DevTools：验证 H5 行为
- 克魔：观察设备资源、原生日志、进程状态
- Xcode / Instruments：针对已确认问题深入分析
- 抓包工具：排查接口与资源加载
关键在于什么时候用哪个工具。
混合 App 测试的一点经验
混合开发的问题往往是渐进式的，只有在持续观察下，异常才会变得清晰。
