给 Tauri（WKWebView）应用解锁 ProMotion 120Hz——从 rAF 恒定 60 到 swizzle 的排除法诊断

现象#

WKWebView 默认会把页面渲染更新的节奏（rAF 回调、style/layout 的推进）钳在 ~60fps 省电。注意它钳的是”页面渲染更新”这一路：

• 合成器动画（transform、opacity 这类能上 GPU 合成线程的）不受影响，能跑满刷新率
• 一切 JS 驱动的渲染——rAF 回调、打字机效果、canvas 逐帧重绘、我这个 HUD 心跳——被锁 60

所以现象很割裂：页面滚动、CSS 过渡都很顺，只有你自己用 rAF 测出来的数字是 60。第一反应很容易误判成”HUD 采样写错了”，但换几种测法（performance.now() 差值、掉帧计数）结论一致——就是 rAF 本身每秒只被叫 60 次。

怎么定位到的#

1
[webView _setPreferPageRenderingUpdatesNear60FPS:NO];

1
if (![webView respondsToSelector:@selector(_setPreferPageRenderingUpdatesNear60FPS:)]) {
2
    // ← 走到了这里，这个 selector 不存在了
3
}

1
// 枚举 WKPreferences 的所有 experimental features，捞和刷新率相关的 key
2
NSArray *features = [(id)[WKPreferences class] performSelector:
3
                     NSSelectorFromString(@"_experimentalFeatures")];
4
for (id f in features) {
5
    NSString *key = [f performSelector:NSSelectorFromString(@"key")];
6
    NSString *l = key.lowercaseString;
7
    if ([l containsString:@"fps"]   || [l containsString:@"refresh"] ||
8
        [key containsString:@"60"]  || [l containsString:@"promotion"])
9
        printf("feature: %s\n", key.UTF8String);
10
}

1
NSString *html = @"<script>"
2
  "let f=0,s=0;"
3
  "function loop(t){"
4
  "  if(!s)s=t; f++;"
5
  "  if(t-s>=2000)"                       // 累计 2 秒
6
  "    window.webkit.messageHandlers.report.postMessage((f/((t-s)/1000)).toFixed(1));"
7
  "  else requestAnimationFrame(loop);"
8
  "} requestAnimationFrame(loop);"
9
"</script>";

1
NSArray *features = [(id)[WKPreferences class] performSelector:
2
                     NSSelectorFromString(@"_experimentalFeatures")];
3
for (id f in features) {
4
    NSString *key = [f performSelector:NSSelectorFromString(@"key")];
5
    if ([key isEqualToString:@"PreferPageRenderingUpdatesNear60FPSEnabled"]) {
6
        // 关掉这个"倾向于 60fps"的 feature
7
        ((void (*)(id, SEL, BOOL, id))objc_msgSend)(config.preferences,
8
            NSSelectorFromString(@"_setEnabled:forFeature:"), NO, f);
9
    }
10
}

根因#

把能确定的和推测的分开说。

能确定的事实（实验直接证明）：

1. _setPreferPageRenderingUpdatesNear60FPS: 在 macOS 26 上已移除（respondsToSelector: 返回 false）。
2. 它的功能以 experimental feature PreferPageRenderingUpdatesNear60FPSEnabled 的形态存在。
3. 这个 feature 仅在 WKWebView 创建时刻从 configuration.preferences 读取——创建前设生效（110.2fps），创建后运行时设 / reload / NSUserDefaults 覆盖全部无效（仍 60）。

我没有验证的部分：为什么 WebKit 默认要开这个”倾向 60fps”、为什么它只在创建时读一次——这是 WebKit 内部实现，我没读源码。合理的猜测是省电（120Hz 意味着渲染管线的功耗和发热都翻倍，对多数网页不值），以及创建时读一次是因为这个 preference 参与了渲染管线的初始化、之后管线定型就不再重配。但这些是推断，修复方案不依赖它们成不成立——我只依赖”创建时刻是唯一窗口”这个实验事实。

修复：为什么 Tauri 里得靠 swizzle#

到这一步，原生 AppKit 应用其实已经解决了：自己 new configuration，创建 WebView 前调一下就行。

问题是 Tauri / wry 不把 WKWebViewConfiguration 暴露给你。WebView 是 wry 内部创建的，等 with_webview 之类的钩子能拿到 WKWebView 时，它早就 init 完了——而上面刚证明，init 之后这个窗口就永久关闭了。Tauri 给的所有钩子都在”创建之后”，全都太晚。

唯一能插进”创建那一刻”的办法：method swizzling——把 WKWebView 的指定初始化器 -initWithFrame:configuration: 换成自己的实现，在里面先对传入的 configuration 关掉 feature，再调原始 init。谁创建 WebView 都拦得到，包括 wry。

核心就这么点：

1
static IMP g_orig_init = NULL;
2

3
// 被 swizzle 进去的 init：先动 configuration，再走原始逻辑
4
static id swizzled_init(id self, SEL _cmd, CGRect frame, WKWebViewConfiguration *config) {
5
    if (config) disable_sixty_clamp(config);              // 创建瞬间关掉 feature
6
    return ((id (*)(id, SEL, CGRect, id))g_orig_init)(self, _cmd, frame, config);
7
}
8

9
void install_high_refresh_unlock(void) {
10
    if (g_orig_init) return;                              // 幂等
11
    Method m = class_getInstanceMethod([WKWebView class],
12
                                       @selector(initWithFrame:configuration:));
13
    if (!m) return;
14
    g_orig_init = method_getImplementation(m);
15
    method_setImplementation(m, (IMP)swizzled_init);      // 换掉 IMP
16
}

disable_sixty_clamp 就是前面那段遍历 features、_setEnabled:NO 的逻辑。swizzle 之后再跑那把 rAF 尺子：112.3 fps。和”原生创建前设”的 110.2 一致，确认 swizzle 拦截等价于在源头改。

1
// build.rs：把 ObjC swizzle 编译进来，链接 WebKit
2
#[cfg(target_os = "macos")]
3
{
4
    cc::Build::new()
5
        .file("src/native/high_refresh.m")
6
        .flag("-fobjc-arc")
7
        .compile("high_refresh");
8
    println!("cargo:rustc-link-lib=framework=WebKit");
9
}

1
// lib.rs：run() 第一件事就装 swizzle，早于 tauri::Builder
2
pub fn run() {
3
    #[cfg(target_os = "macos")]
4
    unsafe { install_high_refresh_unlock(); }   // ← 先于任何 WKWebView 创建
5

6
    tauri::Builder::default()
7
        // ... 后面才轮到窗口/WebView 被创建
8
}

1
static void disable_sixty_clamp(WKWebViewConfiguration *config) {
2
    SEL featuresSel = NSSelectorFromString(@"_experimentalFeatures");
3
    if (![WKPreferences respondsToSelector:featuresSel]) return;      // 机制没了 → 放弃
4
    NSArray *features = [(id)[WKPreferences class] performSelector:featuresSel];
5
    SEL setSel = NSSelectorFromString(@"_setEnabled:forFeature:");
6
    if (![config.preferences respondsToSelector:setSel]) return;      // 方法没了 → 放弃
7
    for (id f in features) {
8
        NSString *key = [f performSelector:NSSelectorFromString(@"key")];
9
        if ([key isEqualToString:@"PreferPageRenderingUpdatesNear60FPSEnabled"]) {
10
            ((void (*)(id, SEL, BOOL, id))objc_msgSend)(config.preferences, setSel, NO, f);
11
            return;
12
        }
13
    }
14
    // key 没匹配上 → 什么都不做，安静退回 60fps
15
}

两个必须知道的坑#

解锁完不代表万事大吉，有两件事不写下来一定会被坑（或者坑到别人）。

几条能带走的经验#

• 私有 API 会换马甲，不会凭空消失。 一个下划线 SPI 在新系统 respondsToSelector: 返回 false，先别断定功能没了——大概率被收编进了 _experimentalFeatures / _internalDebugFeatures 之类的 feature flag。用 runtime 枚举方法列表和 feature key，按关键词捞，比翻过时教程快得多。
• “设了不生效”要区分是没权限还是没赶上时机。 这次四种写法里三种失败，不是 API 用错，而是读取窗口只有创建那一刻。判断一个配置项的生效时机，最干脆的办法就是像这样跑对照实验：创建前 / 创建后 / reload 后 / 进程级覆盖各测一遍，哪个成哪个不成，时机窗口自己就显形了。
• 拿不到创建钩子时，swizzle 初始化器是通用兜底。 框架（wry、各种 WebView 封装）把创建过程藏起来、只给你”创建之后”的对象时，如果你的需求恰好卡在创建瞬间，swizzle 指定初始化器是能插进那个窗口的少数手段之一。代价是依赖私有实现，所以——
• 靠私有 API 的功能，失效路径必须是”优雅降级”而不是崩溃。 每一步 respondsToSelector: / key 匹配都要有 else 分支，匹配不上就安静退回原行为。这条是私有 API 能不能进生产版的分界线。
• 帧率类指标先确认物理上限再下结论。 多屏、混合刷新率环境下，rAF 帧率跟随窗口所在屏幕。看到 60 先问”这块屏是不是就 60Hz”，再问”是不是没解锁”。