书呆子

我这边destory webview关联的activity也无法重现你的异常。不过从你的异常日志上看来，应该不是webview已经被回收的问题。因为如果是那样，会直接在android.webkit.WebView.loadUrl这里报空指针。另外每个JsCallback中强引用了相关联的WebView，即使activity退出销毁后也能正常执行回调JS，但如果回调的js涉及更新UI，则会有下面的异常。 ``` 11-27 10:46:45.992 22168-22168/cn.pedant.SafeWebViewBridge.sample E/Web Console﹕ Uncaught HostApp call error, code:500, message:method execute error:Unable to add window -- token android.os.BinderProxy@416894a0 is not valid; is your activity running? at...

提交 https://github.com/pedant/safe-java-js-webview-bridge/commit/23fed5db320020dd43ed7adebaf2611222a58a31

已部署 ``` repositories { mavenCentral() } dependencies { compile 'cn.pedant.safewebviewbridge:library:1.4' } ```

首先表明立场，不建议在shouldOverrideUrlLoading上去做层协议来发起js调用，暂时能想到的原因有： - 试想一下页面端如果要任何时候发起调用，都必须"模拟"一个链接跳转事件而java端才能收到通知。这样的模拟在页面端比较耗时（我曾经做webapp时尝试过）。 - 另外，页面端一般是同步调用执行java方法，执行完成后有时需要返回各个类型的结果，而在shouldOverrideUrlLoading中不能做到多种类型的结果的【同步】返回。 - 还有种情况，假设页面存在一个正常链接在需要点击完成reload的同时又需要调用java方法怎么办，这两处都会执行都会跑到shouldOverrideUrlLoading中来，使其内部又掺杂业务又掺杂js调用框架，本质上更复杂难以维护。 综合上面对比下safe-java-js-webview-bridge原理就知道优势了。 欢迎探讨补充。。。

Won't be considered, it is limited to alert program state, like ready-only.But you can download the library source and modify layout xml for your product.