PT950 ·Android Studio 如何分析錯(cuò)誤報(bào)告
前面的小節(jié)我們介紹了調(diào)試布局方面的知識(shí)，可以有效的幫助我們解決布局顯示異常，本小結(jié)我們學(xué)習(xí)如何獲取和分析錯(cuò)誤報(bào)告。
1. 獲取錯(cuò)誤報(bào)告
錯(cuò)誤報(bào)告包含設(shè)備日志、堆棧軌跡和其他診斷信息，可以幫助我們查找和修復(fù)應(yīng)用中的錯(cuò)誤。我們可以通過(guò)以下幾種方式從設(shè)備上獲取錯(cuò)誤報(bào)告。
1.1 從真機(jī)設(shè)備上獲取
如需直接從我們的設(shè)備上獲取錯(cuò)誤報(bào)告，請(qǐng)執(zhí)行以下操作：
-
確保已啟用開(kāi)發(fā)者選項(xiàng)；
-
在開(kāi)發(fā)者選項(xiàng)中，點(diǎn)按錯(cuò)誤報(bào)告；
-
選擇所需的錯(cuò)誤報(bào)告類型，然后點(diǎn)按報(bào)告；
稍后，我們便會(huì)收到錯(cuò)誤報(bào)告已準(zhǔn)備就緒的通知。
-
要分享錯(cuò)誤報(bào)告，請(qǐng)點(diǎn)按該通知。
1.2 從 Android 模擬器上獲取
在 Android 模擬器中，我們可以使用 Extended controls 窗口中的 Bug report 功能：
-
點(diǎn)擊模擬器面板中的 More 圖標(biāo)；
-
在 Extended controls 窗口中，選擇左側(cè)的 Bug report；
此時(shí)系統(tǒng)會(huì)打開(kāi)一個(gè)屏幕，我們可以在其中查看錯(cuò)誤報(bào)告詳細(xì)信息，例如屏幕截圖、AVD 配置信息和錯(cuò)誤報(bào)告日志。我們還可以輸入一條包含復(fù)制步驟的消息，以便與報(bào)告一起保存。
-
等待錯(cuò)誤報(bào)告完成收集，然后點(diǎn)擊 Save Report。
1.3 使用 adb 命令獲取
如果我們只連接了一臺(tái)設(shè)備，則可以使用 adb 獲取錯(cuò)誤報(bào)告，如下所示：
$ adb bugreport D:\Reports
Tips：如果沒(méi)有指定錯(cuò)誤報(bào)告的路徑，則系統(tǒng)會(huì)將其保存到本地目錄。
如果我們連接了多臺(tái)設(shè)備，則必須使用 -s 選項(xiàng)指定設(shè)備。運(yùn)行以下 adb 命令可獲取設(shè)備序列號(hào)并生成錯(cuò)誤報(bào)告：
$ adb devices
List of devices attached
emulator-5554 device
8XV7N15C31003476 device
$ adb -s 8XV7N15C31003476 bugreport
2. 錯(cuò)誤報(bào)告文件內(nèi)容
默認(rèn)情況下，錯(cuò)誤報(bào)告是 ZIP 文件。ZIP 文件名類似 bugreport-BUILD_ID-DATE.zip，它可能會(huì)包含多個(gè)文件，但最重要的文件是 bugreport-BUILD_ID-DATE.txt。此文件就是錯(cuò)誤報(bào)告，它包含系統(tǒng)服務(wù) (dumpsys)、錯(cuò)誤日志 (dumpstate) 和系統(tǒng)消息日志 (logcat) 的診斷輸出。系統(tǒng)消息包括設(shè)備拋出錯(cuò)誤時(shí)的堆棧軌跡，以及從所有應(yīng)用中使用 Log 類寫入的消息。
ZIP 文件中有一個(gè) version.txt 元數(shù)據(jù)文件，其中包含 Android 版本號(hào)，而且啟用 systrace 后，ZIP 文件中還會(huì)包含 systrace.txt 文件。Systrace 工具可以獲取并顯示應(yīng)用進(jìn)程和其他 Android 系統(tǒng)進(jìn)程的執(zhí)行時(shí)間，從而幫助分析應(yīng)用的性能。
dumpstate 工具會(huì)將文件從設(shè)備的文件系統(tǒng)復(fù)制到 ZIP 文件的 FS 文件夾下，以便我們引用它們。例如，設(shè)備中的 /dirA/dirB/fileC 文件會(huì)在 ZIP 文件中生成 FS/dirA/dirB/fileC 條目
錯(cuò)誤報(bào)告文件結(jié)構(gòu)如下：
3. 常見(jiàn)日志分析
3.1 ANR 和死鎖
錯(cuò)誤報(bào)告有助于我們找出導(dǎo)致應(yīng)用無(wú)響應(yīng) (ANR) 錯(cuò)誤和死鎖事件的原因。
- 找出無(wú)響應(yīng)的應(yīng)用
當(dāng)某個(gè)應(yīng)用在一定時(shí)間內(nèi)沒(méi)有響應(yīng)（通常是由于主線程被阻塞或繁忙）時(shí)，系統(tǒng)會(huì)終止該進(jìn)程并將堆棧轉(zhuǎn)儲(chǔ)到 /data/anr。要找出 ANR 背后的罪魁禍?zhǔn)祝?qǐng)為二進(jìn)制事件日志中的 am_anr 執(zhí)行 grep 命令。
日志范例如下：
grep "am_anr" bugreport-2015-10-01-18-13-48.txt
10-01 18:12:49.599 4600 4614 I am_anr : [0,29761,com.google.android.youtube,953695941,executing service com.google.android.youtube/com.google.android.apps.youtube.app.offline.transfer.OfflineTransferService]
10-01 18:14:10.211 4600 4614 I am_anr : [0,30363,com.google.android.apps.plus,953728580,executing service com.google.android.apps.plus/com.google.android.apps.photos.service.PhotosService]
我們也可以為 logcat 日志（其中包含關(guān)于發(fā)生 ANR 時(shí)是什么在占用 CPU 的更多信息）中的 ANR in 執(zhí)行 grep 命令。
日志范例如下：
grep "ANR in" bugreport-2015-10-01-18-13-48.txt
10-01 18:13:11.984 4600 4614 E ActivityManager: ANR in com.google.android.youtube
10-01 18:14:31.720 4600 4614 E ActivityManager: ANR in com.google.android.apps.plus
10-01 18:14:31.720 4600 4614 E ActivityManager: PID: 30363
10-01 18:14:31.720 4600 4614 E ActivityManager: Reason: executing service com.google.android.apps.plus/com.google.android.apps.photos.service.PhotosService
10-01 18:14:31.720 4600 4614 E ActivityManager: Load: 35.27 / 23.9 / 16.18
10-01 18:14:31.720 4600 4614 E ActivityManager: CPU usage from 16ms to 21868ms later:
10-01 18:14:31.720 4600 4614 E ActivityManager: 74% 3361/mm-qcamera-daemon: 62% user + 12% kernel / faults: 15276 minor 10 major
10-01 18:14:31.720 4600 4614 E ActivityManager: 41% 4600/system_server: 18% user + 23% kernel / faults: 18597 minor 309 major
10-01 18:14:31.720 4600 4614 E ActivityManager: 32% 27420/com.google.android.GoogleCamera: 24% user + 7.8% kernel / faults: 48374 minor 338 major
10-01 18:14:31.720 4600 4614 E ActivityManager: 16% 130/kswapd0: 0% user + 16% kernel
10-01 18:14:31.720 4600 4614 E ActivityManager: 15% 283/mmcqd/0: 0% user + 15% kernel
...
10-01 18:14:31.720 4600 4614 E ActivityManager: 0.1% 27248/irq/503-synapti: 0%
10-01 18:14:31.721 4600 4614 I ActivityManager: Killing 30363:com.google.android.apps.plus/u0a206 (adj 0): bg anr
- 查找堆棧跟蹤
通常我們可以找到與 ANR 對(duì)應(yīng)的堆棧跟蹤。請(qǐng)確保 VM 跟蹤上的時(shí)間戳和 PID 與我們正在調(diào)查的 ANR 相符，然后再檢查進(jìn)程的主線程。
日志范例如下：
VM TRACES AT LAST ANR (/data/anr/traces.txt: 2015-10-01 18:14:41)
pid 30363 at 2015-10-01 18:14:11
Cmd line: com.google.android.apps.plus
Build fingerprint: 'google/angler/angler:6.0/MDA89D/2294819:userdebug/dev-keys'
ABI: 'arm'
Build type: optimized
Zygote loaded classes=3978 post zygote classes=27
Intern table: 45068 strong; 21 weak
JNI: CheckJNI is off; globals=283 (plus 360 weak)
Libraries: /system/lib/libandroid.so /system/lib/libcompiler_rt.so /system/lib/libjavacrypto.so /system/lib/libjnigraphics.so /system/lib/libmedia_jni.so /system/lib/libwebviewchromium_loader.so libjavacore.so (7)
Heap: 29% free, 21MB/30MB; 32251 objects
Dumping cumulative Gc timings
Total number of allocations 32251
Total bytes allocated 21MB
Total bytes freed 0B
Free memory 9MB
Free memory until GC 9MB
Free memory until OOME 490MB
Total memory 30MB
Max memory 512MB
Zygote space size 1260KB
Total mutator paused time: 0
Total time waiting for GC to complete: 0
Total GC count: 0
Total GC time: 0
Total blocking GC count: 0
Total blocking GC time: 0
suspend all histogram: Sum: 119.728ms 99% C.I. 0.010ms-107.765ms Avg: 5.442ms Max: 119.562ms
DALVIK THREADS (12):
"Signal Catcher" daemon prio=5 tid=2 Runnable
| group="system" sCount=0 dsCount=0 obj=0x12c400a0 self=0xef460000
| sysTid=30368 nice=0 cgrp=default sched=0/0 handle=0xf4a69930
| state=R schedstat=( 9021773 5500523 26 ) utm=0 stm=0 core=1 HZ=100
| stack=0xf496d000-0xf496f000 stackSize=1014KB
| held mutexes= "mutator lock"(shared held)
native: #00 pc 0035a217 /system/lib/libart.so (art::DumpNativeStack(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, int, char const*, art::ArtMethod*, void*)+126)
native: #01 pc 0033b03b /system/lib/libart.so (art::Thread::Dump(std::__1::basic_ostream<char, std::__1::char_traits<char> >&) const+138)
native: #02 pc 00344701 /system/lib/libart.so (art::DumpCheckpoint::Run(art::Thread*)+424)
native: #03 pc 00345265 /system/lib/libart.so (art::ThreadList::RunCheckpoint(art::Closure*)+200)
native: #04 pc 00345769 /system/lib/libart.so (art::ThreadList::Dump(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)+124)
native: #05 pc 00345e51 /system/lib/libart.so (art::ThreadList::DumpForSigQuit(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)+312)
native: #06 pc 0031f829 /system/lib/libart.so (art::Runtime::DumpForSigQuit(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)+68)
native: #07 pc 00326831 /system/lib/libart.so (art::SignalCatcher::HandleSigQuit()+896)
native: #08 pc 003270a1 /system/lib/libart.so (art::SignalCatcher::Run(void*)+324)
native: #09 pc 0003f813 /system/lib/libc.so (__pthread_start(void*)+30)
native: #10 pc 00019f75 /system/lib/libc.so (__start_thread+6)
(no managed stack frames)
"main" prio=5 tid=1 Suspended
| group="main" sCount=1 dsCount=0 obj=0x747552a0 self=0xf5376500
| sysTid=30363 nice=0 cgrp=default sched=0/0 handle=0xf74feb34
| state=S schedstat=( 331107086 164153349 851 ) utm=6 stm=27 core=3 HZ=100
| stack=0xff00f000-0xff011000 stackSize=8MB
| held mutexes=
kernel: __switch_to+0x7c/0x88
kernel: futex_wait_queue_me+0xd4/0x130
kernel: futex_wait+0xf0/0x1f4
kernel: do_futex+0xcc/0x8f4
kernel: compat_SyS_futex+0xd0/0x14c
kernel: cpu_switch_to+0x48/0x4c
native: #00 pc 000175e8 /system/lib/libc.so (syscall+28)
native: #01 pc 000f5ced /system/lib/libart.so (art::ConditionVariable::Wait(art::Thread*)+80)
native: #02 pc 00335353 /system/lib/libart.so (art::Thread::FullSuspendCheck()+838)
native: #03 pc 0011d3a7 /system/lib/libart.so (art::ClassLinker::LoadClassMembers(art::Thread*, art::DexFile const&, unsigned char const*, art::Handle<art::mirror::Class>, art::OatFile::OatClass const*)+746)
native: #04 pc 0011d81d /system/lib/libart.so (art::ClassLinker::LoadClass(art::Thread*, art::DexFile const&, art::DexFile::ClassDef const&, art::Handle<art::mirror::Class>)+88)
native: #05 pc 00132059 /system/lib/libart.so (art::ClassLinker::DefineClass(art::Thread*, char const*, unsigned int, art::Handle<art::mirror::ClassLoader>, art::DexFile const&, art::DexFile::ClassDef const&)+320)
native: #06 pc 001326c1 /system/lib/libart.so (art::ClassLinker::FindClassInPathClassLoader(art::ScopedObjectAccessAlreadyRunnable&, art::Thread*, char const*, unsigned int, art::Handle<art::mirror::ClassLoader>, art::mirror::Class**)+688)
native: #07 pc 002cb1a1 /system/lib/libart.so (art::VMClassLoader_findLoadedClass(_JNIEnv*, _jclass*, _jobject*, _jstring*)+264)
native: #08 pc 002847fd /data/dalvik-cache/arm/system@framework@boot.oat (Java_java_lang_VMClassLoader_findLoadedClass__Ljava_lang_ClassLoader_2Ljava_lang_String_2+112)
at java.lang.VMClassLoader.findLoadedClass!(Native method)
at java.lang.ClassLoader.findLoadedClass(ClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:499)
at java.lang.ClassLoader.loadClass(ClassLoader.java:469)
at android.app.ActivityThread.installProvider(ActivityThread.java:5141)
at android.app.ActivityThread.installContentProviders(ActivityThread.java:4748)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4688)
at android.app.ActivityThread.-wrap1(ActivityThread.java:-1)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1405)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:148)
at android.app.ActivityThread.main(ActivityThread.java:5417)
at java.lang.reflect.Method.invoke!(Native method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
- 查找死鎖
由于線程出現(xiàn)粘滯，死鎖往往首先表現(xiàn)為 ANR。如果系統(tǒng)服務(wù)器發(fā)生死鎖，監(jiān)控程序最終會(huì)將其終止，從而導(dǎo)致日志中出現(xiàn)類似以下的條目：WATCHDOG KILLING SYSTEM PROCESS。對(duì)于用戶來(lái)說(shuō)，看到的是設(shè)備重新啟動(dòng)，但從技術(shù)上來(lái)講這是運(yùn)行時(shí)重啟，而不是真正的設(shè)備重新啟動(dòng)。
要查找死鎖，請(qǐng)檢查 VM 跟蹤部分中是否存在以下模式：線程 A 在等待線程 B 占用的某些資源，而線程 B 也在等待線程 A 占用的某些資源。
日志范例如下：
"Binder_B" prio=5 tid=73 Blocked
| group="main" sCount=1 dsCount=0 obj=0x13faa0a0 self=0x95e24800
| sysTid=2016 nice=0 cgrp=default sched=0/0 handle=0x8b68d930
| state=S schedstat=( 9351576559 4141431119 16920 ) utm=819 stm=116 core=1 HZ=100
| stack=0x8b591000-0x8b593000 stackSize=1014KB
| held mutexes=
at com.android.server.pm.UserManagerService.exists(UserManagerService.java:387)
- waiting to lock <0x025f9b02> (a android.util.ArrayMap) held by thread 20
at com.android.server.pm.PackageManagerService.getApplicationInfo(PackageManagerService.java:2848)
at com.android.server.AppOpsService.getOpsRawLocked(AppOpsService.java:881)
at com.android.server.AppOpsService.getOpsLocked(AppOpsService.java:856)
at com.android.server.AppOpsService.noteOperationUnchecked(AppOpsService.java:719)
- locked <0x0231885a> (a com.android.server.AppOpsService)
at com.android.server.AppOpsService.noteOperation(AppOpsService.java:713)
at com.android.server.AppOpsService$2.getMountMode(AppOpsService.java:260)
at com.android.server.MountService$MountServiceInternalImpl.getExternalStorageMountMode(MountService.java:3416)
at com.android.server.am.ActivityManagerService.startProcessLocked(ActivityManagerService.java:3228)
at com.android.server.am.ActivityManagerService.startProcessLocked(ActivityManagerService.java:3170)
at com.android.server.am.ActivityManagerService.startProcessLocked(ActivityManagerService.java:3059)
at com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:1070)
- locked <0x044d166f> (a com.android.server.am.ActivityManagerService)
at com.android.server.am.ActivityManagerService.finishReceiver(ActivityManagerService.java:16950)
at android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:494)
at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:2432)
at android.os.Binder.execTransact(Binder.java:453)
"PackageManager" prio=5 tid=20 Blocked
| group="main" sCount=1 dsCount=0 obj=0x1304f4a0 self=0xa7f43900
| sysTid=1300 nice=10 cgrp=bg_non_interactive sched=0/0 handle=0x9fcf9930
| state=S schedstat=( 26190141996 13612154802 44357 ) utm=2410 stm=209 core=2 HZ=100
| stack=0x9fbf7000-0x9fbf9000 stackSize=1038KB
| held mutexes=
at com.android.server.AppOpsService.noteOperationUnchecked(AppOpsService.java:718)
- waiting to lock <0x0231885a> (a com.android.server.AppOpsService) held by thread 73
at com.android.server.AppOpsService.noteOperation(AppOpsService.java:713)
at com.android.server.AppOpsService$2.getMountMode(AppOpsService.java:260)
at com.android.server.AppOpsService$2.hasExternalStorage(AppOpsService.java:273)
at com.android.server.MountService$MountServiceInternalImpl.hasExternalStorage(MountService.java:3431)
at com.android.server.MountService.getVolumeList(MountService.java:2609)
at android.os.storage.StorageManager.getVolumeList(StorageManager.java:880)
at android.os.Environment$UserEnvironment.getExternalDirs(Environment.java:83)
at android.os.Environment.isExternalStorageEmulated(Environment.java:708)
at com.android.server.pm.PackageManagerService.isExternalMediaAvailable(PackageManagerService.java:9327)
at com.android.server.pm.PackageManagerService.startCleaningPackages(PackageManagerService.java:9367)
- locked <0x025f9b02> (a android.util.ArrayMap)
at com.android.server.pm.PackageManagerService$PackageHandler.doHandleMessage(PackageManagerService.java:1320)
at com.android.server.pm.PackageManagerService$PackageHandler.handleMessage(PackageManagerService.java:1122)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:148)
at android.os.HandlerThread.run(HandlerThread.java:61)
at com.android.server.ServiceThread.run(ServiceThread.java:46)
3.2 Activity 活動(dòng)
- 查看處于聚焦?fàn)顟B(tài)的 Activity
要查看記錄的處于聚焦?fàn)顟B(tài)的 Activity，請(qǐng)搜索 am_focused_activity。
日志范例如下：
grep "am_focused_activity" bugreport-2015-10-01-18-13-48.txt
10-01 18:10:41.409 4600 14112 I am_focused_activity: [0,com.google.android.GoogleCamera/com.android.camera.CameraActivity]
10-01 18:11:17.313 4600 5687 I am_focused_activity: [0,com.google.android.googlequicksearchbox/com.google.android.launcher.GEL]
10-01 18:11:52.747 4600 14113 I am_focused_activity: [0,com.google.android.GoogleCamera/com.android.camera.CameraActivity]
10-01 18:14:07.762 4600 5687 I am_focused_activity: [0,com.google.android.googlequicksearchbox/com.google.android.launcher.GEL]
- 查看進(jìn)程啟動(dòng)事件
要查看記錄的進(jìn)程啟動(dòng)事件，請(qǐng)搜索 Start proc。
日志范例如下：
grep "Start proc" bugreport-2015-10-01-18-13-48.txt
10-01 18:09:15.309 4600 4612 I ActivityManager: Start proc 24533:com.metago.astro/u0a240 for broadcast com.metago.astro/com.inmobi.commons.analytics.androidsdk.IMAdTrackerReceiver
10-01 18:09:15.687 4600 14112 I ActivityManager: Start proc 24548:com.google.android.apps.fitness/u0a173 for service com.google.android.apps.fitness/.api.services.ActivityUpsamplingService
10-01 18:09:15.777 4600 6604 I ActivityManager: Start proc 24563:cloudtv.hdwidgets/u0a145 for broadcast cloudtv.hdwidgets/cloudtv.switches.SwitchSystemUpdateReceiver
10-01 18:09:20.574 4600 6604 I ActivityManager: Start proc 24617:com.wageworks.ezreceipts/u0a111 for broadcast com.wageworks.ezreceipts/.ui.managers.IntentReceiver
- 設(shè)備是否發(fā)生系統(tǒng)顛簸
要確定設(shè)備是否發(fā)生系統(tǒng)顛簸，請(qǐng)檢查 am_proc_died 和 am_proc_start 前后在短時(shí)間內(nèi)是否出現(xiàn)活動(dòng)異常增加。
日志范例如下：
grep -e "am_proc_died" -e "am_proc_start" bugreport-2015-10-01-18-13-48.txt
10-01 18:07:06.494 4600 9696 I am_proc_died: [0,20074,com.android.musicfx]
10-01 18:07:06.555 4600 6606 I am_proc_died: [0,31166,com.concur.breeze]
10-01 18:07:06.566 4600 14112 I am_proc_died: [0,18812,com.google.android.apps.fitness]
10-01 18:07:07.018 4600 7513 I am_proc_start: [0,20361,10113,com.sony.playmemories.mobile,broadcast,com.sony.playmemories.mobile/.service.StartupReceiver]
10-01 18:07:07.357 4600 4614 I am_proc_start: [0,20381,10056,com.google.android.talk,service,com.google.android.talk/com.google.android.libraries.hangouts.video.CallService]
10-01 18:07:07.784 4600 4612 I am_proc_start: [0,20402,10190,com.andcreate.app.trafficmonitor:loopback_measure_serivce,service,com.andcreate.app.trafficmonitor/.loopback.LoopbackMeasureService]
10-01 18:07:10.753 4600 5997 I am_proc_start: [0,20450,10097,com.amazon.mShop.android.shopping,broadcast,com.amazon.mShop.android.shopping/com.amazon.identity.auth.device.storage.LambortishClock$ChangeTimestampsBroadcastReceiver]
10-01 18:07:15.267 4600 6605 I am_proc_start: [0,20539,10173,com.google.android.apps.fitness,service,com.google.android.apps.fitness/.api.services.ActivityUpsamplingService]
10-01 18:07:15.985 4600 4612 I am_proc_start: [0,20568,10022,com.android.musicfx,broadcast,com.android.musicfx/.ControlPanelReceiver]
10-01 18:07:16.315 4600 7512 I am_proc_died: [0,20096,com.google.android.GoogleCamera]
3.3 內(nèi)存異常
內(nèi)存不足可能會(huì)導(dǎo)致系統(tǒng)發(fā)生顛簸，這是因?yàn)殡m然內(nèi)存不足時(shí)系統(tǒng)會(huì)終止某些進(jìn)程來(lái)釋放內(nèi)存，但又會(huì)繼續(xù)啟動(dòng)其他進(jìn)程。要查看內(nèi)存不足的確鑿證據(jù)，請(qǐng)檢查二進(jìn)制事件日志中 am_proc_died 和 am_proc_start 條目的密集程度。
內(nèi)存不足還可能會(huì)減慢任務(wù)切換速度，并且可能會(huì)阻止進(jìn)行返回嘗試（因?yàn)橛脩魢L試返回到的任務(wù)已被終止）。如果啟動(dòng)器被終止，它會(huì)在用戶觸摸主屏幕按鈕時(shí)重啟，并且日志中會(huì)顯示啟動(dòng)器重新加載其內(nèi)容。
- 查看歷史指標(biāo)
二進(jìn)制事件日志中的 am_low_memory 條目表示最后一個(gè)緩存的進(jìn)程已終止。在此之后，系統(tǒng)開(kāi)始終止各項(xiàng)服務(wù)。
日志范例如下：
grep "am_low_memory" bugreport-2015-10-01-18-13-48.txt
10-01 18:11:02.219 4600 7513 I am_low_memory: 41
10-01 18:12:18.526 4600 14112 I am_low_memory: 39
10-01 18:12:18.874 4600 7514 I am_low_memory: 38
10-01 18:12:22.570 4600 14112 I am_low_memory: 40
10-01 18:12:34.811 4600 20319 I am_low_memory: 43
10-01 18:12:37.945 4600 6521 I am_low_memory: 43
10-01 18:12:47.804 4600 14110 I am_low_memory: 43
- 查看系統(tǒng)顛簸指標(biāo)
關(guān)于系統(tǒng)顛簸（分頁(yè)、直接回收等）的其他指標(biāo)包括 kswapd、kworker 和 mmcqd 消耗的 CPU 周期。
日志范例如下：
CPU INFO (top -n 1 -d 1 -m 30 -t)
User 15%, System 54%, IOW 28%, IRQ 0%
User 82 + Nice 2 + Sys 287 + Idle 1 + IOW 152 + IRQ 0 + SIRQ 5 = 529
PID TID PR CPU% S VSS RSS PCY UID Thread Proc
15229 15229 0 19% R 0K 0K fg root kworker/0:2
29512 29517 1 7% D 1173524K 101188K bg u0_a27 Signal Catcher com.google.android.talk
24565 24570 3 6% D 2090920K 145168K fg u0_a22 Signal Catcher com.google.android.googlequicksearchbox:search
19525 19525 2 6% R 3476K 1644K fg shell top top
24957 24962 2 5% R 1706928K 125716K bg u0_a47 Signal Catcher com.google.android.GoogleCamera
19519 19519 3 4% S 0K 0K fg root kworker/3:1
120 120 0 3% S 0K 0K fg root mmcqd/1
18233 18233 1 3% S 0K 0K fg root kworker/1:1
25589 25594 1 2% D 1270476K 75776K fg u0_a8 Signal Catcher com.google.android.gms
19399 19399 2 1% S 0K 0K fg root kworker/2:2
1963 1978 1 0% S 1819100K 125136K fg system android.fg system_server
1963 1981 3 0% S 1819100K 125136K fg system android.display system_server
- 獲取內(nèi)存快照
內(nèi)存快照是一種 dumpstate，其中會(huì)列出正在運(yùn)行的 Java 進(jìn)程和本機(jī)進(jìn)程.
日志范例如下：
Total PSS by OOM adjustment:
86752 kB: Native
22645 kB: surfaceflinger (pid 197)
18597 kB: mediaserver (pid 204)
136959 kB: System
136959 kB: system (pid 785)
220218 kB: Persistent
138859 kB: com.android.systemui (pid 947 / activities)
39178 kB: com.android.nfc (pid 1636)
28313 kB: com.android.phone (pid 1659)
13868 kB: com.redbend.vdmc (pid 1646)
9534 kB: Persistent Service
9534 kB: com.android.bluetooth (pid 23807)
178604 kB: Foreground
168620 kB: com.google.android.googlequicksearchbox (pid 1675 / activities)
9984 kB: com.google.android.apps.maps (pid 13952)
188286 kB: Visible
85326 kB: com.google.android.wearable.app (pid 1535)
38978 kB: com.google.process.gapps (pid 1510)
31936 kB: com.google.android.gms.persistent (pid 2072)
27950 kB: com.google.android.gms.wearable (pid 1601)
4096 kB: com.google.android.googlequicksearchbox:interactor (pid 1550)
52948 kB: Perceptible
52948 kB: com.google.android.inputmethod.latin (pid 1566)
150851 kB: A Services
81121 kB: com.google.android.gms (pid 1814)
37586 kB: com.google.android.talk (pid 9584)
10949 kB: com.google.android.music:main (pid 4019)
10727 kB: com.motorola.targetnotif (pid 31071)
10468 kB: com.google.android.GoogleCamera (pid 9984)
33298 kB: Previous
33298 kB: com.android.settings (pid 9673 / activities)
165188 kB: B Services
49490 kB: com.facebook.katana (pid 15035)
22483 kB: com.whatsapp (pid 28694)
21308 kB: com.iPass.OpenMobile (pid 5325)
19788 kB: com.google.android.apps.googlevoice (pid 23934)
17399 kB: com.google.android.googlequicksearchbox:search (pid 30359)
9073 kB: com.google.android.apps.youtube.unplugged (pid 21194)
7660 kB: com.iPass.OpenMobile:remote (pid 23754)
7291 kB: com.pujie.wristwear.pujieblack (pid 24240)
7157 kB: com.instagram.android:mqtt (pid 9530)
3539 kB: com.qualcomm.qcrilmsgtunnel (pid 16186)
204324 kB: Cached
43424 kB: com.amazon.mShop.android (pid 13558)
22563 kB: com.google.android.apps.magazines (pid 13844)
4298 kB: com.google.android.apps.enterprise.dmagent (pid 13826)
3.4 電源
事件日志中包含屏幕電源狀態(tài)，其中 0 表示屏幕關(guān)閉，1 表示屏幕打開(kāi)，2 表示已鎖屏。
日志范例如下：
grep screen_toggled bugreport-2015-10-18-16-52-22.txt
10-18 15:05:04.383 992 992 I screen_toggled: 1
10-18 15:05:07.010 992 992 I screen_toggled: 0
10-18 15:23:15.063 992 992 I screen_toggled: 1
10-18 15:23:25.684 992 992 I screen_toggled: 0
10-18 15:36:31.623 992 992 I screen_toggled: 1
10-18 15:36:37.660 3283 3283 I screen_toggled: 2
錯(cuò)誤報(bào)告中還包含關(guān)于喚醒鎖的統(tǒng)計(jì)信息，喚醒鎖是應(yīng)用開(kāi)發(fā)者采用的一種機(jī)制，用于表明其應(yīng)用需要設(shè)備保持開(kāi)啟狀態(tài)。喚醒鎖總時(shí)長(zhǎng)統(tǒng)計(jì)信息僅跟蹤喚醒鎖實(shí)際負(fù)責(zé)使設(shè)備保持喚醒狀態(tài)的時(shí)間，不包括屏幕處于開(kāi)啟狀態(tài)的時(shí)間。此外，如果同時(shí)持有多個(gè)喚醒鎖，系統(tǒng)會(huì)在它們之間分配喚醒鎖時(shí)長(zhǎng)。
4. 小結(jié)
本節(jié)課程我們主要學(xué)習(xí)了如何獲取和分析錯(cuò)誤報(bào)告。本節(jié)課程的重點(diǎn)如下：
- 掌握如何獲取錯(cuò)誤報(bào)告；
- 掌握如何分析常見(jiàn)日志。
2025 imooc.com All Rights Reserved |