解决webview TOP瓦解Render process (7110)‘s crash wasn‘t handled by a
Render process (7110)'s crash wasn't handled by all associatedwebviews, triggering application crash. 瓦解错误如下Render process (7110)'s crash wasn't handled by all associatedwebviews, triggering application crash.
pid: 0, tid: 6625 >>> com.ssa.erw.basd <<<
backtrace:
#00pc 0x00000000066ebbb8/data/app/~~TiOrp6oxxcLg8dq23ARp9g==/com.google.android.trichromelibrary_666807033-96Vgpyd6PfGIV7uDuJ_zPA==/base.apk!libmonochrome_64.so (BuildId: 3a85f8990734d8d4cfc185bd88d9662091624cd1)
#01pc 0x0000000004046d04/data/app/~~TiOrp6oxxcLg8dq23ARp9g==/com.google.android.trichromelibrary_666807033-96Vgpyd6PfGIV7uDuJ_zPA==/base.apk!libmonochrome_64.so (BuildId: 3a85f8990734d8d4cfc185bd88d9662091624cd1)
#02pc 0x00000000066ebbe4/data/app/~~TiOrp6oxxcLg8dq23ARp9g==/com.google.android.trichromelibrary_666807033-96Vgpyd6PfGIV7uDuJ_zPA==/base.apk!libmonochrome_64.so (BuildId: 3a85f8990734d8d4cfc185bd88d9662091624cd1)
#03pc 0x0000000006b7c3d4/data/app/~~TiOrp6oxxcLg8dq23ARp9g==/com.google.android.trichromelibrary_666807033-96Vgpyd6PfGIV7uDuJ_zPA==/base.apk!libmonochrome_64.so (BuildId: 3a85f8990734d8d4cfc185bd88d9662091624cd1)
#04pc 0x00000000046c14f0/data/app/~~TiOrp6oxxcLg8dq23ARp9g==/com.google.android.trichromelibrary_666807033-96Vgpyd6PfGIV7uDuJ_zPA==/base.apk!libmonochrome_64.so (BuildId: 3a85f8990734d8d4cfc185bd88d9662091624cd1)
#05pc 0x000000000671a288/data/app/~~TiOrp6oxxcLg8dq23ARp9g==/com.google.android.trichromelibrary_666807033-96Vgpyd6PfGIV7uDuJ_zPA==/base.apk!libmonochrome_64.so (BuildId: 3a85f8990734d8d4cfc185bd88d9662091624cd1)
#06pc 0x0000000006734dd0/data/app/~~TiOrp6oxxcLg8dq23ARp9g==/com.google.android.trichromelibrary_666807033-96Vgpyd6PfGIV7uDuJ_zPA==/base.apk!libmonochrome_64.so (BuildId: 3a85f8990734d8d4cfc185bd88d9662091624cd1)
#07pc 0x0000000000018e8c/system/lib64/libutils.so (android::Looper::pollInner(int)+1276)
#08pc 0x000000000001892c/system/lib64/libutils.so (android::Looper::pollOnce(int, int*, int*, void**)+124)
#09pc 0x0000000000188dbc/system/lib64/libandroid_runtime.so (android::android_os_MessageQueue_nativePollOnce(_JNIEnv*, _jobject*, long, int)+44)
#10pc 0x00000000003883e0/data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (art_jni_trampoline+112)
#11pc 0x0000000000adb408/data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (android.os.MessageQueue.next+280)
#12pc 0x0000000000ad7e70/data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (android.os.Looper.loopOnce+96)
#13pc 0x0000000000ad7d68/data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (android.os.Looper.loop+1112)
#14pc 0x000000000082dc0c/data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (android.app.ActivityThread.main+2332)
#15pc 0x0000000000362a40/apex/com.android.art/lib64/libart.so (art_quick_invoke_static_stub+640)
#16pc 0x000000000035e42c/apex/com.android.art/lib64/libart.so (_jobject* art::InvokeMethod<(art::PointerSize)8>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jobject*, _jobject*, unsigned long)+732)
#17pc 0x00000000006c8b78/apex/com.android.art/lib64/libart.so (art::Method_invoke(_JNIEnv*, _jobject*, _jobject*, _jobjectArray*) (.__uniq.165753521025965369065708152063621506277)+32)
#18pc 0x000000000038e9c4/data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (art_jni_trampoline+116)
#19pc 0x0000000000e65234/data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run+132)
#20pc 0x0000000000e70ed4/data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (com.android.internal.os.ZygoteInit.main+3540)
#21pc 0x0000000000362a40/apex/com.android.art/lib64/libart.so (art_quick_invoke_static_stub+640)
#22pc 0x000000000034df38/apex/com.android.art/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+204)
#23pc 0x000000000034beec/apex/com.android.art/lib64/libart.so (art::JValue art::InvokeWithVarArgs<_jmethodID*>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jmethodID*, std::__va_list)+512)
#24pc 0x0000000000739bf4/apex/com.android.art/lib64/libart.so (art::JNI<true>::CallStaticVoidMethodV(_JNIEnv*, _jclass*, _jmethodID*, std::__va_list)+104)
#25pc 0x00000000000deca8/system/lib64/libandroid_runtime.so (_JNIEnv::CallStaticVoidMethod(_jclass*, _jmethodID*, ...)+104)
#26pc 0x00000000000eb5dc/system/lib64/libandroid_runtime.so (android::AndroidRuntime::start(char const*, android::Vector<android::String8> const&, bool)+860)
#27pc 0x000000000000256c/system/bin/app_process64 (main+1292)
#28pc 0x000000000008c5b8/apex/com.android.runtime/lib64/bionic/libc.so (__libc_init+104) 分析：此问题是webview渲染瓦解引起，假如发生了webview渲染瓦解，则会触发历程瓦解。
复现瓦解方式 webview.loadUrl("chrome://crash") 可以看到此瓦解发生。
参考谷歌 issure
https://issues.chromium.org/issues/40278434
https://github.com/mozilla-mobile/focus-android/issues/1630
可以知道，谷歌提供了一个方法回调onRenderProcessGone来处理渲染历程退出，默认是false，坑啊，false是会杀app历程退出。
https://i-blog.csdnimg.cn/direct/1e5a0aa36c41410e9c3f47e8968ace0a.png
我们来看看这个方法的注释翻译：
通知宿主应用程序给定的WebView的渲染历程已退出。多个WebView实例可能与单个渲染历程相干联；每个受影响的WebView都会调用onRenderProcessGone。应用程序对此回调的实现应仅尝试清理作为参数提供的特定WebView，而不应假设其他WebView实例受到影响。给定的WebView无法使用，应该从视图条理结构中删除，应该清除对它的所有引用，比方在Activity或使用android生存的其他类中的任何引用。视图。查看。findviewid和类似的调用等。为了测试渲染历程瓦解，应用程序可以在WebView上调用loadUrl("chrome://crash")。请注意，假如多个WebView实例共享一个渲染历程，则可能会受到影响，而不仅仅是加载chrome://瓦解的特定WebView。
参数：
view – 需要清理的 WebView。详细信息——退出原因。
退货：
假如宿主应用程序处理了历程已退出的情况，则为true，否则，假如出现历程瓦解，应用程序将瓦解，或者假如出现历程被体系杀死，应用程序将被杀死。
解决问题，根据注释的到场，重写webviewClient的方法，返回true。
<strong>@Override
public boolean onRenderProcessGone(android.webkit.WebView view, RenderProcessGoneDetail detail) {
return true;
}</strong> 假如想要更完善处理，可以在此类瓦解发生时，展示错误页面
@Override
public boolean onRenderProcessGone(android.webkit.WebView view, RenderProcessGoneDetail detail) {
view.clearCache(false);
view.clearHistory();
if (errorListener != null) {
errorListener.showErrorPage();
}
return true;
} 上线结果，APP瓦解率下降了70%，还是会瓦解上报。
反编译APK发现，有很多第三方SDK的webview也有这个问题，特别是广告SDK，那么想要彻底解决此问题，需要重写全部第三方SDK的代码，重写他们的webviewClient子类的onRenderProcessGone方法，强制返回true.
彻底清除这类瓦解，那么只有上ASM字节码插桩了，发现有继承的webviewClient的子类，然后强制改写或插入onRenderProcessGone方法，强制返回true。这样可根治90%的此类瓦解，插件开发待续。。。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]