帧预算只有 16 毫秒
在 60 Hz 屏幕上，浏览器约有 16 毫秒 去跑 JS、算样式、布局并绘制每一帧。错过它，帧就被丢掉——动画抽搐、列表顿挫、点击感觉迟钝。Web Almanac 与 web.dev 反复指出，移动端主线程才是瓶颈：超过 50 毫秒 的任务即「长任务」（W3C Long Tasks API），会阻塞输入并直接伤害 INP（Interaction to Next Paint，2024 年 3 月起成为核心 Web 指标，「良好」门槛低于 200 毫秒）。在手机上，处理一次滚动或输入事件可能耗时数百毫秒，期间动画完全停滞。这被称为卡顿（jank）。
WebView 把所有事压在一条线程
WebView 按浏览器的方式渲染页面：单个主线程同时承担 JS、样式、布局与绘制。一段由脚本驱动的动画——哪怕只是简单的 setData 式更新——也必须跨过「逻辑层 → 渲染层」的序列化桥：逻辑先跑、JSON 序列化、Native 转发、渲染端反序列化、绘制，最后才出帧。在低端机上，这一来一回轻松超过 16 毫秒，这正是指尖拖拽与滚动动画「跟不上手」的根源。架构有硬天花板：主线程同一时刻只能做「跑 JS / 布局 / 绘制」中的一件。
Skyline 把动画跑在渲染线程
微信的 Skyline 渲染引擎（自研、基于 Skia、类 Flutter，自基础库 3.0.0 于 2023 年全面开放）把样式计算、布局、绘制与动画从 WebView 搬进原生渲染管线。决定性的改变是 worklet：动画与手势代码直接在渲染线程执行，读写共享值而无需跨线程序列化。没有桥的往返，动画便能以最高 120 fps 跟手，而非卡在 16 毫秒。原生组件——相机、地图、视频——与普通组件处于同一图层（无需别扭的 z-index 补丁），共享元素转场也是内置能力。
渲染器，决定天花板
这不是调优差异，而是结构性差异。WebView 页面可以用 CSS 动画、Web Worker 与精细分块来缓解卡顿，但它仍在和一条还得解析、编译、执行 JavaScript 的主线程搏斗。Skyline 把 WebView 彻底移出渲染路径，让渲染线程独享动画与手势。结果是低端硬件上可预期的帧节奏——而卡顿正是在这里最伤害获客。
逐项对比
| 维度 | H5 / WebView | 小程序（Skyline） |
|---|---|---|
| 渲染后端 | 系统 WebView（WKWebView / X5） | 自研 Skia 管线 |
| 动画线程 | 主线程（JS + 布局 + 绘制） | 渲染线程 via worklet |
| 跨线程成本 | 序列化 → Native → 反序列化 | 零（线程内共享值） |
| 帧天花板 | 超过 16 毫秒即掉帧 | 最高 120 fps，跟手 |
| 原生组件 | 图层补丁 / z-index | 同层，堆叠正确 |
| 共享元素动画 | 非原生 | 内置 |
| 手势系统 | 无原生竞争 | 声明式手势竞争 |
对你的 UI 意味着什么
若你的屏幕成败系于滚动手感、拖拽交互或共享元素转场——商铺、画廊、引导轮播——渲染路径就是产品本身。一个带原生渲染器的受管 runtime，从结构上给你这种流畅，尤其在占全球装机主体量的低端 Android 上。H5 仍是内容与原开放网络的正确工具；宿主内的交互界面，不该在不必要时卡顿。
Cross Mini App 的位置
Cross Mini App 是流畅渲染模型下的 runtime 与开放 catalog。你按标准 API 面构建小程序，它便在每一个嵌入的宿主里继承一条「动画与手势活在渲染线程」的渲染路径——而非一个与单主线程搏斗的 WebView。流畅是被设计进去的，不是祈祷来的。H5 讲故事，小程序让用户感受它。
