PWA与原生App共存不必然拖慢性能，关键在于避免资源争抢和桥接逻辑错误：Service Worker运行于浏览器独立线程，与原生进程隔离；但WebView初始化叠加PWA启动、桥接调用阻塞、缓存策略冲突或状态同步不当，易引发首屏变慢、导航卡顿、离线失效等问题。
<PWA 本身不会拖慢原生 App，但两者共存时若设计不当，可能因资源争抢或桥接逻辑错误引发性能问题。关键不在“PWA 是否慢”，而在“如何让它们不互相干扰”。
Service Worker 和原生后台进程会冲突吗
Service Worker 运行在浏览器独立线程中，与原生 App 的进程完全隔离——Android 上 WebView 内的 SW 不会占用主 App 的主线程，iOS 上 WKWebView 里的 SW 也受限于 WebKit 沙盒。但问题常出在「桥接层」：
- 若原生端通过 evaluateJavaScript 频繁调用 PWA 页面中的 heavy JS 函数（如解析 10MB JSON），会阻塞 WebView 渲染线程
- Android 的 WebSettings.setCacheMode() 若设为 LOAD_CACHE_ELSE_NETWORK，而 PWA 又在 SW 中主动缓存同一批资源，可能造成磁盘 I/O 竞争
- iOS 上若原生代码调用 WKWebView.reload() 同时 PWA 正在执行 caches.delete()，偶发触发 WebKit 内部资源锁死，表现为白屏 2–3 秒
建议统一资源调度权：原生端只负责网络状态监听和权限代理，缓存策略全交给 Service Worker；避免在 onMessage 回调里做同步计算。
WebView 加载 PWA 页面时首屏变慢怎么查
这不是 PWA 本身的问题，而是 WebView 初始化 + PWA 启动双重开销叠加的结果。常见诱因有：
- manifest.json 中 start_url 指向了带大量查询参数的页面（如 /?utm_source=app），导致 SW 的 fetch 事件监听器反复匹配失败，回退到网络请求
- Android WebViewAssetLoader 未启用，仍用 file:///android_asset/ 加载，而 PWA 的 sw.js 又尝试 fetch 同目录下资源，触发跨域预检（即使本地文件）
- iOS 的 WKWebView 默认禁用 localStorage 在 file:// 协议下工作，但 PWA 的初始化逻辑依赖它，导致 JS 报错并重试三次
验证方法：在 WebView 加载后立即执行 console.log(navigator.serviceWorker.controller?.state)，若输出 undefined 或 redundant，说明注册失败，需检查 HTTPS 要求是否被绕过、路径是否写错（sw.js 必须与页面同源且可直连）。
原生跳转 PWA 页面时导航卡顿怎么办
这是最易被忽略的协同点。原生侧调用 loadUrl("https://app.example.com/home") 后，若 PWA 页面内使用 history.pushState 配合动画过渡，而原生又监听了 shouldOverrideUrlLoading 并做同步拦截处理，就会形成循环等待。
- Android：不要在 WebViewClient.shouldOverrideUrlLoading 里直接调用 webView.loadUrl()，改用 post(() -> webView.loadUrl(...)) 异步化
- iOS：避免在 navigationDelegate.decidePolicyFor 中对 PWA 的内部路由（如 #settings）返回 .cancel，应放行给 WKWebView 自身处理
- 共同原则：PWA 的路由系统（如 Vue Router / React Router）必须设置 scrollBehavior: 'auto'，否则原生跳转后页面滚动位置异常，用户感知为“卡住”
另外，manifest.json 中的 display: "standalone" 在 WebView 中无效，强行设置会导致 Android 上状态栏闪动，建议原生侧通过 setSystemUiVisibility 控制沉浸式模式，PWA 侧只管内容布局。
立即学习“前端免费学习笔记（深入）”；
离线状态下原生和 PWA 缓存谁优先
没有“谁优先”，只有“谁生效”。两者的缓存机制物理隔离：
- 原生层可用 OkHttp Cache 或 NSCache 缓存 API 响应，但无法拦截 PWA 的 fetch 请求
- Service Worker 的 caches.match() 只对经过它的网络请求起作用，原生发起的 HTTP 请求完全绕过它
- 真正的协同点在数据层：若原生把用户登录态存在 SharedPreferences / UserDefaults，PWA 就必须通过原生桥接（如 getAuthHeader()）读取，不能依赖 localStorage —— 后者在 PWA 离线时可能为空，而原生缓存仍是最新
一个典型翻车场景：PWA 页面加载时先从 localStorage 取 token，失败后再调原生桥接；但原生桥接函数未加超时，离线时阻塞 JS 主线程长达 8 秒。解决方式是桥接调用必须带 timeout 参数，并默认 fallback 到空值而非死等。
PWA 和原生 App 是两条平行线，强行让它们“共享状态”反而最容易出问题。真正稳定的配合方式，是把原生当能力网关、PWA 当界面引擎，接口契约比代码复用更重要。
