اشکالات در هر نوع توسعه یک واقعیت هستند - و گزارش های باگ برای شناسایی و حل مشکلات حیاتی هستند. همه نسخههای اندروید از ثبت گزارشهای باگ با پل اشکالزدایی اندروید (adb) پشتیبانی میکنند. نسخههای اندروید 4.2 و بالاتر از گزینه توسعهدهنده برای دریافت گزارشهای اشکال و اشتراکگذاری از طریق ایمیل، Drive و غیره پشتیبانی میکنند.
گزارشهای باگ Android حاوی دادههای dumpsys
، dumpstate
و logcat
در قالب متن (txt.) است که به شما امکان میدهد به راحتی محتوای خاصی را جستجو کنید. بخشهای زیر اجزای گزارش اشکال را به تفصیل شرح میدهند، مشکلات رایج را شرح میدهند، و نکات مفید و دستورات grep
را برای یافتن گزارشهای مرتبط با آن اشکالات ارائه میدهند. بیشتر بخش ها همچنین شامل نمونه هایی برای دستور و خروجی grep
و/یا خروجی dumpsys
هستند.
لاگ logcat
یک تخلیه مبتنی بر رشته از تمام اطلاعات logcat
است. بخش سیستم برای چارچوب رزرو شده است و تاریخچه طولانی تری نسبت به اصلی دارد که شامل همه چیزهای دیگر است. هر خط معمولاً با timestamp UID PID TID log-level
شروع میشود، اگرچه UID
ممکن است در نسخههای قدیمیتر Android فهرست نشده باشد.
این گزارش شامل نمایش رشتهای از پیامهای لاگ با فرمت باینری است. سر و صدای کمتری نسبت به logcat
log دارد اما خواندن آن کمی سخت تر است. هنگام مشاهده گزارشهای رویداد، میتوانید این بخش را برای شناسه فرآیند خاص (PID) جستجو کنید تا ببینید یک فرآیند در حال انجام چه کاری است. قالب اصلی این است: timestamp PID TID log-level log-tag tag-values
.
سطوح گزارش شامل موارد زیر است:
- V: پرحرف
- د: اشکال زدایی
- من: اطلاعات
- W: هشدار
- ه: خطا
برای سایر برچسبهای گزارش رویداد مفید، به /services/core/java/com/android/server/EventLogTags.logtags مراجعه کنید.
گزارشهای اشکال میتوانند به شما کمک کنند تا بفهمید چه چیزی باعث خطاهای Application Not Responding (ANR) و رویدادهای بن بست میشود.
هنگامی که یک برنامه در مدت زمان معینی پاسخ نمی دهد، معمولاً به دلیل یک رشته اصلی مسدود شده یا شلوغ، سیستم فرآیند را از بین می برد و پشته را به /data/anr
می اندازد. برای کشف مقصر پشت ANR، برای am_anr
در گزارش رویداد باینری grep کنید.
شما همچنین می توانید برای ANR in
در گزارش logcat
که حاوی اطلاعات بیشتری در مورد آنچه از CPU در زمان ANR استفاده می کرد، grep کنید.
اغلب میتوانید ردیابی پشتهای را پیدا کنید که با یک ANR مطابقت دارد. مطمئن شوید که مهر زمانی و PID روی ردیابی های VM با ANR مورد بررسی شما مطابقت دارند، سپس رشته اصلی فرآیند را بررسی کنید. به خاطر داشته باشید:
- رشته اصلی فقط به شما می گوید که رشته در زمان ANR چه کار می کرد، که ممکن است با علت واقعی ANR مطابقت داشته باشد یا نباشد. (پشته در گزارش اشکال ممکن است بی گناه باشد؛ چیز دیگری ممکن است برای مدت طولانی گیر کرده باشد - اما نه به اندازه کافی برای ANR - قبل از اینکه گیر کند.)
- ممکن است بیش از یک مجموعه ردیابی پشته (
VM TRACES JUST NOW
وVM TRACES AT LAST ANR
) وجود داشته باشد. مطمئن شوید که بخش صحیح را مشاهده می کنید.
بنبستها اغلب ابتدا بهعنوان ANR ظاهر میشوند، زیرا رشتهها گیر میکنند. اگر بن بست به سرور سیستم برخورد کند، ناظر در نهایت آن را می کشد، که منجر به ورودی مشابهی در گزارش می شود: WATCHDOG KILLING SYSTEM PROCESS
. از دیدگاه کاربر، دستگاه راهاندازی مجدد میشود، اگرچه از نظر فنی این یک راهاندازی مجدد در زمان اجراست تا راهاندازی مجدد واقعی.
- در یک راه اندازی مجدد در زمان اجرا ، سرور سیستم می میرد و دوباره راه اندازی می شود. کاربر می بیند که دستگاه به انیمیشن بوت باز می گردد.
- در راه اندازی مجدد ، هسته از کار افتاده است. کاربر می بیند که دستگاه به لوگوی بوت گوگل باز می گردد.
برای یافتن بنبستها، بخشهای Traces VM را برای الگوی thread A که در انتظار چیزی است که توسط thread B نگهداری میشود، بررسی کنید، که به نوبه خود در انتظار چیزی است که توسط thread A نگهداری میشود.
اکتیویتی جزء برنامهای است که به کاربران صفحهنمایش را برای انجام کاری مانند شمارهگیری، عکس گرفتن، ارسال ایمیل و غیره فراهم میکند. ، که مکان یابی فعالیتی را که در حین تصادف در کانون توجه بوده است بسیار مهم می کند. فعالیتها (از طریق ActivityManager) فرآیندها را اجرا میکنند، بنابراین مکانیابی تمام فرآیندها برای یک فعالیت معین متوقف و شروع میشود، همچنین میتواند به عیبیابی کمک کند.
برای مشاهده سابقه فعالیت های متمرکز، am_focused_activity
را جستجو کنید.
برای مشاهده تاریخچه شروع فرآیند، Start proc
جستجو کنید.
برای تعیین اینکه آیا دستگاه در حال ضربه زدن است یا خیر، افزایش غیرعادی فعالیت در اطراف am_proc_died
و am_proc_start
را در مدت زمان کوتاهی بررسی کنید.
از آنجایی که دستگاه های اندرویدی اغلب حافظه فیزیکی محدودی دارند، مدیریت حافظه با دسترسی تصادفی (RAM) بسیار مهم است. گزارشهای باگ حاوی چندین نشانگر از حافظه کم و همچنین یک فضای خالی است که یک عکس فوری از حافظه ارائه میدهد.
حافظه کم می تواند باعث از بین رفتن سیستم شود زیرا برخی از فرآیندها را از بین می برد تا حافظه آزاد شود اما به شروع فرآیندهای دیگر ادامه می دهد. برای مشاهده شواهد تأییدکننده حافظه کم، غلظت ورودیهای am_proc_died
و am_proc_start
را در گزارش رویداد باینری بررسی کنید.
حافظه کم همچنین میتواند تعویض کار را کند کند و تلاشهای بازگشت را خنثی کند (زیرا وظیفهای که کاربر میخواست به آن بازگردد کشته شد). اگر لانچر کشته شد، زمانی که کاربر دکمه هوم را لمس میکند، دوباره راهاندازی میشود و گزارشها نشان میدهند که لانچر محتوای خود را دوباره بارگذاری میکند.
ورودی am_low_memory
در گزارش رویداد باینری نشان میدهد که آخرین فرآیند ذخیرهسازی شده از بین رفته است. پس از این، سیستم شروع به کشتن خدمات می کند.
سایر شاخصهای thrashing سیستم (صفحهبندی، بازیابی مستقیم و غیره) شامل چرخههای مصرف kswapd
، kworker
و mmcqd
است. (به خاطر داشته باشید که گزارش اشکال جمع آوری شده می تواند بر شاخص های thrashing تأثیر بگذارد.)
گزارشهای ANR میتوانند عکس فوری حافظه مشابهی ارائه دهند.
عکس فوری حافظه یک انبار زباله است که فرآیندهای جاوا و بومی در حال اجرا را فهرست می کند (برای جزئیات، به مشاهده تخصیص کلی حافظه مراجعه کنید). به خاطر داشته باشید که عکس فوری فقط وضعیت را در یک لحظه خاص از زمان نشان می دهد. سیستم ممکن است قبل از عکس فوری در شکل بهتر (یا بدتر) بوده باشد.
- برای درک مدت زمان اجرای یک فرآیند، به زمان اجرای فرآیند مراجعه کنید.
- برای درک اینکه چرا چیزی در حال حاضر در حال اجرا است، به چرا یک فرآیند در حال اجرا است؟
برنامه ها برای ارسال رویدادها در برنامه فعلی یا به برنامه دیگر، پخش پخش می کنند. گیرنده های پخش مشترک پیام های خاصی (از طریق فیلترها) می شوند و آنها را قادر می سازد هم به یک پخش گوش دهند و هم به آن پاسخ دهند. گزارشهای باگ حاوی اطلاعاتی در مورد پخشهای ارسال شده و پخشهای ارسالنشده، و همچنین محتویات همه گیرندههایی است که به پخش خاصی گوش میدهند.
پخشهای تاریخی آنهایی هستند که قبلاً ارسال شدهاند و به ترتیب زمانی معکوس فهرست شدهاند.
بخش خلاصه مروری بر 300 آخرین پخش پیش زمینه و آخرین 300 پخش پس زمینه است.
بخش جزئیات حاوی اطلاعات کاملی برای آخرین 50 پخش پیش زمینه و 50 آخرین پخش پس زمینه و همچنین گیرنده های هر پخش است. گیرنده هایی که دارای:
- ورودی
BroadcastFilter
در زمان اجرا ثبت می شود و فقط به فرآیندهای در حال اجرا ارسال می شود. - ورودی
ResolveInfo
از طریق ورودی های مانیفست ثبت می شود. ActivityManager فرآیند را برای هرResolveInfo
در صورتی که قبلاً اجرا نشده است شروع می کند.
پخش های فعال آنهایی هستند که هنوز ارسال نشده اند. تعداد زیاد در صف به این معنی است که سیستم نمی تواند به اندازه کافی سریع پخش ها را ارسال کند تا ادامه یابد.
برای مشاهده لیستی از گیرنده هایی که برای پخش گوش می دهند، جدول Resolver Resolver را در dumpsys activity broadcasts
بررسی کنید. مثال زیر همه گیرندههایی را نشان میدهد که به USER_PRESENT
گوش میدهند.
ثبت اختلافات مانیتور گاهی اوقات می تواند نشان دهنده اختلاف واقعی مانیتور باشد، اما اغلب نشان می دهد که سیستم به قدری بارگذاری شده است که همه چیز کند شده است. ممکن است رویدادهای مانیتور طولانی ثبت شده توسط ART را در گزارش سیستم یا رویداد مشاهده کنید.
در گزارش سیستم:
10-01 18:12:44.343 29761 29914 W art : Long monitor contention event with owner method=void android.database.sqlite.SQLiteClosable.acquireReference() from SQLiteClosable.java:52 waiters=0 for 3.914s
در گزارش رویداد:
10-01 18:12:44.364 29761 29914 I dvm_lock_sample: [com.google.android.youtube,0,pool-3-thread-9,3914,ScheduledTaskMaster.java,138,SQLiteClosable.java,52,100]
کامپایل می تواند گران باشد و دستگاه را بارگیری کند.
هنگام بارگیری بهروزرسانیهای فروشگاه Google Play، ممکن است گردآوری در پسزمینه رخ دهد. در این مورد، پیامهای برنامه فروشگاه Google Play ( finsky
) و installd
قبل از پیامهای dex2oat
ظاهر میشوند.
هنگامی که یک برنامه در حال بارگذاری یک فایل dex است که هنوز کامپایل نشده است، کامپایل ممکن است در پس زمینه رخ دهد. در این صورت، finsky
یا لاگ installd
را مشاهده نخواهید کرد.
ایجاد روایت یک مشکل (چگونه شروع شد، چه اتفاقی افتاد، سیستم چگونه واکنش نشان داد) مستلزم یک جدول زمانی دقیق از رویدادها است. میتوانید از اطلاعات گزارش اشکال برای همگامسازی خطوط زمانی در چندین گزارش و تعیین مهر زمانی دقیق گزارش اشکال استفاده کنید.
گزارش اشکال چندین جدول زمانی موازی را منعکس می کند: گزارش سیستم، گزارش رویداد، گزارش هسته، و چندین جدول زمانی تخصصی برای پخش، آمار باتری، و غیره. متأسفانه، خطوط زمانی اغلب با استفاده از پایگاه های زمانی مختلف گزارش می شوند.
مُهرهای زمان سیستم و گزارش رویداد در همان منطقه زمانی کاربر هستند (همانطور که بیشتر مُهرهای زمانی دیگر). به عنوان مثال، هنگامی که کاربر روی دکمه خانه ضربه میزند، گزارش سیستم گزارش میدهد:
10-03 17:19:52.939 1963 2071 I ActivityManager: START u0 {act=android.intent.action.MAIN cat=[android.intent.category.HOME] flg=0x10200000 cmp=com.google.android.googlequicksearchbox/com.google.android.launcher.GEL (has extras)} from uid 1000 on display 0
برای همان اقدام، گزارش رویداد گزارش می دهد:
10-03 17:19:54.279 1963 2071 I am_focused_activity: [0,com.google.android.googlequicksearchbox/com.google.android.launcher.GEL]
گزارشهای هسته ( dmesg
) از یک پایگاه زمانی متفاوت استفاده میکنند و آیتمهای گزارش را با چند ثانیه پس از اتمام بوتلودر برچسبگذاری میکنند. برای ثبت این بازه زمانی در سایر مقیاسهای زمانی، پیامهای suspend exit و suspend entry را جستجو کنید:
<6>[201640.779997] PM: suspend exit 2015-10-03 19:11:06.646094058 UTC … <6>[201644.854315] PM: suspend entry 2015-10-03 19:11:10.720416452 UTC
از آنجایی که لاگهای هسته ممکن است شامل زمان در حالت تعلیق نباشند، باید لاگ را بین پیامهای ورودی و خروجی تعلیق ثبت کنید. علاوه بر این، گزارشهای هسته از منطقه زمانی UTC استفاده میکنند و باید با منطقه زمانی کاربر تنظیم شوند.
برای تعیین اینکه چه زمانی یک گزارش اشکال گرفته شده است، ابتدا گزارش سیستم (Logcat) را برای dumpstate: begin
:
10-03 17:19:54.322 19398 19398 I dumpstate: begin
در مرحله بعد، مهرهای زمانی گزارش هسته ( dmesg
) را برای پیام Starting service 'bugreport'
بررسی کنید:
<5>[207064.285315] init: Starting service 'bugreport'...
برای ارتباط بین این دو رویداد، به عقب کار کنید و اخطارهای ذکر شده در خطوط زمانی همگام سازی را در نظر داشته باشید. در حالی که بعد از شروع گزارش اشکال، اتفاقات زیادی می افتد، اکثر فعالیت ها چندان مفید نیستند زیرا عمل گرفتن گزارش اشکال سیستم را به طور قابل توجهی بارگیری می کند.
گزارش رویداد حاوی وضعیت برق صفحه است، که در آن 0 صفحه نمایش خاموش، 1 صفحه نمایش روشن، و 2 برای صفحه کلید تمام شده است.
گزارشهای باگ همچنین حاوی آماری درباره wake lock هستند، مکانیزمی که توسط توسعهدهندگان برنامهها برای نشان دادن نیاز برنامههایشان به روشن ماندن دستگاه استفاده میشود. (برای جزئیات بیشتر در مورد wake lock، به PowerManager.WakeLock مراجعه کنید و CPU را روشن نگه دارید .)
آمار انبوه مدت زمان wake lock تنها زمانی را که wake lock واقعاً مسئول بیدار نگه داشتن دستگاه است ردیابی می کند و زمان روشن بودن صفحه را در بر نمی گیرد. علاوه بر این، اگر چندین wake lock به طور همزمان نگه داشته شوند، مدت زمان wake lock بین آن wake lock ها توزیع می شود.
برای کمک بیشتر به تجسم وضعیت انرژی، از Battery Historian ، یک ابزار منبع باز Google برای تجزیه و تحلیل مصرف کنندگان باتری با استفاده از فایل های گزارش اشکال Android استفاده کنید.
بخش DUMP OF SERVICE package
شامل نسخه های برنامه (و سایر اطلاعات مفید) است.
گزارشهای اشکال حاوی حجم عظیمی از دادهها برای فرآیندها، از جمله زمان شروع و توقف، طول زمان اجرا، خدمات مرتبط، امتیاز oom_adj
و غیره است. برای جزئیات در مورد نحوه مدیریت فرآیندها، به Processes و Threads مراجعه کنید.
بخش procstats
حاوی آمار کاملی از مدت زمان اجرای فرآیندها و خدمات مرتبط است. برای خلاصهای سریع و قابل خواندن برای انسان، AGGREGATED OVER
جستجو کنید تا دادههای سه یا 24 ساعت گذشته را مشاهده کنید، سپس Summary:
فهرستی از فرآیندها، مدت زمانی که این فرآیندها در اولویتهای مختلف اجرا شدهاند و RAM آنها. فرمت استفاده به صورت حداقل میانگین حداکثر PSS/دقیقه میانگین حداکثر USS.
بخش dumpsys activity processes
فهرستی از تمام فرآیندهای در حال اجرا در حال اجرا را به ترتیب با امتیاز oom_adj
فهرست میکند (اندروید اهمیت فرآیند را با اختصاص دادن مقدار oom_adj
به فرآیند نشان میدهد که میتواند به صورت پویا توسط ActivityManager بهروزرسانی شود). خروجی شبیه به یک عکس فوری حافظه است، اما شامل اطلاعات اضافی در مورد آنچه باعث اجرای فرآیند می شود. در مثال زیر، ورودیهای پررنگ نشان میدهند که فرآیند gms.persistent
با اولویت vis
(قابل مشاهده) اجرا میشود، زیرا فرآیند سیستم به NetworkLocationService
آن متصل است.
برای شناسایی برنامههایی که اسکنهای بیش از حد کم انرژی بلوتوث (BLE) انجام میدهند، از مراحل زیر استفاده کنید:
- یافتن پیام های گزارش برای
BluetoothLeScanner
:$ grep 'BluetoothLeScanner' ~/downloads/bugreport.txt 07-28 15:55:19.090 24840 24851 D BluetoothLeScanner: onClientRegistered() - status=0 clientIf=5
- PID را در پیام های گزارش پیدا کنید. در این مثال، "24840" و "24851" PID (شناسه فرآیند) و TID (شناسه رشته) هستند.
- برنامه مرتبط با PID را پیدا کنید:
PID #24840: ProcessRecord{4fe996a 24840:com.badapp/u0a105}
در این مثال، نام بسته
com.badapp
است. - برای شناسایی برنامه مسئول، نام بسته را در Google Play جستجو کنید: https://play.google.com/store/apps/details?id=com.badapp .
توجه : برای دستگاههایی که Android 7.0 دارند، سیستم دادهها را برای اسکنهای BLE جمعآوری میکند و این فعالیتها را با برنامه شروعکننده مرتبط میکند. برای جزئیات، به اسکنهای کم انرژی (LE) و بلوتوث مراجعه کنید.