我遇到了一个应用程序在运行大约 10 分钟后可靠地崩溃的问题，我正在尝试追踪崩溃的根源。

logcat 似乎表明崩溃是由于基于以下行的 grefs 泄漏造成的。

09-14 23:36:48.055 12383 12409 I monodroid-gc: 46080 outstanding GREFs. >Performing a full GC!

此行之后是疯狂的重复 GC Activity ，直到应用程序被 Activity 管理器终止，如以下行所示。

"08-23 11:10:14.393 880 894 I ActivityManager: Killing >1909:WheelchairQuickCollect.WheelchairQuickCollect/u0a220 (adj 0): user request >after error" (Note this line is from an earlier log - I just had it handy)

我尝试通过以下 adb 命令启用 gref 日志记录(如 https://developer.xamarin.com/guides/android/troubleshooting/troubleshooting/ 所建议)

"adb shell setprop debug.mono.log gref,gc"

但是我在日志记录方面遇到了两个问题

1) 日志条目似乎不包含任何有用的信息，下面是 gref 日志的示例。请注意，如 Xamarin 网站上的故障排除示例所示，在 gref 指向的对象上没有任何堆栈跟踪或类型信息。

2) 启用 gref 日志会导致我的应用程序的主 ui 卡住。我已经多次复制这种行为，但一直无法弄清楚为什么会这样。我没有在 ide 中遇到任何未捕获的异常，只是卡住屏幕，然后 Activity 管理器强制完成我的主要 Activity

(09-14 23:45:30.742 883 909 W ActivityManager: Force finishing activity >WheelchairQuickCollect.WheelchairQuickCollect/md580d5d820f0b3cedc88e4799f6dbbf8c>5.MainActivity )

有人对我如何识别锁定 UI 线程的内容有任何建议吗？

还有任何关于如何确定什么正在用尽所有 gref 的想法将不胜感激。甚至由这些 refs 链接的 .net 运行时或 java 对象的类型信息也是一个好的开始。

09-14 23:45:30.389 13759 14047 I monodroid-gref: +w+ grefc 1082 gwrefc 4 obj-handle 0x1018c6/G -> new-handle 0x2002d7/W from thread 'finalizer'(14047)

09-14 23:45:30.390 13759 14047 I monodroid-gref: +w+ grefc 1075 gwrefc 11 obj-handle 0x18ea/G -> new-handle 0x2f3/W from thread 'finalizer'(14047)

09-14 23:45:30.390 13759 14047 I monodroid-gref: -g- grefc 1075 gwrefc 11 handle 0x18ea/G from thread 'finalizer'(14047)

更新

非常感谢 SushiHangover 让我走上了正确的道路。我后来发现泄漏来自 c# port of the usb serial for android library .一些评论。

• 通过禁用我的一些请求/处理来自 android 传感器 API 的测量值的代码，我能够避免锁定 UI。不知道为什么会这样，但我现在没有时间弄明白。
• 我在/data/user/0/package_name_here/files/.__override__/grefs.txt 中找到了 gref.txt 日志。这与 SushiHangover 的回答略有不同。不确定这是否是我正在运行的 android 版本 (7.1.1) 的结果。我通过在我的主要 Activity onCreate 方法中记录 this.ApplicationContext.FilesDir.AbsolutePath 的结果来确定这条路径。
• gref.txt 日志非常冗长并且没有任何类型的摘要，因此很难确定哪些对象实际上正在泄漏。如果有人知道可以总结此文件的工具，那将非常有帮助。但是我确实发现您可以强制 dalvik 缓存转储引用表(本地/全局)的摘要。要转储表，您必须使用反射来调用 dumpReferenceTables 方法，如下所示。我在一个专门的任务中运行 debugGlobalRefWorker，每 10 秒打印一次表格。从转储的摘要部分，我能够快速识别泄漏对象的类型。然后我使用 gref.txt 日志来了解对象最常被分配的位置。幸运的是泄漏量很大，所以很容易看出它是从哪里来的。

我的转储引用表的代码

    public void debugGlobalRefWorker()
    {
        while(true)
        {
            dumpGlobalRefTable();
            Task.Delay(10000).Wait();
        }
    }

    //dont create these in dumpGlobalRefTable otherwise they will clutter up the gref log
    Java.Lang.Reflect.Method dumpGREFTableMethod = Java.Lang.Class.ForName("dalvik.system.VMDebug").GetDeclaredMethod("dumpReferenceTables");
    Java.Lang.Object[] args = new Java.Lang.Object[0];

    public void dumpGlobalRefTable()
    {
        //          Java.Lang.Class cls = Java.Lang.Class.ForName("android.os.Debug");
        //          Java.Lang.Class cls = Java.Lang.Class.ForName("dalvik.system.VMDebug");
        //      var method = cls.GetDeclaredMethod("dumpReferenceTables");
        dumpGREFTableMethod.Invoke(null,args);
    }

示例表

09-18 12:20:36.091 29146 29174 I art     : global reference table dump:

09-18 12:20:36.091 29146 29174 I art     :   Last 10 entries (of 677):

09-18 12:20:36.091 29146 29174 I art     :       676: 0x7106a800 java.lang.Class<android.hardware.SensorEvent>

09-18 12:20:36.091 29146 29174 I art     :       675: 0x32c023c0 android.hardware.SensorEvent

09-18 12:20:36.091 29146 29174 I art     :       674: 0x32c04520 android.os.Bundle

09-18 12:20:36.091 29146 29174 I art     :       673: 0x32c06070 com.google.android.gms.internal.zzary

09-18 12:20:36.091 29146 29174 I art     :       672: 0x7104b448 java.lang.Class<android.widget.Toast>
...

09-18 12:20:36.091 29146 29174 I art     :   Summary:

09-18 12:20:36.091 29146 29174 I art     :         1 of android.runtime.UncaughtExceptionHandler

09-18 12:20:36.091 29146 29174 I art     :         2 of md57dcfd83abf19bfc45de0a46e73444d92.ServiceConnectionHelper (2 unique instances)

09-18 12:20:36.092 29146 29174 I art     :         1 of md526b7ac14cffc1a788e82c7b73f3add08.GoogleApiClientConnectionCallbacksImpl

09-18 12:20:36.092 29146 29174 I art     :         1 of md580d5d820f0b3cedc88e4799f6dbbf8c5.WheelchairConnectService_FLPCallbackHelper

09-18 12:20:36.092 29146 29174 I art     :         1 of md5e34b7f0d2ba7321e77528f2c21447828.AndroidBaroMeasurementProvider

09-18 12:20:36.092 29146 29174 I art     :         1 of md5e34b7f0d2ba7321e77528f2c21447828.AndroidMagUncalMeasurementProvider

最佳答案

gref 文档在如何随着时间的推移而发生变化的情况下获取详细信息方面略有欠缺。

启用 gref 日志记录:

Logcat 输出(通过 adb logcat -s monodroid-gref 过滤):

adb shell setprop debug.mono.log gref

注意:我从未见过它挂起 UI 线程或导致终止，但请在运行应用程序之前尝试启用它

~~~~ 
09-14 23:40:19.656  4053  4053 I monodroid-gref: +g+ grefc 291 gwrefc 0 obj-handle 0x100019/I -> new-handle 0x100786/G from thread '(null)'(1)           
~~~~

Gref 详细信息在 grefs.txt 中:

+g+ grefc 291 gwrefc 0 obj-handle 0x100019/I -> new-handle 0x100786/G from thread '(null)'(1)
  at Android.Runtime.AndroidObjectReferenceManager.CreateGlobalReference (Java.Interop.JniObjectReference value) [0x00000] in <05a8ec13540f42fc8ec62ef099f948d3>:0
  at Java.Interop.JniObjectReference.NewGlobalRef () [0x00000] in <548a126e175845e0999036cd7abdeb57>:0
  at Android.Runtime.JNIEnv.NewGlobalRef (System.IntPtr jobject) [0x00000] in <05a8ec13540f42fc8ec62ef099f948d3>:0
  at Java.Lang.Object.RegisterInstance (Android.Runtime.IJavaObject instance, System.IntPtr value, Android.Runtime.JniHandleOwnership transfer, System.IntPtr& handle) [0x00000] in <05a8ec13540f42fc8ec62ef099f948d3>:0
  at Java.Lang.Object.SetHandle (System.IntPtr value, Android.Runtime.JniHandleOwnership transfer) [0x00000] in <05a8ec13540f42fc8ec62ef099f948d3>:0
  at Java.Lang.Object..ctor () [0x00000] in <05a8ec13540f42fc8ec62ef099f948d3>:0
  at Android_Gref_Test.JavaObjectWrapper..ctor () [0x00000] in /Users/Sushi/code/Projects/Android_Gref_Test/Android_Gref_Test/MainActivity.cs:45
  at Android_Gref_Test.MainActivity.Button_Click (System.Object sender, System.EventArgs e) [0x0003b] in /Users/Sushi/code/Projects/Android_Gref_Test/Android_Gref_Test/MainActivity.cs:33
  at Android.Views.View+IOnClickListenerImplementor.OnClick (Android.Views.View v) [0x00000] in <05a8ec13540f42fc8ec62ef099f948d3>:0
  at Android.Views.View+IOnClickListenerInvoker.n_OnClick_Landroid_view_View_ (System.IntPtr jnienv, System.IntPtr native__this, System.IntPtr native_v) [0x00000] in <05a8ec13540f42fc8ec62ef099f948d3>:0
  at System.Object.cf56947b-b824-4d0d-839a-1d6dd87a5b7c (System.IntPtr , System.IntPtr , System.IntPtr ) [0x00000] in <896ad1d315ca4ba7b117efb8dacaedcf>:0
handle 0x100786; key_handle 0x2ef9890: Java Type: `md505d171be8e81cafbccfb3a52eeebc2c5/JavaObjectWrapper`; MCW type: `Android_Gref_Test.JavaObjectWrapper`

这些详细信息位于应用程序数据文件的隐藏目录中 (files/.__override__/grefs.txt)。在某个时间点，此目录可world 访问，因此报告了一个安全漏洞并已修补 (Xamarin.Android 5.1.x)，因此您现在需要应用程序级别或 root 访问权限获得它。如果写入的消息过多，Android 也会丢弃 logcat 消息，因此 logcat 中的 gref 列表可能会被丢弃，因此详细信息存储在单独的文件中。

如果您有 root 访问权限，请使用 adb pull

注意:通过 abd root 获取基于非生产构建的模拟器的 root 访问权限。

adb pull /data/data/com.sushihangover.Android_Gref_Test/files/.__override__/grefs.txt ~/Desktop/grefs.txt

或者使用root shell:

adb shell 
cd /data/data/com.sushihangover.Android_Gref_Test/files/.__override__/
cat grefs.txt

或者如果您的应用程序包被标记为可调试:

adb shell
run-as com.sushihangover.Android_Gref_Test
cd files/.__override__
cat grefs.txt

将 Grefs.txt 复制到公共(public)目录:

注意:这只是一个简单的连续后台线程，将其放入您的 Activity.OnCreate 或在一些基于 Debug 的应用程序设置等中进行设置......

#if DEBUG
    Task.Run(async () =>
    {
        const int seconds = 30;
        const string grefTag = "monodroid-gref";
        const string grefsFile = "grefs.txt";
        while (true)
        {
            var appDir = Application.ApplicationInfo.DataDir;
            var grefFile = Path.Combine("/data/data", PackageName, "files/.__override__", grefsFile);
            var grefFilePublic = Path.Combine(Environment.GetExternalStoragePublicDirectory(Environment.DirectoryDownloads).AbsolutePath, grefsFile);
            if (File.Exists(grefFile))
            {
                File.Copy(grefFile, grefFilePublic, true);
                Log.Debug(grefTag, $"adb pull {grefFilePublic} {grefsFile}");
            }
            else
                Log.Debug(grefTag, "no grefs.txt found, gref logging enabled? (adb shell setprop debug.mono.log gref)");
            await Task.Delay(seconds * 1000);
        }
    });
#endif

您还可以通过以下方式强制输出到不同的目录:

adb shell setprop debug.mono.log gref=/some/writable/path/grefs.txt

关于android - 试图追踪 gref 泄漏，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/46232314/