Instruments — ما هو، إمكانيات Time Profiler و Allocations

ما هو Instruments؟

Instruments هو نظام تحليل أداء وتتبع مضمن في Xcode ويعتمد على تقنية DTrace التي طورتها Sun Microsystems. يجمع Instruments عشرات أدوات التحليل (قوالب) في واجهة واحدة: فقط اختر قالبًا، قم بتشغيل تطبيقك من خلال Xcode وابدأ جمع البيانات.

تعتمد معمارية Instruments على نموذج خدمة العميل والخادم: يقوم وكيل على الجهاز بجمع البيانات ونقلها إلى Mac عبر اتصال USB. يقلل هذا من تأثير محلل الأداء على أداء التطبيق — يعمل Instruments بشكل أساسي على جانب المضيف. وفقًا لـ WWDC 2022، يبلغ الحمل الزائد لـ Time Profiler عند تردد الأخذ بمعدل 1 مس أقل من 3%.

Instruments يدعم القوالب المخصصة — يمكن للمطور الجمع بين عدة أدوات في جلسة تحليل واحدة. على سبيل المثال، تشغيل Time Profiler + Allocations + Leaks معًا ورؤية الارتباط بين قمم وحدة المعالجة المركزية وتخصيصات الذاكرة. يوفر هذا صورة كاملة للأداء غير متوفرة عند تحليل كل مكون بشكل منفرد.

ما هي القوالب المتوفرة افتراضيًا

يأتي Xcode مع 16 قالبًا مثبتًا من Instruments: Time Profiler، Allocations، Leaks، Energy Log، Network، Core Animation، Metal System Trace، File Activity، System Trace وغيرها. كل قالب محسن لمهمة محددة ومكون مسبقًا بإعدادات المحفزات والمرشحات الصحيحة.

Time Profiler: تحليل أداء وحدة المعالجة المركزية

Time Profiler هو أكثر قوالب Instruments استخدامًا. يعمل عن طريق أخذ عينات من كومة الاستدعاء: كل 1–10 ملي ثانية يسجل النظام كومة استدعاء جميع خيوط التطبيق. بعد إيقاف الجلسة، يجمع Instruments العينات ويظهر الدوال والوظائف التي استهلكت أكبر قدر من الوقت. يتم عرض النتيجة كشجرة استدعاء (Call Tree) — مرتبة حسب Self Weight.

المقياس الرئيسي لـ Time Profiler هو Self Weight (الوقت المقضى مباشرة في الدالة، باستثناء استدعاءات الدوال الفرعية). يظهر Self Weight الدوال التي تحمل المعالج المركزي فعليًا. قد يكون Weight (الوقت الإجمالي مع الدوال الفرعية) مضللًا: دالة ذات Weight عالي قد تكون فقط تستدعي دالة أخرى بطيئة بينما هي نفسها سريعة.

import UIKit

class ImageGalleryViewController: UIViewController {
    // Time Profiler سيظهر أن cellForItemAt لديه Self Weight = 40%
    // داخله decodeImage يستغرق 35% — هذه هي المخنق

    func collectionView(
        _ collectionView: UICollectionView,
        cellForItemAt indexPath: IndexPath
    ) -> UICollectionViewCell {
        let cell = collectionView.dequeueReusableCell(
            withReuseIdentifier: "ImageCell",
            for: indexPath
        ) as! ImageCell
        // ❌ decodeImage — مخنق (Self Weight = 35%)
        cell.imageView.image = UIImage(contentsOfFile: imagePath)
        return cell
    }
}

عند تحليل Time Profiler، انتبه إلى الدوال التي تعمل على com.apple.main-thread. إذا تجاوز Self Weight على الخيط الرئيسي حد 16 مس لكل إطار، فستتعرض واجهة المستخدم للتهزيز. حل هذه المشكلات هو نقل فك تشفير الصور، حسابات layout ومعالجة البيانات من الخيط الرئيسي إلى خيط خلفي عبر Grand Central Dispatch (GCD).

كيفية قراءة Call Tree في Time Profiler

Call Tree هو تمثيل هرمي لجميع استدعاءات الدوال، مرتب حسب Self Weight. أثقل دالة في Call Tree هي السطر الأول. بتوسيع السطر، ترى الدوال الفرعية التي تم استدعاؤها والوقت الذي استغرقته. ابحث عن دوال حيث يكون Self Weight (الوقت الذاتي) أكبر بكثير من Weight (الوقت الإجمالي) — هذه علامات الأقفال المتزامنة والانتظار.

Allocations: تتبع الذاكرة في الوقت الفعلي

Allocations هي أداة لمراقبة جميع تخصيصات الذاكرة للتطبيق. تظهر الأشياء التي تم إنشاؤها، بأي كمية وبأي حجم إجمالي في كل لحظة. بخلاف Memory Profiler في Android Studio، تدعم Allocations Heapshot — لقطة من الكائنات الحية مع القدرة على مقارنة لقطتين.

تتكون واجهة Allocations من قسمين رئيسيين: All Allocations (إحصاءات إجمالية لجميع أنواع الكائنات) و Call Trees (شجرة استدعاء مقسمة حسب الدوال التي تنشئ الكائنات). للعثور على التسربات، استخدم Heapshot Analysis: خذ لقطة قبل تنفيذ سيناريو، نفذ السيناريو، خذ لقطة بعده — وقارن الكائنات الجديدة التي بقيت في الذاكرة.

وفقًا لـ Apple Developer Documentation، أكثر أنماط التسريب شيوعًا التي يكتشفها Allocations هو الإنشاء المفرط لـ UIView و CALayer أثناء التمرير في المجموعات. إذا زاد عدد UIView الحية مع كل تمرير بينما تعيد المجموعة استخدام الخلايا — في مكان ما يتم إنشاء عروض إضافية دون تحرير القديمة. يظهر Allocations كومة الاستدعاء الدقيقة حيث تتم إنشاء هذه العروض.

Heapshot Analysis: مقارنة لقطات الذاكرة

Heapshot هي لقطة من الكائنات الحية في Allocations. خذ Heapshot قبل تنفيذ سيناريو، نفذ السيناريو وخذ Heapshot ثاني. سيظهر الفرق بين اللقطات الكائنات التي تم إنشاؤها ولم تتحرر. النتيجة المثالية هي نمو الكائنات المؤقتة فقط (Autorelease pool). للتحليل الدقيق، استخدم مزيجًا من Allocations + Leaks في جلسة واحدة. يظهر Allocations الكائنات التي لم تتحرر، ويظهر Leaks لماذا (أي مرجع قوي يحتفظ بها). شغل جلسة مزدوجة كلما اشتبهت وجود تسريب.

Leaks: البحث التلقائي عن تسربات الذاكرة

Leaks هي أداة متخصصة لكشف تسربات الذاكرة في تطبيقات iOS و macOS. بخلاف Allocations التي تظهر فقط التخصيصات، تقوم Leaks بمسح الكومة بنشاط بحثًا عن retain cycles — حالات حيث يتبادل كائنان أو أكثر الإمساك ببعضهم البعض بمراجع قوية.

تعمل Leaks مع Cycles & Roots — مصور رسم بياني للاحتفاظ بالكائنات. عندما يتم اكتشاف تسريب، تظهر Leaks جميع الكائنات في الدورة، عدد الاحتفاظات والحقول الدقيقة التي تم من خلالها تمرير المراجع. يحتاج المطور فقط إلى النظر إلى الرسم البياني وفهم المرجع الذي يجب تغييره إلى weak.

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

وفقًا لـ WWDC 2022، يستطيع Leaks اكتشاف حتى retain cycles المعقدة متعددة المستويات — على سبيل المثال، عندما تشكل ثلاثة كائنات أو أكثر سلسلة مغلقة من المراجع القوية. لتشخيص مثل هذه الدورات، يعتبر رسم Cycles & Roots أساسيًا: يظهر بوضوح كيف ترتبط الكائنات ببعضها البعض في حلقة مغلقة.

كيفية قراءة رسم Cycles & Roots

كل عقدة في الرسم هي كائن، وكل سهم هو مرجع قوي. الدورة هي حلقة مغلقة من السهام. يظهر لون العقدة الحالة: أحمر — كائن متسرب، أخضر — جذر (GC Root)، رمادي — كائن وسيط. لإصلاح التسريب، ابحث عن سهم يمكن جعله weak دون تعطيل المنطق — وقم بتغيير نوع المرجع في الكود.

Energy Log: تحليل استهلاك الطاقة

Energy Log هو قالب Instruments لقياس استهلاك الطاقة للتطبيق. يجمع بيانات من حاسات الجهاز: حمل وحدة المعالجة المركزية، حالة Wi-Fi والشبكة الخلوية، استخدام GPS، الشاشة و Bluetooth. يظهر Energy Log العمليات التي تسبب أكبر استهلاك للبطارية ويضعها على رسم بياني لاستهلاك الطاقة عبر الوقت.

تصنف الأداة العمليات حسب مستوى استهلاك الطاقة: منخفض (عمل وحدة المعالجة المركزية العادي)، متوسط (إرسال Wi-Fi)، عالي (GPS، الشبكة الخلوية، GPU). إذا أظهر Energy Log مؤشرات حمراء عالية لفترة طويلة — فالتطبيق يستهلك البطارية في الخلفية وسيتم حذفه من قبل المستخدم.

المشاكل النموذجية التي يكتشفها Energy Log: WakeLock بدون حد زمني (التطبيق يبقي المعالج نشطًا بعد إكمال المهمة)، Location Updates بدقة عالية في الخلفية (طلبات إحداثيات كل بضع ثوان)، شذوذ جلسات الشبكة (إعادات اتصال متكررة بالخادم). يوصي Energy Log بتسجيل أي حادثة من هذا النوع وإضافة شرط لتعطيل العملية عالية استهلاك الطاقة.

لاختبار استهلاك الطاقة، استخدم جهازًا حقيقيًا بطاقة البطارية — قراءات استهلاك الطاقة على المحاكي غير صحيحة. شغل Energy Log مع اختبارات UI لأتمتة فحص استهلاك البطارية في CI.

كيفية تشغيل وتفسير نتائج Instruments

يتم تشغيل Instruments من Xcode بطريقتين: من خلال قائمة Product → Profile (⌘I) أو بفتح Instruments كتطبيق منفصل في Launchpad. الطريقة الأولى أكثر راحة: Xcode يبني التطبيق تلقائيًا في وضع التحليل ويشغله على الجهاز المتصل بالقالب المحدد. بعد إيقاف الجلسة، يحفظ Instruments التتبع في ملف بامتداد .trace.

يعتمد تفسير النتائج على القالب. لـ Time Profiler، انظر إلى Call Tree المرتب حسب Self Weight — الدوال العليا هي المخانق الرئيسية. لـ Allocations — انظر إلى # Living بعد سيناريو دوري: إذا زاد عدد الكائنات، ابحث عن تسريب. لـ Leaks — انظر إلى العلامات الحمراء ورسم Cycles & Roots. قارن النتائج قبل وبعد التحسين — هذا هو الطريق الوحيد لتأكيد فعالية التغييرات.

// سطر الأوامر لـ Instruments في CI
// دمج Instruments في خط التجميع CI/CD
import XCTest

class PerformanceTests: XCTestCase {
    func testScrollPerformance() {
        // قياس وقت التمرير للمجموعة
        measure(metrics: [XCTCPUMetric(), XCTMemoryMetric()]) {
            app.scrollToBottom()
        }
    }
}

في CI، يمكنك تشغيل Instruments من سطر الأوامر باستخدام xcodebuild -showBuildSettings و xcrun xctrace. يسمح هذا بأتمتة التحليل عند كل commit وعدم تفويت الانتكاسات. للتحليل، استخدم مقارنة Baseline: إذا تدهور مقياس بنسبة 5% مقارنة بالالتزام السابق، يجب أن يتوقف خط التجميع.

الأخطاء الشائعة عند العمل مع Instruments: التحليل على المحاكي بدلاً من الجهاز (بيانات وحدة المعالجة المركزية و GPU غير صحيحة)، جمع البيانات بدون سيناريو (النتائج عشوائية)، تجاهل Call Tree (النظر فقط إلى الرسم البياني وليس إلى الدوال المحددة). إصلاح هذه الأخطاء يوفر 80% من جودة التحليل.