MetricKit. تحليل أداء تطبيقات iOS

لعبة جديدة

نستمر في تعريف أنفسنا بالمواد الجديدة من Apple المقدمة في WWDC. هذه المرة ، خذ بعين الاعتبار MetricKit ، إطار عمل جديد تمامًا يعمل كأداة لمراقبة أداء التطبيقات.

يعلم الجميع أن قياس أداء التطبيق أثناء التطوير أمر سهل. يُظهر Xcode مقدار ذاكرة الوصول العشوائي المستخدمة وتحميل المعالج ، ويمكنك الاتصال باستخدام Instruments إلى جهاز محاكاة أو جهاز قيد الاختبار وحتى كتابة أدواتك الخاصة (لمزيد من التفاصيل ، راجع مقالاتنا على حزم الأدوات المخصصة: الجزء 1 / الجزء 2 ). إن فهم أهمية ضبط الأداء لا يسمح لك بقياس كل ما يفعله التطبيق تقريبًا. لكن الأمور تصبح أكثر تعقيدًا عندما نتحدث عن AppStore ، إذا كان التطبيق المطور مخصصًا للمستخدمين الحقيقيين. بغض النظر عن مدى دقة اختبار التطبيق الخاص بك ، في الظروف الحقيقية سيكون هناك دائمًا مجموعة من المفاجآت التي ستؤثر على الأداء وتجربة المستخدم. بالطبع ، هناك العديد من الأدوات لجمع المعلمات المتنوعة ، ولكن معظمها محدود بواسطة iK SDK ، وكذلك تأثير المراقبة الفعلية على سلوك التطبيق.

قررت Apple هذا العام ملء هذه الفجوة وتزويد المطورين بأداة تساعدهم على جمع وتحليل مقاييس أداء التطبيقات في بيئة حقيقية. أعلنوا عن MetricKit (إطار عمل يوفر الوصول إلى الخيارات التي يوفرها نظام التشغيل) لعلامة تبويب منفصلة في منظم Xcode 11 ، حيث يمكنك العثور على إعدادات التطبيق. سنتوقف في MetricKit ، لأن عرض المعلمات في Xcode سيعمل فقط مع التطبيقات التي تم نشرها بالفعل في AppStore.

MXMetricManager

بنية الإطار بسيطة للغاية ومباشرة. يشغل الجزء الرئيسي فئة MXMetricManager ، وهي بنية أحادية العنصر توفر للمطور مجموعة كبيرة من واجهات برمجة التطبيقات (APIs) الإطارية.

بشكل عام ، يتكون سير العمل من 3 خطوات رئيسية:

1. يمكنك تهيئة MXMetricMnager وتعيين مراقب له.
2. إذا كنت ترغب في ذلك ، يمكنك تطبيق المقاييس الخاصة بك في التطبيق الخاص بك باستخدام Signpost API
3. وأخيرًا ، نحن نتعامل الآن مع البيانات المستلمة في طريقة didReceivePayloads ، أي إرسالها إلى الخلفية الخاصة بك لمزيد من التحليل.

تأتي المعلمات كصفيف لمثيلات MXMetricPayload . تضم الحمولة الصافية مجموعات البيانات الأولية والطوابع الزمنية. الحمولة النافعة المترية عبارة عن غلاف بسيط لفئة MXMetric . لكل نوع من المعلمات ، فهو منفصل.

يتم توثيق أنواع المقاييس جيدًا من قِبل Apple ، لذلك دعونا لا نتطرق إلى ذلك لفترة طويلة. ومع ذلك ، يجب أن تتوقف عن ملاحظة شيء مثير للاهتمام - يوفر MXMetric واجهة برمجة تطبيقات مفتوحة لتسلسلها في NSDictionary أو JSON ، والتي ، في رأيي ، غير عادية بعض الشيء.

المكونات الداخلية ل MetricKit.

في الخارج ، تبدو MetricKit بسيطة جدًا. ولكن من المثير للاهتمام دائمًا أن نرى كيف يعمل كل شيء من الداخل إلى الخارج. الانغماس في شيء أعمق دائمًا هو دسيسة ، إذا كنت تواجه مهمة محددة. لذلك قررت أن أرغب في تمرير معلمات بعلامات MetricKit ، ثم جعلهم يزودونني بمقاييس محدثة في أي وقت. بالطبع ، يمكنك استخدام ` Debug -> Simulation MetricKit Payloads` في Xcode ، لكن id لا يسمح لك بعرض البيانات الخاصة بك. صحيح ، هذا ليس فريقًا مفيدًا للغاية ، ولكنه يمنحك التوجيه في البحث الخاص بك ، ويبدو مضحكا للغاية ؛)

لبدء المهمة ، من الواضح أننا بحاجة إلى MetricKit نفسها. قد تعتقد أن الحصول على ملف ثنائي للإطار أمر سهل ، لأن Xcode يعرضه في قائمة الأُطُر بمجرد إضافته من خلال مربع حوار "ربط الملف الثنائي بالمكتبات". هذا هو الفكر متفائل جدا. لأنه إذا قمت بفتح MetricKit.framework ، فسترى ملف MetricKit.tbd . حجمها 4 كيلو بايت فقط. من الواضح أن هذا ليس ما نبحث عنه.

إذن ما الذي يحدث بالفعل هنا؟

يرمز TBD إلى "كعب dylib المستند إلى النص" وهو في الواقع ملف YAML مع وصف dylib الذي يقوم بتصدير الأحرف ومسار إلى ثنائي dylib. يؤدي الارتباط بملفات tbd إلى تقليل حجم الملف الثنائي. في وقت لاحق ، في وقت التشغيل ، سيتم تنزيل dylib الحقيقي الثنائي من نظام التشغيل على المسار المحدد في ملف tbd. هذا هو ما يبدو عليه الملف عند فتحه في Xcode:



باستخدام المسار من ملف tbd ، يمكنك بسهولة الحصول على MetricKit الثنائية لمزيد من البحث ، ولكن هناك طريقة أكثر بساطة.

يحتوي تطبيقنا الثنائي على المسار إلى كل مكتبة مرتبطة ديناميكيًا في قسم رأس Mach-O. يتم استرداد هذه المعلومات بسهولة باستخدام الأداة باستخدام علامة -l.

فيما يلي إخراج مشروع الاختبار الذي قمت بإنشائه:

→ otool -l ./Metrics | grep -i metrickit name /System/Library/Frameworks/MetricKit.framework/MetricKit (offset 24) 

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

بمجرد فتح ملف MetricKit الثنائي ، انتقل إلى علامة التبويب "Proc" وتوسيع قائمة "العلامات". هنا يمكنك رؤية جميع الشخصيات المصدرة. عند اختيار واحدة منها (على سبيل المثال ، MXMetricManager) ، سنرى كل طرقها ، وبعد تحديد طريقة ، سنرى محتوياتها على الجانب الأيمن:



عند عرض قائمة أسلوب MXMetricManager [ https://gist.github.com/deszip/88a258ae21d33dc75d7cbac9569c6ec1 ] ، من السهل جدًا ملاحظة طريقة _checkAndDeliverMetricReports. يبدو أن هذا هو ما يجب استدعاءه للحصول على MetricKit لتقديم تحديثات للمشتركين.

لسوء الحظ ، لم تؤدي محاولة الاتصال به إلى دعوة للمشترك ، مما يعني على الأرجح أن هذه المعلمات لن يتم تسليمها. النظر في تنفيذ هذه الطريقة ، نلاحظ بعض الأشياء المثيرة للاهتمام: فإنه يعدد محتويات الدليل / Library / Caches / MetricKit / Reports.

ثم يحاول فك ضغط مثيل MXMetricPayload لكل عنصر على القرص. وأخيرًا ، يتكرر عبر المشتركين المسجلين ويستدعي طريقة didReceive مع قائمة من البيانات.

قد تكون المشكلة في عدم وجود بيانات في / Library / Caches / MetricKit / Reports ، لكننا نعلم أننا بحاجة إلى بعض المثيلات المؤرشفة لـ MXMetricPayload. لذلك ، دعونا ننشئها ونضعها على القرص قبل استدعاء " _checkAndDeliverMetricReports ". مرة أخرى ، تتمثل الخطة في إنشاء مثيل لـ MXMetricPayload ، ثم إنشاء وإضافة أي نوع من أنواع MXMetric إليها ، ثم أرشفة مثيل البيانات على القرص. بعد كل شيء ، استدعاء الأسلوب " _checkAndDeliverMetricReports " ، وهذا ينبغي أن يؤدي إلى استدعاء المشترك لدينا مع كعب روتين كوسيطة.

عند النظر في مستندات Apple على الحمولة والقياسات ، قد تلاحظ أنها لا تحتوي على أدوات تهيئة عامة ، وأن معظم الخصائص للقراءة فقط. لذلك ، كيف يمكن إنشاء مثيل لفصل دراسي؟

العودة إلى النطاط مرة أخرى لرؤية قائمة بطرق MXMetricPayload :



هنا يمكنك رؤية أدوات التهيئة الخاصة بها وأساليب تعيين المعلمات. من السهل استخدام أساليب الاتصال الخاصة باستخدام فئة NSInvocation وطريقة "performSelector" بسبب الطبيعة الديناميكية للهدف- C.

كمثال ، سنقوم بإنشاء مقاييس لوحدة المعالجة المركزية وإضافتها إلى الحمولة النافعة. باستخدام هذا الرابط ، يمكنك العثور على جزء الشفرة الكامل: [ https://gist.github.com/deszip/a0cf877b07cc2877129e0aaef2fed1e4 ].

وأخيرًا ، نقوم بأرشفة كل ما أنشأناه وكتابة البيانات إلى دليل / Library / Caches / MetricKit / Reports .

حان الوقت الآن للاتصال بأسلوب " _checkAndDeliverMetricReports " ، والذي يجب أن يؤدي في النهاية إلى استدعاء المشترك. هذه المرة نمرر البيانات ذات الحمولة النافعة كحجة كوسيطة.

من أين تأتي المقاييس؟

من السهل تطبيق الحصول على التقارير من خلال MetricKit ، ولكن ربما تكون مهتمًا بمعرفة كيفية ظهور التقارير في دليل التطبيق / المكتبة . هنا هو كيف.

عند الحفر داخل MetricKit الثنائي ، لاحظت هذه الطريقة: '_createXPCConnection'. التحقق من تنفيذه يوضح الموقف - فهو ينشئ NSXPCConnection للخدمة مع اسم com.apple.metrickit.xpc واثنين من واجهات MXXPCServer و MXXPCClient لجوانب العميل والخادم. إذا نظرت إلى وصف البروتوكول:

استنتاج

MetricKit هي أداة فريدة لا غنى عنها لرعاية أداء التطبيق الخاص بك في ظروف حقيقية في الإنتاج.

لسوء الحظ ، لا يمكن حاليًا إلقاء نظرة على واجهة المستخدم "Metric" في Xcode ، باستثناء ما تم عرضه أثناء العرض التوضيحي في جلسة WWDC.



يمكن أن يكون أداة لا تقدر بثمن لنقل تجربة المستخدم إلى المستوى التالي من خلال القضاء على مشاكل الأداء في التعليمات البرمجية الخاصة بك.

أحد العيوب التي أراها الآن في هذه الأداة هو عدم وجود تفاصيل لكل نوع: الفصل الوحيد هو إصدار التطبيق ، ولا يمكنك رؤية أي مقاييس لمجموعة محددة من الأجهزة / إصدارات / مناطق OS ، إلخ.

ولكن ، بالطبع ، هناك دائمًا فرصة لإرسال البيانات إلى نفسك لمزيد من المعالجة إلى جانب المعلومات الهامة التي تحتاجها. يمكنك إرفاقه بالمهام في تعقب الأخطاء والمزيد. في AppSpector ، يعمل فريقنا على توسيع وظائف أدوات مراقبة الأداء باستخدام البيانات التي تم الحصول عليها من MetricKit .

البقاء حتى الآن!