三星设备上的本机崩溃高峰

Question

上个月，我在 Google Play Console 上看到了本机崩溃的强劲高峰，它们来自三星设备，占 98%，主要是 Android 10 (90%)，其次是 Android 9 (10%)。超过一半的案例与三星 S9 设备有关，而其余案例与最近的设备型号（三星 s10+、Note9 等）有关。

有堆栈跟踪：

#00  pc 0000000000083360  /apex/com.android.runtime/lib64/bionic/libc.so (abort+176)
  #01  pc 0000000000008a74  /system/lib64/liblog.so (__android_log_assert+324)
  #02  pc 00000000003fb0dc  /system/lib64/libhwui.so (android::uirenderer::renderthread::EglManager::swapBuffers(android::uirenderer::renderthread::Frame const&, SkRect const&)+276)
  #03  pc 00000000003fae4c  /system/lib64/libhwui.so (android::uirenderer::skiapipeline::SkiaOpenGLPipeline::swapBuffers(android::uirenderer::renderthread::Frame const&, bool, SkRect const&, android::uirenderer::FrameInfo*, bool*)+92)
  #04  pc 0000000000407c8c  /system/lib64/libhwui.so (android::uirenderer::renderthread::CanvasContext::draw()+716)
  #05  pc 0000000000406d38  /system/lib64/libhwui.so (_ZNSt3__110__function6__funcIZN7android10uirenderer12renderthread13DrawFrameTask11postAndWaitEvE3$_0NS_9allocatorIS6_EEFvvEEclEv$c303f2d2360db58ed70a2d0ac7ed911b+216)
  #06  pc 0000000000417a44  /system/lib64/libhwui.so (android::uirenderer::WorkQueue::process()+228)
  #07  pc 0000000000417770  /system/lib64/libhwui.so (android::uirenderer::renderthread::RenderThread::threadLoop()+80)
  #08  pc 00000000000137a4  /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+284)
  #09  pc 00000000000e3b14  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+36)
  #10  pc 0000000000085330  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)

此外，还有另一个问题仅出现在三星设备和 Android 10 上（设备型号分布似乎很随机）： 这是在没有采取任何特定行动的情况下解决的

#00  pc 0000000002cfeadc  /data/app/com.google.android.webview-8w0eiuwFhdVaEviNzD1U7g==/base.apk!libmonochrome.so (offset 0x15b000)

我不知道是什么导致了问题，但我还附上了我的build.gradle文件依赖项，因为这些问题通常与 Google 库相关联。

dependencies {

    implementation 'androidx.appcompat:appcompat:1.1.0-alpha04'
    implementation 'androidx.recyclerview:recyclerview:1.1.0-alpha04'
    implementation 'androidx.preference:preference:1.1.0'
    implementation 'com.google.code.gson:gson:2.8.6'
    implementation 'com.google.android.material:material:1.1.0-alpha06'
    implementation 'androidx.legacy:legacy-support-v4:1.0.0'
    implementation 'androidx.cardview:cardview:1.0.0'
    implementation 'androidx.browser:browser:1.2.0'
    implementation 'com.github.smarteist:autoimageslider:1.3.2'

    implementation 'com.android.billingclient:billing:2.1.0'
    implementation 'com.nononsenseapps:filepicker:4.2.1'
    implementation 'com.simplecityapps:recyclerview-fastscroll:2.0.0'
    implementation 'com.github.AppIntro:AppIntro:5.1.0'
    implementation 'net.cachapa.expandablelayout:expandablelayout:2.9.2'
    implementation 'com.github.faruktoptas:FancyShowCaseView:1.0.0'
    implementation 'me.drakeet.support:toastcompat:1.1.0'
    implementation 'com.github.hkk595:Resizer:v1.5'

    implementation 'com.github.bumptech.glide:glide:4.11.0'
    implementation 'androidx.multidex:multidex:2.0.1'
    implementation 'com.google.firebase:firebase-analytics:17.2.1'
    implementation 'com.google.firebase:firebase-messaging:20.0.1'
    implementation 'com.google.firebase:firebase-ads:18.2.0'
    implementation 'com.google.firebase:firebase-crashlytics:17.0.0-beta01'
    implementation 'com.google.firebase:firebase-crashlytics-ndk:17.0.0-beta01'

}

有没有人看到同样的问题？

更新 关于第一个问题，我对发生崩溃的应用程序活动应用的主要更改之一是关于更新的 Android 视图绑定。由于崩溃似乎与UI有关，因此可能是这种情况。有没有人也使用视图绑定？

更新 2 看起来切换到旧的findViewById（仅在崩溃时处于活动状态的活动中）而不是使用视图绑定使问题消失。目前我正在一小部分 beta 测试人员上测试它，但此时我应该已经看到了一些崩溃报告。我会不断更新这篇文章。

Answer 1

即使我在应用程序中的某些广告中也经历过这种崩溃。即使您可以通过调用 webview.loadUrl("chrome://crash") 来重现 webview 崩溃，这也会使您的 webview 崩溃，并且您将能够重现该场景。

抑制这些崩溃的唯一方法是重写webview 客户端中的onRenderProcessGone并自行处理崩溃，在这种情况下，广告 SDK 必须处理，因为 webview 是由它们实现的。

参考： https: //github.com/mopub/mopub-android-sdk/issues/312

Answer 2

自从我发布问题 \xe2\x94\x80 以来已经过去了两年，距离问题首次出现 \xe2\x94\x80 已经过去了 2.5 年，现在看来我已经找到了根本原因。

\n

我看到的晦涩的堆栈跟踪有点误导，但这表明了与文件描述符相关的底层问题，事实上，当我实现使用从 Java 端接收的 FD 的 JNI 代码时，这个问题第一次出现。

\n

问题的解决方案是确保我没有双重关闭文件描述符，因此我执行以下步骤：

\n

\n
• 在 Java 端，将文件描述符与对象分离ParcelFileDescriptor。现在由您的 JNI 代码来关闭文件描述符，因此您不必再调用了ParcelFileDescriptor.close()！
\n
• 在 JNI 端使用文件描述符打开流fdopen()并对文件执行操作
\n
• 完成后调用fclose()文件描述符
\n
• 仅此而已，无需close()执行其他调用
\n

\n

最后，仔细检查 \xe2\x94\x80 但不要双重关闭:\') \xe2\x94\x80 如何管理文件描述符，特别是如果您在应用程序中实现了一些本机代码。

\n