Android 使用kotlin协程时随机崩溃

我正在使用

recyclerView

来显示SD卡上的图像/视频，就像一个图库应用程序&最近我迁移到Kotlin，并尝试使用协同程序进行后台工作。。
但是，当我启动协同程序时，会出现随机崩溃，我无法理解Firebase Crashlytics显示的stacktrace，它显示了崩溃发生的类别和行号，但没有显示崩溃的原因

下面是发生崩溃的

refresh（）

方法

private fun refreshGallery() {
    gridView.adapter = null
    if (actionMode != null) actionMode!!.finish()
    myAdapter = Adapter(galleryType!!, this@BaseFragment) //This is where I am getting a crash on some devices...
    ref.isRefreshing = true

    launch {
        delay(1000)
        val statusList = getMediaFiles()
        myAdapter!!.addAll(statusList)

        myAdapter!!.setEmptyView(empty)
        gridView.adapter = myAdapter
        myAdapter!!.toogleEmptyView()
        if (ref.isRefreshing) ref.isRefreshing = false
    }
}

此方法在

onCreateView（）

&

swipeRefresh.setOnRefreshListener{}

更多信息，我在片段中扩展了

CoroutineScope

，因此没有

Global.launch{}

我还尝试对函数使用

suspend

修饰符，将

withContext（）

更改为

async{}。wait

但仍会崩溃

这是Crashlytics的日志-

Caused by e.b
   at com.example.fragments.BaseFragment.refreshGallery + 352(BaseFragment.java:352)
   at com.example.fragments.BaseFragment.onCreateView + 233(BaseFragment.java:233)
   at androidx.fragment.app.Fragment.onCreateAnimator(Fragment.java:5)
   at androidx.fragment.app.Fragment.performCreateView + 2595(Fragment.java:2595)
   at androidx.fragment.app.FragmentManagerImpl.moveToState + 880(FragmentManagerImpl.java:880)
   at androidx.fragment.app.FragmentManagerImpl.moveFragmentToExpectedState + 1237(FragmentManagerImpl.java:1237)
   at androidx.fragment.app.FragmentManagerImpl.moveToState + 1302(FragmentManagerImpl.java:1302)
   at androidx.fragment.app.FragmentManagerImpl.dispatchStateChange + 2655(FragmentManagerImpl.java:2655)
   at androidx.fragment.app.FragmentManagerImpl.dispatchActivityCreated + 2609(FragmentManagerImpl.java:2609)
   at androidx.fragment.app.FragmentController.dispatchActivityCreated + 246(FragmentController.java:246)
   at androidx.fragment.app.FragmentActivity.onStart + 542(FragmentActivity.java:542)
   at androidx.appcompat.app.AppCompatActivity.onStart + 201(AppCompatActivity.java:201)
   at com.example.MainActivity.onStart + 189(MainActivity.java:189)
   at android.app.Instrumentation.callActivityOnStart + 1249(Instrumentation.java:1249)
   at android.app.Activity.performStart + 6873(Activity.java:6873)
   at android.app.ActivityThread.performLaunchActivity + 2687(ActivityThread.java:2687)
   at android.app.ActivityThread.handleLaunchActivity + 2785(ActivityThread.java:2785)
   at android.app.ActivityThread.-wrap12(ActivityThread.java)
   at android.app.ActivityThread$H.handleMessage + 1532(ActivityThread.java:1532)
   at android.os.Handler.dispatchMessage + 102(Handler.java:102)
   at android.os.Looper.loop + 163(Looper.java:163)
   at android.app.ActivityThread.main + 6342(ActivityThread.java:6342)
   at java.lang.reflect.Method.invoke(Method.java)
   at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run + 880(ZygoteInit.java:880)
   at com.android.internal.os.ZygoteInit.main + 770(ZygoteInit.java:770)

main活动的

onStart（）

-

override fun onStart() {
    super.onStart()
    try {
        NotificationManagerCompat.from(this@MainActivity).cancelAll()
    } catch (ignore: Exception) {}
}

---

第一步应该是检索相关构建的模糊处理

mapping.txt

，并查找

e.b

映射到的内容

然而，从上下文来看，我猜测它映射到

kotlin.KotlinNullPointerException

，如果一个被断言为非null的变量（通过

！！

）实际上是

null

，就会抛出该异常

---

由于这与协同程序无关，并且您的问题中没有包含处理相关变量（

galleryType

）的代码，因此无法进行进一步调试。

第一步应该是检索相关生成的模糊处理

mapping.txt

，并查找

e.b

映射到的内容

然而，从上下文来看，我猜测它映射到

kotlin.KotlinNullPointerException

，如果一个被断言为非null的变量（通过

！！

）实际上是

null

，就会抛出该异常

---

由于这与协程无关，并且问题中没有包含处理相关变量（

galleryType

）的代码，因此无法进行进一步调试。

如果您将函数参数声明为不可空（如

fun foo（bar:String）

），也会引发相同的异常然后从Java调用它并传递一个空值。这很好地工作了，我不知道为什么Kotlin中会抛出异常，Java中从来没有这样的异常。。您的回答仍然帮助我解决了这个问题：）大概您从未在

galleryType

上调用过一个方法，所以即使它是

null

，通常也不会抛出异常。但是Kotlin试图在其原点附近抛出NPE，而不是在有人试图访问NPE以确保其正确性时抛出。如果您将函数参数声明为不可空（如

fun foo（bar:String）

），然后从Java调用它并传递空值，也会抛出相同的异常。这非常有效，不知道为什么Kotlin中会抛出异常，Java中从未出现过。。您的回答仍然帮助我解决了这个问题：）大概您从未在

galleryType

上调用过一个方法，所以即使它是

null

，通常也不会抛出异常。但科特林试图将NPE扔到它们的原点附近，而不是当有人试图访问它们以获得正确性时。