混合应用WebView中HTML5视频硬件加速配置

# HTML5视频在混合应用WebView中的硬件加速配置 坦白说，在混合应用开发中，HTML5视频播放卡顿几乎是必踩的坑——默认设置下，硬件加速压根儿没启用，结果就是发热、掉帧、电量嗖嗖往下掉。问题的关键，其实就两件事：一是把WebView的渲染策略调对，二是把video标签的属性配齐。而且，Android和iOS各有各的脾气。 ## Android WebView硬件加速开关 Android从4.0开始默认就开启了硬件加速，但实际开发中，你得确认应用级别和WebView实例级别都真正启用，不能光指望默认值： - 在 `AndroidManifest.xml` 中，给对应的 Activity 显式加上 `android:hardwareAccelerated="true"`——全局虽然默认为 true，但显式声明更稳妥，少踩很多暗坑。 - 如果用了自定义 WebView，千万别手滑调用 `setLayerType(LAYER_TYPE_SOFTWARE, null)`，这玩意儿会直接把图层切成软件渲染，加速就废了。 - Android 7.0 以上，可以额外启用 SurfaceView 后端来提升视频性能：创建 WebView 之后调用 `webView.setVideoSurfaceViewEnabled(true)`（需要 API 26+，部分厂商定制系统可能不支持）。这个不是必选项，但开了之后帧率确实更稳。 ## WebView中video标签的关键属性设置 光开硬件加速远远不够——video 元素本身也得配合特定的属性，才能顺利走上 GPU 渲染的路径： - **playsinline** 是必加的。iOS 的 WKWebView 强制要求它，Android 的 Chrome 内核也依赖它才能启用内联硬件解码。没有这个属性，很多场景下硬解压根儿不走。 - 建议顺手加上 **webkit-playsinline** 和 **x5-playsinline**，主要是为了兼容微信等平台的 X5 内核——别问为什么，踩过坑的人都知道。 - 使用 `controls` 属性时，要避免叠加过多的自定义 DOM 控件。复杂 overlay 很容易触发软件合成，导致 GPU 加速白费。要么用原生控件，要么把 CSS 变换精简到极致。 - 设置 `preload="auto"`，再配合 `autoplay`（但注意，autoplay 需要用户手势触发后才真正生效），可以提前建立 GPU 解码上下文，减少播放时的启动延迟。 ## iOS WKWebView的特殊处理 iOS 对 video 硬件加速的控制比 Android 严格得多，而且默认会强制全屏播放。要想让它乖乖内联播放，得做针对性配置： - 在 `WKWebViewConfiguration` 中，把 `mediaTypesRequiringUserActionForPlayback` 设为 `[]`，允许自动播放音频和视频。这个是前提。 - HTML 中的 video 标签必须包含：**playsinline**、**webkit-playsinline**、**muted**。注意，muted 是 iOS 自动播放的硬性前提，不静音就不让播。 - 确认 `allowsInlineMediaPlayback` 为 `true`——如果设为 `false`，还是会跳转全屏，内联播放白配。 - 有个容易踩的坑：不要对 video 元素使用 `transform: translateZ(0)` 或 `will-change`。iOS 15 以上，这两个属性可能导致解码器降级回 CPU，反而更卡。 ## 调试与验证方法 配置做没做对，不能光靠感觉，得实际验证： - **Android**：打开 Chrome DevTools，远程调试 WebView，在 Rendering 面板勾选 “FPS meter”，播放时观察是否稳定在 60fps。同时去 Layers 面板里检查 video 是不是独立的 GPU Layer——不是的话说明硬件加速没跑通。 - **iOS**：用 Xcode → Debug → View Debugging → Rendering，显示 “Color Composited Layers”。video 区域应该是绿色（GPU 合成），如果是红色（CPU 合成），那就是配置有问题。 - **通用方法**：监听 `video.webkitDecodedFrameCount`（iOS）或 `video.getVideoPlaybackQuality()`（Android Chrome），如果数值持续增长，说明解码正常在工作。