如果只做过纯 Native 或纯 Flutter 项目，很容易低估混合开发 App 的测试复杂度。
但只要项目里同时存在 Native 页面、WebView、Flutter 或其他跨端方案，测试这件事就会迅速变得不那么“干净”。

我第一次明显感受到这一点，是在一个 iOS 项目里：
部分核心页面是 Native，活动页用 H5，另一些模块是 Flutter。
功能测试能过，但问题总是在一些“说不清楚”的场景里冒出来。

混合开发的问题，很少只属于某一层

测试反馈往往是这样的：

  • 页面偶发白屏
  • 某些设备上明显卡顿
  • 返回上一级时短暂无响应
  • 用久了之后整体变慢

当你去问“是 Native 的问题还是 Web 的问题”，
很多时候，答案是：都不是单独一边的问题。

只用某一种测试方式，结论往往不完整

最早我们还是按老习惯来测试：

  • Xcode 跑功能
  • Instruments 看性能
  • Safari Inspector 看 H5

每个工具都能看到一些东西，但总感觉拼不成一条完整的线。

比如：

  • Safari Inspector 显示 JS 正常
  • Native 内存看起来也不高
  • 但实际体验就是越来越卡

这类问题，如果不把不同层的行为放在一起看，很难解释。

混合 App 测试，第一步是“统一视角”

后来我意识到，混合开发的 App 在 iOS 上，最终都要接受系统调度。
不管页面是 Native、Web 还是 Flutter，它们的 CPU、内存、线程、能耗，最终都会体现在同一个进程里。

从这个角度看，把 App 当成一个整体来测试，反而更有意义。

从 Instruments 开始，但不要停在这里

Instruments 仍然是一个非常重要的工具。

通过 Time Profiler，可以看到：

  • 渲染压力集中在哪一段
  • WebKit 线程何时活跃
  • Flutter Engine 是否频繁调度

这些信息能帮你判断“压力来源在哪里”，
但它不太适合回答“问题什么时候开始出现”。

当问题是“跑久了才有”，测试方式就得变

在一个版本回归中，我们发现：

  • 第一次进入混合页面一切正常
  • 多次切换后开始掉帧
  • 再回到 Native 页面，响应也变慢

这个现象，用 Instruments 很难一次性抓住。

于是我开始在真机上跑完整使用流程，并引入 克魔（KeyMob） 做持续观察。

KeyMob 在混合 App 测试里的作用

我并没有把 KeyMob 当成“某一层的工具”，而是把它当成一个观察窗口：

  • 看 CPU、内存是否随着页面切换逐步上升
  • 看 FPS 在混合页面前后是否发生变化
  • 看网络、日志是否在后台持续活跃

当你把 Native、WebView、Flutter 页面来回切换跑一遍，再回头看这些数据，很多问题会变得非常直观。

Web 层的测试，不能只看 Web 层

在混合项目中，Web 页面经常被单独测试。
但在 App 里运行时，它的行为会受到更多限制。

我一般会同时使用：

  • Safari Inspector：确认 JS 行为、定时任务、资源加载
  • KeyMob：观察 Web 页面前后整体内存与 CPU 变化

在一次排查中，我们发现 Web 页面本身没有明显问题，但在退出后短时间内仍然占用资源，导致后续 Native 页面受影响。

网络问题，往往在混合场景下被放大

通过 Charles 抓包，可以看到一些在功能测试中不明显的情况：

  • 某些接口在 H5 页面和 Native 页面都会调用
  • 切换页面时请求被重复触发
  • 弱网下重试逻辑叠加

这些行为单独看并不严重，但放在混合场景中，就容易变成性能问题。

混合 App 测试，本质是跨层对照

慢慢地，我形成了一种比较稳定的测试方式：

  • 用 Instruments 看压力来源
  • 用 Safari Inspector 理解 Web 行为
  • 用 Charles 对照网络
  • 用 KeyMob 把所有行为放在同一条时间线上看

这样做的好处是：
你不需要一开始就判断“是哪一层的问题”，而是让数据自己说明问题