当前位置:首页 » 《关于电脑》 » 正文

解决webview TOP崩溃Render process (7110)‘s crash wasn‘t handled by all associated webviews, triggering

8 人参与  2024年11月19日 18:01  分类 : 《关于电脑》  评论

点击全文阅读


[FATAL:crashpad_client_linux.cc(745)] Render process (7110)'s crash wasn't handled by all associated  webviews, triggering application crash.

崩溃错误如下

[FATAL:crashpad_client_linux.cc(745)] Render process (7110)'s crash wasn't handled by all associated  webviews, triggering application crash.pid: 0, tid: 6625 >>> com.ssa.erw.basd <<<backtrace:  #00  pc 0x00000000066ebbb8  /data/app/~~TiOrp6oxxcLg8dq23ARp9g==/com.google.android.trichromelibrary_666807033-96Vgpyd6PfGIV7uDuJ_zPA==/base.apk!libmonochrome_64.so (BuildId: 3a85f8990734d8d4cfc185bd88d9662091624cd1)  #01  pc 0x0000000004046d04  /data/app/~~TiOrp6oxxcLg8dq23ARp9g==/com.google.android.trichromelibrary_666807033-96Vgpyd6PfGIV7uDuJ_zPA==/base.apk!libmonochrome_64.so (BuildId: 3a85f8990734d8d4cfc185bd88d9662091624cd1)  #02  pc 0x00000000066ebbe4  /data/app/~~TiOrp6oxxcLg8dq23ARp9g==/com.google.android.trichromelibrary_666807033-96Vgpyd6PfGIV7uDuJ_zPA==/base.apk!libmonochrome_64.so (BuildId: 3a85f8990734d8d4cfc185bd88d9662091624cd1)  #03  pc 0x0000000006b7c3d4  /data/app/~~TiOrp6oxxcLg8dq23ARp9g==/com.google.android.trichromelibrary_666807033-96Vgpyd6PfGIV7uDuJ_zPA==/base.apk!libmonochrome_64.so (BuildId: 3a85f8990734d8d4cfc185bd88d9662091624cd1)  #04  pc 0x00000000046c14f0  /data/app/~~TiOrp6oxxcLg8dq23ARp9g==/com.google.android.trichromelibrary_666807033-96Vgpyd6PfGIV7uDuJ_zPA==/base.apk!libmonochrome_64.so (BuildId: 3a85f8990734d8d4cfc185bd88d9662091624cd1)  #05  pc 0x000000000671a288  /data/app/~~TiOrp6oxxcLg8dq23ARp9g==/com.google.android.trichromelibrary_666807033-96Vgpyd6PfGIV7uDuJ_zPA==/base.apk!libmonochrome_64.so (BuildId: 3a85f8990734d8d4cfc185bd88d9662091624cd1)  #06  pc 0x0000000006734dd0  /data/app/~~TiOrp6oxxcLg8dq23ARp9g==/com.google.android.trichromelibrary_666807033-96Vgpyd6PfGIV7uDuJ_zPA==/base.apk!libmonochrome_64.so (BuildId: 3a85f8990734d8d4cfc185bd88d9662091624cd1)  #07  pc 0x0000000000018e8c  /system/lib64/libutils.so (android::Looper::pollInner(int)+1276)  #08  pc 0x000000000001892c  /system/lib64/libutils.so (android::Looper::pollOnce(int, int*, int*, void**)+124)  #09  pc 0x0000000000188dbc  /system/lib64/libandroid_runtime.so (android::android_os_MessageQueue_nativePollOnce(_JNIEnv*, _jobject*, long, int)+44)  #10  pc 0x00000000003883e0  /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (art_jni_trampoline+112)  #11  pc 0x0000000000adb408  /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (android.os.MessageQueue.next+280)  #12  pc 0x0000000000ad7e70  /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (android.os.Looper.loopOnce+96)  #13  pc 0x0000000000ad7d68  /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (android.os.Looper.loop+1112)  #14  pc 0x000000000082dc0c  /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (android.app.ActivityThread.main+2332)  #15  pc 0x0000000000362a40  /apex/com.android.art/lib64/libart.so (art_quick_invoke_static_stub+640)  #16  pc 0x000000000035e42c  /apex/com.android.art/lib64/libart.so (_jobject* art::InvokeMethod<(art::PointerSize)8>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jobject*, _jobject*, unsigned long)+732)  #17  pc 0x00000000006c8b78  /apex/com.android.art/lib64/libart.so (art::Method_invoke(_JNIEnv*, _jobject*, _jobject*, _jobjectArray*) (.__uniq.165753521025965369065708152063621506277)+32)  #18  pc 0x000000000038e9c4  /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (art_jni_trampoline+116)  #19  pc 0x0000000000e65234  /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run+132)  #20  pc 0x0000000000e70ed4  /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (com.android.internal.os.ZygoteInit.main+3540)  #21  pc 0x0000000000362a40  /apex/com.android.art/lib64/libart.so (art_quick_invoke_static_stub+640)  #22  pc 0x000000000034df38  /apex/com.android.art/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+204)  #23  pc 0x000000000034beec  /apex/com.android.art/lib64/libart.so (art::JValue art::InvokeWithVarArgs<_jmethodID*>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jmethodID*, std::__va_list)+512)  #24  pc 0x0000000000739bf4  /apex/com.android.art/lib64/libart.so (art::JNI<true>::CallStaticVoidMethodV(_JNIEnv*, _jclass*, _jmethodID*, std::__va_list)+104)  #25  pc 0x00000000000deca8  /system/lib64/libandroid_runtime.so (_JNIEnv::CallStaticVoidMethod(_jclass*, _jmethodID*, ...)+104)  #26  pc 0x00000000000eb5dc  /system/lib64/libandroid_runtime.so (android::AndroidRuntime::start(char const*, android::Vector<android::String8> const&, bool)+860)  #27  pc 0x000000000000256c  /system/bin/app_process64 (main+1292)  #28  pc 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进程退出。

我们来看看这个方法的注释翻译:

通知宿主应用程序给定的WebView的渲染进程已退出。多个WebView实例可能与单个渲染进程相关联;每个受影响的WebView都会调用onRenderProcessGone。应用程序对此回调的实现应仅尝试清理作为参数提供的特定WebView,而不应假设其他WebView实例受到影响。给定的WebView无法使用,应该从视图层次结构中删除,应该清除对它的所有引用,例如在Activity或使用android保存的其他类中的任何引用。视图。查看。findviewid和类似的调用等。为了测试渲染进程崩溃,应用程序可以在WebView上调用loadUrl("chrome://crash")。请注意,如果多个WebView实例共享一个渲染进程,则可能会受到影响,而不仅仅是加载chrome://崩溃的特定WebView。
参数:
view – 需要清理的 WebView。详细信息——退出原因。
退货:
如果宿主应用程序处理了进程已退出的情况,则为true,否则,如果呈现进程崩溃,应用程序将崩溃,或者如果呈现进程被系统杀死,应用程序将被杀死。

解决问题,根据注释的参与,重写webviewClient的方法,返回true。

@Overridepublic boolean onRenderProcessGone(android.webkit.WebView view, RenderProcessGoneDetail detail) {    return true;}

如果想要更完善处理,可以在此类崩溃发生时,展示错误页面

@Overridepublic 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%的此类崩溃,插件开发待续。。。


点击全文阅读


本文链接:http://zhangshiyu.com/post/188877.html

<< 上一篇 下一篇 >>

  • 评论(0)
  • 赞助本站

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。

关于我们 | 我要投稿 | 免责申明

Copyright © 2020-2022 ZhangShiYu.com Rights Reserved.豫ICP备2022013469号-1