Android Kotlin 应用程序在真实设备中运行时因致命信号 6 (SIGABRT) 而崩溃

Question

我的应用程序在 Fragment 的 OncreateView 返回后崩溃。我得到的堆栈跟踪是：

D/MenuAtividadesFragment: onCreate: Cheguei no onCreate

D/MenuAtividadesFragment: onCreateView: Cheguei no On createView

I/zygote: Starting a blocking GC NativeAllocBlocking

D/skia: --- allocation failed for scaled bitmap

I/zygote: Compiler allocated 4MB to compile void android.widget.TextView.<init>(android.content.Context, android.util.AttributeSet, int, int)

D/MenuAtividadesFragment: onViewCreated: Cheguei em On View Created

I/Choreographer: Skipped 1195 frames!  The application may be doing too much work on its main thread.

D/skia: external/skia/include/core/SkBitmap.h:282: fatal error: "sk_throw"

A/libc: Fatal signal 6 (SIGABRT), code -6 in tid 11765 (.aplicativo_rdo), pid 11765 (.aplicativo_rdo)

Disconnected from the target VM, address: 'localhost:51879', transport: 'socket'

它返回致命信号 6，但目前我只是在放大视图。

package com.eim.rdoApplication.ui.fragment

import android.os.Build
import android.os.Bundle
import android.util.Log
import android.view.LayoutInflater
import android.view.View
import android.view.ViewGroup
import android.view.animation.AnimationUtils
import android.widget.AutoCompleteTextView
import android.widget.ImageView
import android.widget.TextView
import androidx.annotation.RequiresApi
import androidx.cardview.widget.CardView
import androidx.fragment.app.Fragment
import androidx.fragment.app.viewModels
import androidx.navigation.fragment.findNavController
import androidx.navigation.fragment.navArgs
import com.eim.rdoApplication.R
import com.eim.rdoApplication.data.model.entity.ActivityEntity
import com.eim.rdoApplication.data.model.entity.InstallationReportEntity
import com.eim.rdoApplication.data.model.openWeatherApi.CurrentLocationInformation
import com.eim.rdoApplication.ui.viewModel.DepartmentsMenuViewModel
import com.eim.rdoApplication.utils.GPSUtilsKotlin
import com.eim.rdoApplication.utils.Resource
import dagger.hilt.android.AndroidEntryPoint
import kotlinx.coroutines.*
import kotlinx.coroutines.flow.collect
import kotlin.coroutines.CoroutineContext


private const val TAG = "MenuAtividadesFragment"
@AndroidEntryPoint
class HomeFragment:Fragment(), CoroutineScope, TryAgainNetworkListener {

    private val navController by lazy {
        findNavController()
    }
    lateinit var loadingImageView: ImageView
    lateinit var loadingBg: ImageView
    lateinit var autoCompleteTextView: AutoCompleteTextView
    lateinit var reportTitleTextView:TextView
    lateinit var rootView: View
    private val args: HomeFragmentArgs by navArgs()
    private val departmentsMenuViewModel:DepartmentsMenuViewModel by viewModels()
    lateinit var dialogFragment: NetworkErrorFragment
    private var job = Job()
    override val coroutineContext: CoroutineContext
        get() = Dispatchers.IO + job

    private var installationsReports: List<InstallationReportEntity>?=null

    override fun onCreate(savedInstanceState: Bundle?) {
        departmentsMenuViewModel.installationReportId = args.installationReportId
        super.onCreate(savedInstanceState)
        Log.d(TAG, "onCreate: Cheguei no onCreate")
    }

    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View {
                Log.d(TAG, "onCreateView: Cheguei no On createView")
                rootView = inflater.inflate(
                    R.layout.fragment_new_home_screen_updated,
                    container,
                    false
                )
//                setupReloadButton()
//                setupLoadingViews()
//                getUserInformation()
//                setupCardViews()
//                setupWeather()
                return rootView
        }

显然，只有膨胀视图会导致崩溃。

另一个有趣的事情是，片段视图在安卓虚拟设备（Pixel 3 API 30）中运行时会膨胀，但在真实设备（摩托罗拉 G5S API 26）中崩溃。

如果有人能帮我找出原因，我将不胜感激。

[EDITED] 所以伙计们，我安装了 LeakCanary 来尝试缩小可能的内存泄漏，结果我离原因更近了。这是它给我的报告：

====================================
    HEAP ANALYSIS RESULT
    ====================================
    1 APPLICATION LEAKS
    References underlined with "~~~" are likely causes.
    Learn more at https://squ.re/leaks.
    3054 bytes retained by leaking objects
    Signature: 108d5f2862bd8da48823273827314afbdcc2540
    ┬───
    │ GC Root: Local variable in native code
    │
    ├─ android.os.HandlerThread instance
    │    Leaking: NO (PathClassLoader↓ is not leaking)
    │    Thread name: 'LeakCanary-Heap-Dump'
    │    ↓ HandlerThread.contextClassLoader
    ├─ dalvik.system.PathClassLoader instance
D/LeakCanary: │    Leaking: NO (InternalLeakCanary↓ is not leaking and A ClassLoader is never leaking)
    │    ↓ PathClassLoader.runtimeInternalObjects
    ├─ java.lang.Object[] array
    │    Leaking: NO (InternalLeakCanary↓ is not leaking)
    │    ↓ Object[].[616]
    ├─ leakcanary.internal.InternalLeakCanary class
    │    Leaking: NO (MainActivity↓ is not leaking and a class is never leaking)
    │    ↓ static InternalLeakCanary.resumedActivity
    ├─ com.eim.rdoApplication.ui.activity.MainActivity instance
    │    Leaking: NO (NavHostFragment↓ is not leaking and Activity#mDestroyed is false)
    │    mApplication instance of com.eim.rdoApplication.AppAplication
    │    mBase instance of androidx.appcompat.view.ContextThemeWrapper, not wrapping known Android context
    │    ↓ MainActivity.mFragments
    ├─ androidx.fragment.app.FragmentController instance
    │    Leaking: NO (NavHostFragment↓ is not leaking)
    │    ↓ FragmentController.mHost
    ├─ androidx.fragment.app.FragmentActivity$HostCallbacks instance
    │    Leaking: NO (NavHostFragment↓ is not leaking)
    │    this$0 instance of com.eim.rdoApplication.ui.activity.MainActivity with mDestroyed = false
    │    mActivity instance of com.eim.rdoApplication.ui.activity.MainActivity with mDestroyed = false
    │    mContext instance of com.eim.rdoApplication.ui.activity.MainActivity with mDestroyed = false
    │    ↓ FragmentActivity$HostCallbacks.mFragmentManager
    ├─ androidx.fragment.app.FragmentManagerImpl instance
    │    Leaking: NO (NavHostFragment↓ is not leaking)
    │    ↓ FragmentManagerImpl.mPrimaryNav
    ├─ androidx.navigation.fragment.NavHostFragment instance
    │    Leaking: NO (LoginFragment↓ is not leaking and Fragment#mFragmentManager is not null)
    │    ↓ NavHostFragment.mChildFragmentManager
    ├─ androidx.fragment.app.FragmentManagerImpl instance
D/LeakCanary: │    Leaking: NO (LoginFragment↓ is not leaking)
    │    ↓ FragmentManagerImpl.mFragmentStore
    ├─ androidx.fragment.app.FragmentStore instance
    │    Leaking: NO (LoginFragment↓ is not leaking)
    │    ↓ FragmentStore.mActive
    ├─ java.util.HashMap instance
    │    Leaking: NO (LoginFragment↓ is not leaking)
    │    ↓ HashMap.table
    ├─ java.util.HashMap$Node[] array
    │    Leaking: NO (LoginFragment↓ is not leaking)
    │    ↓ HashMap$Node[].[0]
    ├─ java.util.HashMap$Node instance
    │    Leaking: NO (LoginFragment↓ is not leaking)
    │    ↓ HashMap$Node.value
    ├─ androidx.fragment.app.FragmentStateManager instance
    │    Leaking: NO (LoginFragment↓ is not leaking)
    │    ↓ FragmentStateManager.mFragment
    ├─ com.eim.rdoApplication.ui.fragment.login.LoginFragment instance
    │    Leaking: NO (Fragment#mFragmentManager is not null)
    │    componentContext instance of dagger.hilt.android.internal.managers.ViewComponentManager$FragmentContextWrapper,
    │    wrapping activity com.eim.rdoApplication.ui.activity.MainActivity with mDestroyed = false
    │    ↓ LoginFragment.loadingBg
    │                    ~~~~~~~~~
    ├─ androidx.appcompat.widget.AppCompatImageView instance
    │    Leaking: UNKNOWN
    │    Retaining 2801 bytes in 23 objects
    │    View not part of a window view hierarchy
    │    View.mAttachInfo is null (view detached)
D/LeakCanary: │    View.mID = R.id.imageView_loading_bg
    │    View.mWindowAttachCount = 1
    │    mContext instance of dagger.hilt.android.internal.managers.ViewComponentManager$FragmentContextWrapper, wrapping
    │    activity com.eim.rdoApplication.ui.activity.MainActivity with mDestroyed = false
    │    ↓ AppCompatImageView.mParent
    │                         ~~~~~~~
    ╰→ androidx.constraintlayout.widget.ConstraintLayout instance
    ​     Leaking: YES (ObjectWatcher was watching this because com.eim.rdoApplication.ui.fragment.login.LoginFragment
    ​     received Fragment#onDestroyView() callback (references to its views should be cleared to prevent leaks))
    ​     Retaining 3054 bytes in 52 objects
    ​     key = 0ab7649b-62de-4b19-a9c6-7c9cf02b88a5
    ​     watchDurationMillis = 142488
    ​     retainedDurationMillis = 137486
    ​     View not part of a window view hierarchy
    ​     View.mAttachInfo is null (view detached)
    ​     View.mWindowAttachCount = 1
    ​     mContext instance of dagger.hilt.android.internal.managers.ViewComponentManager$FragmentContextWrapper, wrapping
    ​     activity com.eim.rdoApplication.ui.activity.MainActivity with mDestroyed = false

我收到了这份报告，但我不完全明白如何解决它或我做错了什么

Answer 1

我想我发现了导致致命错误的原因。 我安装了leakCanary 并得到了上面的跟踪。在挖掘跟踪之后，据我所知，事实证明我在片段 A 中保留了对某些视图的引用。然后，当我从片段 A 离开到下一个片段时，我没有正确清除视图引用。因此，通过在片段 A 的 onDestroyView() 方法中将此引用设置为 null 来解决此问题。