深入原生交互：提升Web应用性能与用户体验的核心技术

在 WebView 中调用原生方法时遇到的 JavaScript 与 Android 通信失效问题

上个月，我在开发一个混合 App 的新功能，前端用的是 Vue3 + Vite，打包后通过 Android 的 WebView 加载。这个功能需要在用户点击某个按钮时，调用原生的分享能力，把当前页面的链接分享到微信或朋友圈。按照之前的方案，我们是通过 window.Android 对象暴露原生方法给前端调用的。项目之前跑得好好的，但这次新功能上线前测试时，却发现点击分享按钮完全没反应，连最基本的 Toast 都没弹出来。我一开始以为是新页面的 JS 没加载完，结果反复刷新、清理缓存都没用，折腾了一下午才意识到问题没那么简单。

问题表现：JS 调用原生方法无响应

具体表现是：在 WebView 中打开 H5 页面后，点击「分享」按钮，控制台没有任何报错，但原生那边完全没收到调用。我加了日志打印，发现 Android.share() 这行代码执行了，但 Android 的 share 方法根本没被触发。更奇怪的是，在同一个 App 的其他页面（比如首页）调用同样的 Android.share() 却能正常工作。我一度怀疑是不是新页面的 JS 作用域有问题，或者 WebView 的配置被改了。另外，我还试过在 Chrome DevTools 的 Console 里手动输入 window.Android，结果返回的是 undefined —— 这说明原生对象根本没有注入成功。但在旧页面里，同样的操作却能正确返回一个包含 share、getUserInfo 等方法的对象。

排查过程：从配置到注入时机的层层验证

我先检查了 Android 端的 WebView 配置，确认 addJavascriptInterface 是在主线程中调用的，并且传入的对象没有被混淆（ProGuard 规则也加了）。然后我对比了新旧页面的加载方式，发现旧页面是直接通过 loadUrl("file:///android_asset/...") 加载本地 HTML，而新页面是通过 loadUrl("https://xxx.com/page") 加载远程地址。这让我想到：是不是因为跨域或者 HTTPS 的原因导致 JS 接口没注入？

接着，我尝试在 Android 的 WebViewClient 的 onPageFinished 回调里重新注入接口，结果还是不行。我又怀疑是不是 JS 执行太快，原生对象还没准备好，于是加了个 setTimeout 延迟调用，依然无效。最让我崩溃的是，我甚至把整个 WebView 初始化代码复制到一个新 Activity 里单独测试，加载同一个远程 URL，结果又能正常调用 —— 说明问题出在主 App 的上下文环境里。

最后，我注意到主 App 的 WebView 是在一个 Fragment 里复用的，而新页面是通过路由跳转进来的。会不会是 WebView 被复用后，某些状态没重置？于是我打印了 WebView 的 ID 和实例地址，发现确实是同一个实例。但为什么旧页面能用，新页面不能？我突然想到：会不会是 Android 的 addJavascriptInterface 只在首次加载时生效，后续页面跳转（即使是同域）不会自动重新注入？

解决方案：确保每次页面加载都重新注入 JS 接口

经过反复测试，我确认问题根源在于：当 WebView 加载远程页面并进行内部跳转（比如通过 Vue Router 的 history 模式）时，Android 不会自动重新注入 JavaScript 接口。而旧页面之所以能用，是因为它每次都是全新加载（通过 loadUrl），而新页面是在同一个 WebView 实例里通过前端路由切换的，页面地址变了，但 WebView 并不知道需要重新绑定原生对象。

解决办法很简单：在 WebView 的 shouldOverrideUrlLoading 或 onPageStarted 中，每次页面加载（包括前端路由跳转）都重新调用 addJavascriptInterface。但要注意，不能频繁重复添加，否则会造成内存泄漏或方法重复注册。所以我在 Android 端做了一个小优化：只在页面 URL 匹配特定规则时才注入，并且先移除旧的接口再添加新的。

以下是最终的 Android Java 代码：

public class MainActivity extends AppCompatActivity {
    private WebView webView;
    private MyJavaScriptInterface jsInterface;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        webView = findViewById(R.id.webview);
        webView.getSettings().setJavaScriptEnabled(true);
        webView.setWebViewClient(new WebViewClient() {
            @Override
            public void onPageStarted(WebView view, String url, Bitmap favicon) {
                // 每次页面开始加载时，重新注入 JS 接口
                injectJavaScriptInterface(view, url);
                super.onPageStarted(view, url, favicon);
            }
        });

        // 初始加载页面
        webView.loadUrl("https://your-app.com/");
    }

    private void injectJavaScriptInterface(WebView view, String url) {
        // 如果是我们的业务域名，才注入接口
        if (url != null && url.startsWith("https://your-app.com/")) {
            // 先移除旧的接口（避免重复）
            view.removeJavascriptInterface("Android");
            // 创建新的接口实例
            jsInterface = new MyJavaScriptInterface(this);
            view.addJavascriptInterface(jsInterface, "Android");
        }
    }

    public static class MyJavaScriptInterface {
        private Context context;

        MyJavaScriptInterface(Context context) {
            this.context = context;
        }

        @JavascriptInterface
        public void share(String title, String content, String url) {
            // 原生分享逻辑
            Intent sendIntent = new Intent();
            sendIntent.setAction(Intent.ACTION_SEND);
            sendIntent.putExtra(Intent.EXTRA_TEXT, content + " " + url);
            sendIntent.setType("text/plain");
            context.startActivity(Intent.createChooser(sendIntent, "分享到"));
        }
    }
}

前端调用方式保持不变：

function handleShare() {
  if (window.Android && typeof window.Android.share === 'function') {
    window.Android.share('页面标题', '分享内容', window.location.href);
  } else {
    console.warn('原生分享接口未就绪');
  }
}

原因分析：WebView 的 JS 接口绑定是页面级的

根本原因在于 Android 的 addJavascriptInterface 方法绑定的是当前 WebView 的 JavaScript 上下文，而这个上下文在页面跳转（尤其是单页应用的前端路由跳转）时并不会自动重置或更新。当 WebView 加载一个新页面（即使是同域的不同路径），如果这个跳转是由前端 JavaScript 触发的（如 history.pushState），WebView 并不会触发完整的页面加载流程，因此也不会重新注入接口。而直接调用 loadUrl 会触发完整的页面生命周期，所以旧页面能正常工作。这就导致了在 SPA 应用中，只有首次加载的页面能访问原生接口，后续路由跳转后的页面就“断联”了。

经验总结：混合开发中 WebView 与原生交互的几个坑

这次踩坑让我总结了几点经验，希望能帮到后来人：

• 不要假设 JS 接口会自动持久化：在 WebView 中，每次页面跳转（尤其是 SPA 路由）都可能需要重新注入原生接口。
• 注入时机要选对：推荐在 onPageStarted 而不是 onPageFinished 注入，因为 JS 可能在页面加载早期就需要调用原生方法。
• 记得移除旧接口：重复调用 addJavascriptInterface 会导致内存泄漏，务必先 removeJavascriptInterface。
• 做好兜底判断：前端调用前一定要检查 window.Android 是否存在，避免白屏或静默失败。
• 测试要覆盖路由场景：不要只测首页，要模拟真实的用户路径，包括多次跳转后再调用原生功能。

说到底，混合开发的坑往往不在技术本身，而在于对平台机制理解不够深。下次再遇到类似问题，我一定会先问自己：这个接口是在什么时机绑定的？页面跳转后它还在吗？