Profiling (التوصيف) هو عملية قياس أداء التطبيق وفقًا للمقاييس الرئيسية: تحميل CPU واستهلاك الذاكرة وحركة مرور الشبكة واستخدام الطاقة. الهدف من التوصيف هو العثور على الاختناقات التي تبطئ التطبيق أو تسبب استهلاكًا مفرطًا للموارد. وفقًا لـ Android Developers، فإن التوصيف المنتظم أثناء التطوير يقلل عدد أخطاء الأداء في الإنتاج بنسبة تصل إلى 60% ويساعد في الحفاظ على واجهة مستخدم سلسة حتى على الأجهزة الضعيفة.
النقاط الرئيسية
التوصيف هو جمع وتحليل البيانات حول كيفية عمل التطبيق: ما الوظائف التي يتم تنفيذها، والمدة التي تستغرقها، وكم الذاكرة التي تستهلكها، وكيف تتفاعل مع الشبكة. على عكس التسجيل (logging)، يعمل التوصيف على مستوى النظام ويوفر مقاييس رقمية دقيقة وليس تقييمات ذاتية.
الهدف الرئيسي من التوصيف هو العثور على أجزاء الكود التي تستخدم الموارد بشكل دون أمثل. يمكن أن تكون هذه طرقًا بطيئة يتم استدعاؤها في مسار واجهة المستخدم، أو تسريبات ذاكرة، أو استعلامات SQL غير فعالة، أو استدعاءات شبكة مفرطة، أو استهلاكًا مفرطًا للطاقة. بدون التوصيف، يصلح المطورون ما “يشعرون أنه بطيء” بدلاً من الاعتماد على بيانات حقيقية.
وفقًا لـ Google I/O 2023، فإن التطبيقات التي تخضع لتوصيف منتظم أثناء التطوير تظهر أخطاء ANR (Application Not Responding) أقل بنسبة 40% وأعطال OutOfMemory أقل بنسبة 50%. أدوات التوصيف مدمجة في جميع بيئات التطوير المتكاملة الحديثة — Android Studio Profiler لنظام Android و Xcode Instruments لنظام iOS.
يمكن أن يكون التوصيف ثابتًا (تحليل الكود بدون تنفيذ — lint، Detekt) وديناميكيًا (قياسات أثناء تشغيل التطبيق). للعثور على مشاكل الأداء الحقيقية، يتم استخدام التوصيف الديناميكي الذي يظهر السلوك الفعلي للتطبيق على جهاز أو محاكي.
التوصيف ضروري قبل كل إصدار رئيسي، عند إدخال مكونات واجهة مستخدم ثقيلة (قوائم، رسوم متحركة، طرق عرض مخصصة)، عند شكوى المستخدمين من البطء واستنزاف البطارية، وبعد تغيير بنية التطبيق. النهج المنهجي هو إجراء التوصيف في كل سباق (sprint)، مع تسجيل خط أساس للمقاييس.
توصيف CPU يتتبع أي الطرق والمسارات تثقل المعالج ومقدار الوقت الذي يستغرقه تنفيذ كل استدعاء. الهدف الرئيسي هو العثور على الوظائف التي تعمل لفترة أطول من المتوقع وتعيق مسار واجهة المستخدم، مما يسبب انخفاض الإطارات (jank) وأخطاء ANR.
على Android، يعرض CPU Profiler شجرة من أعلى إلى أسفل (Top-Down tree) — شجرة استدعاءات حيث يمكن رؤية أي طريقة تستغرق أطول وقت في سياق مسار معين. على iOS، يعمل Instruments Time Profiler على أساس أخذ العينات: على فترات منتظمة (على سبيل المثال، 1 مللي ثانية)، يسجل النظام مكدس الاستدعاءات لكل مسار. تحدد إحصائيات العينات أي كود يستهلك معظم الوقت.
// مثال: طريقة بطيئة تسبب jank
class UserAdapter : RecyclerView.Adapter<UserViewHolder>() {
override fun onBindViewHolder(holder: UserViewHolder, position: Int) {
// ❌ هذه الطريقة تُستدعى في مسار واجهة المستخدم وتعيق العرض
// سيظهر التوصيف أن decompressImage يستغرق 80% من الوقت
val user = getItem(position)
val bitmap = ImageUtils.decompressImage(user.avatar)
holder.avatarView.setImageBitmap(bitmap)
}
}
عند توصيف CPU، انتبه إلى الطرق ذات Self Time العالي — هذا هو الوقت الذي تقضيه الطريقة في عملها الخاص، دون حساب استدعاءات الطرق الفرعية. إذا تجاوز Self Time لطريقة في مسار واجهة المستخدم 16 مللي ثانية، فهذا يضمن انخفاض إطار على شاشة 60 FPS. الحل هو نقل العمليات الثقيلة إلى مسار خلفي.
توصيف الذاكرة يتتبع مقدار الذاكرة التي يستخدمها التطبيق: ما الكائنات التي يتم إنشاؤها، ومدة بقائها، ومتى يتم تحريرها. الهدف الرئيسي هو العثور على التسريبات (كائنات لا يجب أن توجد ولكنها تبقى في الذاكرة) والتخصيصات المفرطة (كائنات يتم إنشاؤها بشكل متكرر جدًا).
على Android، يعرض Memory Profiler رسمًا بيانيًا لاستهلاك RAM في الوقت الفعلي، وقائمة بجميع الكائنات المخصصة، وتفاصيل لكل نوع. المقاييس الرئيسية: Java Heap (كائنات في كومة JVM)، Native Heap (تخصيصات على مستوى C/C++)، Graphics Memory (الأنسجة ومخازن GPU). لنظام iOS، يعرض Instruments Allocations مقاييس مماثلة: Heap Allocations (كائنات في الكومة) و Anonymous VM (صفحات الذاكرة الافتراضية).
| المقياس | Android Profiler | Instruments (iOS) |
|---|---|---|
| كائنات الكومة | Java Heap + Native Heap | Heap Allocations |
| الرسوميات | Graphics Memory | VM Tracker |
| التسريبات | Memory Profiler + LeakCanary | Leaks instrument |
| تفريغ الكومة | HPROF (Capture) | Heapshot |
عند توصيف الذاكرة، من المهم أخذ تفريغات للكومة بعد تنفيذ سيناريوهات المستخدم النموذجية: فتح وإغلاق شاشة، تحميل قائمة، العمل مع الصور. ستظهر مقارنة تفريغين (قبل وبعد السيناريو) أي الكائنات لم يتم تحريرها. إذا زاد عدد كائنات Activity ولكن الشاشة أغلقت، فهذا تسريب.
في Android Studio، افتح التفريغ عبر Memory Profiler: رتب الكائنات حسب Retained Size (كلما كان أكبر، زادت الذاكرة التي يحتفظ بها الكائن). ابحث عن مثيلات Activity و Fragment و Bitmap التي لا يجب أن توجد في الذاكرة. إذا كان هناك مثل هذا الكائن، انتقل إلى Reference Tree لترى ما الذي يحتفظ به.
توصيف الشبكة يتتبع جميع طلبات HTTP من التطبيق: URL، حجم الاستجابة، وقت التنفيذ، رموز الاستجابة والرؤوس. الهدف الرئيسي هو العثور على الطلبات التي تستغرق وقتًا طويلاً، أو تنقل بيانات مفرطة، أو تتم دون داعٍ.
على Android، يعرض Network Profiler خطًا زمنيًا لجميع استدعاءات الشبكة ومدتها وكمية البيانات المنقولة. يمكن فتح كل طلب لعرض الرؤوس الكاملة وجسم الاستجابة. على iOS، يستخدم Instruments Network لمراقبة نظام تحميل URL ويعرض مخططًا waterfall للطلبات.
المشاكل النموذجية التي يكشفها توصيف الشبكة: عدم وجود تخزين مؤقت (يتم تحميل نفس JSON في كل مرة تفتح فيها شاشة)، طلبات مكررة (تطلب عدة مكونات نفس البيانات في وقت واحد)، استجابات كبيرة (يرسل الخادم 5 ميجابايت من JSON بينما تحتاج 100 كيلوبايت). لكل مشكلة حل قياسي: تكوين التخزين المؤقت عبر OkHttp أو URLSession، دمج الاشتراكات عبر Combine أو Flow، إضافة ترقيم الصفحات من جانب الخادم.
انتبه بشكل خاص إلى الوقت حتى أول بايت (TTFB). إذا تجاوز TTFB 500 مللي ثانية على اتصال جيد، فالمشكلة من جانب الخادم. إذا كان الطلب نفسه سريعًا ولكن تحليل JSON يستغرق ثوانٍ، فالمشكلة في إلغاء التسلسل ويجب توصيفها بشكل منفصل.
توصيف الطاقة يقيس كيف يؤثر التطبيق على عمر البطارية. هذا نوع جديد نسبيًا من التوصيف ولكنه مهم بشكل حاسم للتطبيقات المحمولة — المستخدمون يحذفون التطبيقات التي تستنزف البطارية بشكل مفرط. يعرض Energy Profiler في Android Studio و Energy Log في Instruments أي العمليات (Wi-Fi، GPS، CPU، Bluetooth) تستهلك الطاقة في كل لحظة.
المستهلكون الرئيسيون للطاقة في التطبيقات المحمولة: WakeLock (إبقاء المعالج نشطًا)، GPS Location (تحديثات موقع مستمرة)، طلبات الشبكة (خاصة على شبكات 4G/5G)، الرسوم المتحركة في الخلفية. يضع Energy Profiler أحداث التطبيق على مقياس استهلاك الطاقة — إذا كان هناك ارتفاع في الرسم البياني، يمكنك تحديد العملية التي تسببت فيه بدقة.
وفقًا لـ Apple WWDC 2023، فإن تقليل استهلاك الطاقة للتطبيق بنسبة 20% يزيد من الاحتفاظ بالمستخدمين بنسبة 12%، حيث يميل المستخدمون إلى حذف التطبيقات التي تستنزف البطارية بشدة. التوصية هي تمكين Energy Profiler دائمًا عند اختبار السيناريوهات مع GPS والمزامنة الخلفية والبث.
يعتمد اختيار الأداة على المنصة ونوع التوصيف. لنظام Android، المجموعة الرئيسية هي Android Studio Profiler (CPU، الذاكرة، الشبكة، الطاقة)، LeakCanary (تسريبات الذاكرة) و Perfetto (التوصيف على مستوى النظام). لنظام iOS — Xcode Instruments مع القوالب: Time Profiler و Allocations و Leaks و Energy Log و Network و Core Animation.
للتطوير عبر المنصات باستخدام Flutter، استخدم DevTools مع وحدات Timeline (CPU) و Memory و Network و Debugger. لـ React Native — React DevTools و Flipper من Facebook، الذي يدعم فحص الشبكة وقاعدة البيانات والتسلسل الهرمي لواجهة المستخدم. بغض النظر عن الإطار، فإن المبادئ الأساسية للتوصيف عالمية: قس قبل التحسين وبعده، سجل خط الأساس، قارن المقاييس مع كل تغيير في الكود.
تشمل الأساليب الحديثة التوصيف الآلي في CI. على Android، يدعم Firebase Test Lab قياسات الأداء إلى جانب اختبارات واجهة المستخدم: تحصل ليس فقط على نتائج نجاح/فشل ولكن أيضًا رسوم بيانية لـ CPU والذاكرة والشبكة لكل تكرار. وظائف مماثلة لنظام iOS توفرها GitHub Actions مع XCUITest و Instruments CLI.
لفحص سريع لمقياس واحد، استخدم أداة التوصيف المدمجة في IDE. للتحليل الشامل للتسريبات — أدوات متخصصة (LeakCanary، Instruments Leaks). للتوصيف على مستوى النظام — Perfetto (Android) أو DTrace (macOS). مزيج من أداتين أو ثلاث يغطي 95% من سيناريوهات التوصيف.
الأسئلة الشائعة
التسجيل (logging) يعرض تسلسل الأحداث في شكل نصي، بينما يوفر التوصيف مقاييس كمية — مقدار الوقت والذاكرة وCPU والشبكة التي يستهلكها كل جزء من الكود. التوصيف يجيب على سؤال “كم?”، بينما يجيب التسجيل على “ماذا حدث?”
يوصى بإجراء التوصيف قبل كل إصدار رئيسي، وعند إدخال مكونات واجهة مستخدم ثقيلة جديدة، وعند ظهور شكاوى حول الأداء. من الناحية المثالية، يكون التوصيف مدمجًا في CI ويعمل تلقائيًا مع كل طلب سحب (pull request).
نعم، وهذا أفضل حتى من استخدام المحاكي. يظهر الجهاز الحقيقي الأداء الفعلي مع مراعاة قيود الأجهزة المحددة. يدعم Android Studio Profiler و Xcode Instruments التوصيف على جهاز متصل دون أي قيود.
نعم، أي أداة توصيف تضيف عبئًا إضافيًا. لتوصيف CPU القائم على أخذ العينات، يبلغ العبء الإضافي 1–5%. لتوصيف الذاكرة مع تفريغ الكومة، يصل إلى 10% في لحظة التفريغ. تحاول الأدوات الحديثة تقليل التأثير، ولكن يجب دائمًا أخذه في الاعتبار عند تفسير النتائج.
خط الأساس (Baseline) هو مجموعة مرجعية من مقاييس الأداء المأخوذة على أول إصدار مستقر من التطبيق. مع كل تغيير في الكود، قارن المقاييس الجديدة بخط الأساس. إذا زاد وقت بدء التشغيل بمقدار 50 مللي ثانية مقارنة بخط الأساس، تحقق من السبب قبل دمج التغييرات.
الملخص
سنقوم بتطوير تطبيق جوال جاهز
تقدم IT Sectr تطبيقات iOS وAndroid للشركات الناشئة والشركات منذ عام 2017. سوف نقدم لك النصح ونقترح أفضل حل.
اقرأ أيضًا