طرق متابعة Crash في iOS بشكل عام وكيفية تعريف Bugly

طرق تتبع إصطدام iOS بشكل تقليدي وتطبيق Bugly

عندما يحدث إصطدام التطبيق، في المرحلة التطويرية يمكن تتبع معلومات الإصطدام بالطرق التالية

#1. تشغيل المحاكي، عرض سجلات الأخطاء في Xcode

#2. تتبع الهاتف الحقيقي، عرض سجلات الأخطاء في Xcode

#3. تشغيل الهاتف الحقيقي، عرض سجلات النظام في device

　لإعطاء مثال، أكتب كودًا سيؤدي إلى إصطدامcrashdemo:

- (void)viewDidLoad {
  [super viewDidLoad];
  // Do any additional setup after loading the view, typically from a nib.
  [self performSelector:@selector(print) withObject:nil afterDelay:5];
}
- (void)print {
  NSArray *array = @[];
  NSLog(@"%@", array[1]);
}

Demo#1. تشغيل المحاكي، عرض سجلات الأخطاء في Xcode

بعد تنفيذ البرنامج سيحدث إصطدام فوري، يمكنك فتح سجلات النظام في Xcode لرؤية الأخطاء التالية

2016-10-29 12:13:29.015 CrashDemo[37842:7436441] *** تنهية التطبيق بسبب استثناء غير محدد 'NSRangeException'، السبب: '*** -[__NSArray0 objectAtIndex:]: index 1 beyond bounds for empty NSArray'
*** قائمة الاستدعاءات الأولى:
(
  0  CoreFoundation           0x00b7ba84 __exceptionPreprocess + 180
  1  libobjc.A.dylib           0x00642e02 objc_exception_throw + 50
  2  CoreFoundation           0x00b22390 __CFArrayGetTypeID_block_invoke + 0
  3  CoreFoundation           0x00ac07f8 -[NSArray objectAtIndexedSubscript:] + 40
  4  CrashDemo              0x000877b7 -[ViewController print] + 87
  5  Foundation             0x00250d71 __NSFireDelayedPerform + 442
  6  CoreFoundation           0x00acd576 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 22
  7  CoreFoundation           0x00accf72 __CFRunLoopDoTimer + 1250
  8  CoreFoundation           0x00a8b25a __CFRunLoopRun + 2202
  9  CoreFoundation           0x00a8a706 CFRunLoopRunSpecific + 470
  10 CoreFoundation           0x00a8a51b CFRunLoopRunInMode + 123
  11 GraphicsServices          0x041e4664 GSEventRunModal + 192
  12 GraphicsServices          0x041e44a1 GSEventRun + 104
  13 UIKit                0x00f0c1eb UIApplicationMain + 160
  14 CrashDemo              0x00087bba main + 138
  15 libdyld.dylib            0x03189a21 start + 1
)
libc++abi.dylib: ينتهي التشغيل غير المكتشف الاستثناء من نوع NSException
(lldb) 

من خلال سجلات xcode يمكننا رؤية أن هناك تجاوز حدود في الوصول إلى البنية، ويُدعى طريقة حدوث التجاوز print

بالنسبة لهذا demo نحن بالطبع نعرف أن array[1] التي قمنا بتحديدها هي التي حدثت فيها تجاوز الحدود، لكن كيف يمكننا معرفة مكان حدوث تجاوز الحدود في برنامج كامل؟

في هذه اللحظة يمكننا استخدام ميزة Show the breakpoint navigator الخاصة بـ xcode، النقر على زر plus لتحديد add exception breakpoint

في هذه اللحظة، عند تنفيذ البرنامج، سيقوم xcode بالتوقف تلقائيًا عند السطر الذي سيحدث فيه الانهيار

Demo#2. الت调试 على الهاتف الاصل، عرض سجلات الأخطاء في xcode
إذا تم إضافة نقطة توقيف الاستثناء، فإن البرنامج سيقف تلقائيًا عند سطر طباعة array[1]. إذا لم يتم إضافة أي نقطة توقيف، فإن البرنامج سيقوم بالانهيار، وسيظهر xcode سجلات خطأ كما يلي

2016-10-29 12:15:53.561 CrashDemo[1062:316582] *** تنهي التطبيق بسبب استثناء غير مكتشف 'NSRangeException'، السبب: '*** -[__NSArray0 objectAtIndex:]: index 1 beyond bounds for empty NSArray'
*** قائمة الاستدعاءات الأولى:
(0x211b398b 0x2094ee17 0x211433e7 0xc5a3b 0x219d1ad5 0x211765ff 0x21176231 0x2117407d 0x210c32e9 0x210c30d5 0x226b3ac9 0x257880b9 0xc5c99 0x20d6b873)
libc++abi.dylib: ينتهي التشغيل غير المكتشف الاستثناء من نوع NSException
(lldb) 

من خلال معلومات الخطأ يمكننا رؤية أن هناك زيادة في نطاق الوصول إلى المصفوفة، إذا تم إضافة نقطة توقيف الاستثناء فإنها ستتوقف تلقائيًا عند سطر الخطأ.

　Demo#3. تشغيل على الهاتف الاصل، عرض سجلات النظام للأجهزة

توقف xcode عن تشغيل crashdemo، اختر نافذة xcode - الأجهزة، اختر الهاتف - عرض سجلات الأجهزة

ثم تشغيل crashdemo على الهاتف، في سجلات الأجهزة قم بترتيب الأحداث حسب الوقت لرؤية سجلات التشغيل الأخيرة لـ crashdemo

مُعرف الحدث: 9A4C52F0-B0D7-42C9-A7CB-D4D3321D00D5
مفتاح مُسجل التشغيل: 90f4d3621773443794fa73f506fd6bdef49fc269
نموذج الأجهزة: iPhone4,1
العمليات:       CrashDemo [1074]
المسار:        /private/var/containers/Bundle/Application/1307034E-9C2B-451F-ACD9-04C97DEC047B/CrashDemo.app/CrashDemo
المعرف:     PEGA.CrashDemo
الإصدار:       1 (1.0)
نوع الكود:      ARM (Native)
العمليات الأم:   launchd [1]
التاريخ/الوقت:      2016-10-29 12:21:49.49 +0800
وقت التشغيل:     2016-10-29 12:21:43.43 +0800
إصدار النظام:     iOS 9.3.1 (13E238)
إصدار التقرير:   104
نوع الاستثناء: EXC_CRASH (SIGABRT)
كود الاستثناء: 0x0000000000000000, 0x0000000000000000
ملاحظة الاستثناء: EXC_CORPSE_NOTIFY
تم إطلاق هذا الاستثناء بواسطة Thread: 0
syslog مصفى:
لا توجد نتائج
آخر استثناء التتبع:
0  CoreFoundation          0x211b3986 __exceptionPreprocess + 122
1  libobjc.A.dylib          0x2094ee12 objc_exception_throw + 34
2  CoreFoundation          0x211433e2 -[__NSArray0 objectAtIndex:] + 110
3  CrashDemo             0x000e6a36 0xe0000 + 27190
4  Foundation            0x219d1ad0 __NSFireDelayedPerform + 464
5  CoreFoundation          0x211765fa 

يمكن تنفيذ هذه الأمور بسهولة في مرحلة التطوير، ولكن ماذا إذا حدث تحطم للمستخدم بعد إصدار التطبيق؟ عادةً يمكن للمستخدم فقط إرسال ملاحظات حول ما كان يفعله عندما حدث التحطم

ثم نحاول تجربة ما إذا كان يمكننا مواجهة هذه المشكلة، ولكن هذا غير فعال جدًا وغالبًا ما يكون من الصعب إعادة إنتاج تحطم المستخدم

يحل Bugly هذه المشكلة

يتم إرسال معلومات الخطأ تلقائيًا إلى الخادم عند تحطم البرنامج بواسطة Bugly SDK، مما يسهل على المطورين مراجعة وتحليل الأخطاء

إذن كيف يمكن استخدام Bugly؟

أولاً، قم بزيارة https://bugly.qq.com/v2/ للتسجيل في حساب، ثم سجّل التطبيق لتنزيل SDK

أحضر Bugly.framework إلى المشروع، لا تنسى اختيار copy if needed.

ثم أضف libz.tbd / libstdc++.tbd / Security.framework / SystemConfiguration.framework إلى المشروع

تسجيل في delegate.m

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { 
    [Bugly startWithAppId:@"إسحب هنا معرف التطبيق الخاص بك"]; 
    return YES; 
 }

بهذا، عند تحطم البرنامج، سيتم إرسال معلومات التحطم تلقائيًا إلى الخادم، ويمكنك التحقق من حساب bugly الخاص بك للحصول على المعلومات

　

　شكرًا على القراءة، آمل أن تكون مفيدًا للجميع، شكرًا لدعمكم لموقعنا!