عمليات ربط الخدمات وحالات العمليات

لا تعمل عمليات التطبيقات على Android بشكل منفصل. تعتمد التطبيقات غالبًا على الخدمات التي توفّرها تطبيقات أخرى أو النظام نفسه. عندما تتصل إحدى العمليات بعملية أخرى من خلال ربط خدمة، يتم إنشاء تبعية تؤثر بشكل كبير في طريقة إدارة إطار عمل Android للذاكرة.

حالات العمليات ونتائج OOM

يستخدم إطار عمل Android حالات العمليات لتتبُّع أهمية كل عملية قيد التشغيل. تستخدم OomAdjuster هذه الحالات لتعيين قيمة تعديل نتيجة OOM (oom_score_adj) تتراوح بين -1000 و1000.

يشير انخفاض قيمة oom_score_adj إلى أنّ العملية أكثر أهمية وأقل عرضة لأن يتم إيقافها من خلال Low Memory Killer (LMK).

حالات العملية الشائعة

يعرض الجدول التالي بعض حالات العمليات الأكثر شيوعًا وقيمها النموذجية oom_score_adj. للحصول على قائمة كاملة وحديثة، يُرجى الرجوع إلى android.app.ActivityManager وcom.android.server.am.psc.Constants في رمز المصدر لنظام Android.

تأثير روابط الخدمات

عندما يرتبط أحد عمليات العميل (مثل تطبيق في الحالة TOP) بخدمة في عملية خادم، غالبًا ما تكتسب عملية الخادم أولوية أعلى. ويضمن ذلك بقاء الخدمة متاحة طالما احتاج إليها العميل.

التحكّم في الاكتساب باستخدام علامات BIND

يتم استخدام ميزة "الميراث" تلقائيًا عند استخدام Context.BIND_AUTO_CREATE. ومع ذلك، يمكن للمطوّرين التحكّم في كيفية تأثير الربط في أهمية العملية المستهدَفة باستخدام علامات مختلفة في bindService().

علامات BIND الرئيسية لتقييم OOM

تكون العلامات التالية أكثر صلةً عند إدارة ضغط الذاكرة على مستوى النظام:

• ‫BIND_AUTO_CREATE: يشير إلى البلاغ الأكثر شيوعًا. ويضمن بدء عملية الخدمة واستمرارها طالما أنّ الربط متوفّر. تؤدي هذه العملية تلقائيًا إلى رفع مستوى أولوية عملية الخادم ليتطابق مع مستوى أولوية العميل.
• BIND_NOT_FOREGROUND: يمنع رفع أولوية الجدولة (أولوية وحدة المعالجة المركزية) لعملية الخدمة المستهدَفة إلى المقدّمة. ومع ذلك، يظل بإمكانك رفع أولوية الذاكرة (oom_score_adj). ويكون ذلك مفيدًا لتنفيذ مهام في الخلفية لا تتنافس مع واجهة المستخدم على دورات وحدة المعالجة المركزية، ولكن يجب أن تظل محمية من الإيقاف.
• BIND_WAIVE_PRIORITY: علامة قوية جدًا توجّه النظام إلى عدم التأثير في أولوية الجدولة أو إدارة الذاكرة للعملية المستهدَفة. ستتم إدارة عملية الخدمة كما لو كانت عملية عادية تعمل في الخلفية ضمن قائمة العناصر الأقل استخدامًا (LRU)، ما يجعلها مؤهَّلة لإيقافها بسبب خطأ نفاد الذاكرة (OOM) حتى أثناء ربطها.
• BIND_ABOVE_CLIENT: يشير إلى أنّ الخدمة أكثر أهمية من تطبيق العميل نفسه. عندما يحتاج النظام إلى استرداد الذاكرة، سيُفضّل إيقاف تطبيق العميل قبل إيقاف الخدمة المرتبطة. هذه الطريقة "أكثر أمانًا" من BIND_AUTO_CREATE لأنّها توفّر طبقة حماية إضافية للخدمة على حساب العميل.
• BIND_NOT_PERCEPTIBLE: يخفّض مستوى أهمية الخدمة المستهدَفة إلى أقل من المستوى PERCEPTIBLE، ما يتيح للنظام استعادة الذاكرة لإتاحة مساحة لعمليات أكثر أهمية يمكن للمستخدم إدراكها.

تجربة عملية: مراقبة تأثيرات الربط

سنستخدم تطبيق MemoryLab لتوضيح كيف يؤثر ربط من تطبيق TOP في حالة عملية منفصلة.

1. تشغيل MemoryLab

يؤدي الأمر التالي إلى تشغيل التطبيق. وبعد فتحه، تأكَّد من بقاء التطبيق في المقدّمة (لا تضغط على "الشاشة الرئيسية" أو تنتقل إلى تطبيقات أخرى بعد).

adb shell am start -n com.android.memorylab/.MainActivity

2. تحديد العمليات

تحقَّق من حالات العملية قبل الربط. تُشغّل MemoryLab واجهة المستخدم الرئيسية في عملية واحدة، وتتضمّن RemoteService يتم تشغيلها في عملية :remote.

adb shell dumpsys activity processes com.android.memorylab

مثال على مقتطف الناتج:

  Process OOM control (154 total, non-act at 7, non-svc at 7):
    Proc #0: fg       T/A/TOP  LCMNFUATI  t: 0 13470:com.android.memorylab/u0a417 (top-activity)
        oom: max=1001 curRaw=0 setRaw=0 cur=0 set=0
        state: cur=TOP  set=TOP   lastRss=0.00 lastCachedRss=0.00

سيظهر لك الإجراء الرئيسي com.android.memorylab في الحالة TOP. لم تبدأ عملية :remote بعد.

3- ربط المشغّل

أرسِل بثًا إلى التطبيق لتفعيل ربط الخدمة:

adb shell am broadcast -a com.android.memorylab.LEAK_BINDER

4. مراقبة الحالة المرتفعة

تحقَّق من حالات العملية مرة أخرى:

adb shell dumpsys activity processes | grep -A 10 "com.android.memorylab"

مثال على مقتطف الناتج:

  Proc #  1: vis      F/ /BTOP ---NFUATI  t: 0 13560:com.android.memorylab:remote/u0a417 (service)
    com.android.memorylab/.RemoteService<=Proc{13470:com.android.memorylab/u0a417}
    oom: max=1001 curRaw=100 setRaw=100 cur=100 set=100
    state: cur=BTOP set=BTOP  lastRss=0.00 lastCachedRss=0.00

تعمل عملية :remote الآن وهي في حالة BTOP (أعلى موضع مرتبط) مع oom_score_adj بقيمة 100. وهي أكثر حماية من خدمة تُشغَّل في الخلفية عادية (والتي تكون في الفئة 500 أو أعلى). تعرض الرموز <=Proc{...} العملية المسؤولة عن رفع الأولوية هذا.

‫5. التشغيل في الخلفية

اضغط على زر الشاشة الرئيسية على الجهاز. يُرجى التحقّق من الحالات مرة أخرى:

adb shell dumpsys activity processes | grep -A 10 "com.android.memorylab"

مثال على مقتطف الناتج:

    Proc #  2: prev     b/ /LAST --------I  t: 0 13560:com.android.memorylab:remote/u0a417 (service)
        com.android.memorylab/.RemoteService<=Proc{13470:com.android.memorylab/u0a417}
        oom: max=1001 curRaw=700 setRaw=700 cur=700 set=700
        state: cur=LAST set=LAST  lastRss=0.00 lastCachedRss=0.00
    Proc #  1: prev     b/ /LAST --------I  t: 0 13470:com.android.memorylab/u0a417 (previous)
        oom: max=1001 curRaw=700 setRaw=700 cur=700 set=700
        state: cur=LAST set=LAST  lastRss=209MB lastCachedRss=0.00

الآن، انتقلت كلتا العمليتين إلى حالة أولوية أقل (PREV / oom_score_adj 700)، لأنّ عملية البرنامج لم تعُد TOP. (ملاحظة: يشير LAST في تفريغ الحالة إلى الحالة الداخلية LAST_ACTIVITY، والتي تتطابق مع PREV في الملخّصات العالية المستوى).

التحليل باستخدام procstats

تقدّم أداة procstats عرضًا تاريخيًا لهذه الحالات.

# View stats for MemoryLab over the last hour
adb shell dumpsys procstats --hours 1 com.android.memorylab

مثال على مقتطف الناتج:

  *   com.android.memorylab / u0a417 / v37:
      *   Prc com.android.memorylab / u0a417 / v37:
             TOTAL: 0.89% (0.00-0.00-0.00/0.00-0.00-0.00/210MB-210MB-210MB over 1)
               Top: 0.89% (0.00-0.00-0.00/0.00-0.00-0.00/210MB-210MB-210MB over 1)
      *   Prc com.android.memorylab:remote / u0a417 / v37:
             TOTAL: 0.19%
           Bnd Top: 0.19%

يشير Bnd Top هنا إلى النسبة المئوية للوقت الذي استغرقته العملية البعيدة في الربط بتطبيق في الحالة TOP.

تسجيل عمليات الربط وتحليلها باستخدام أداة Perfetto

في حين يقدّم لك dumpsys لقطة سريعة، يتيح لك Perfetto الاطّلاع على اللحظة الدقيقة التي يحدث فيها الربط وكيف يتغير تقييم OOM في الوقت الفعلي.

1. تسجيل عملية تتبُّع

استخدِم إعدادًا يتضمّن linux.process_stats وفئة am atrace:

adb shell perfetto -c - --txt -o /data/misc/perfetto-traces/service_bindings.perfetto-trace <<EOF
buffers: { size_kb: 65536 }
data_sources: {
    config {
        name: "linux.process_stats"
        process_stats_config { proc_stats_poll_ms: 100 }
    }
}
data_sources: {
    config {
        name: "linux.ftrace"
        ftrace_config { ftrace_events: "am/am_proc_bound" }
    }
}
duration_ms: 15000
EOF

2. عمليات نقل نتائج "خطأ نفاد الذاكرة" لطلبات البحث

باستخدام PerfettoSQL، يمكنك الاطّلاع على كيفية تغيُّر نتيجة OOM للعملية البعيدة مقارنةً بعملية واجهة المستخدم:

SELECT ts, p.name, value AS oom_score_adj
FROM counter c
JOIN process_counter_track t ON c.track_id = t.id
JOIN process p USING (upid)
WHERE p.name LIKE 'com.android.memorylab%'
  AND t.name = 'oom_score_adj'
ORDER BY ts;

3- تحديد أحداث الربط

لمعرفة الوقت الدقيق الذي تم فيه إنشاء تبعية ربط والعملية التي بدأت فيها، استخدِم طلب البحث التالي:

SELECT
    s.ts,
    p.name AS process_name,
    t.name AS thread_name,
    s.name AS slice_name
FROM slice s
JOIN thread_track tt ON s.track_id = tt.id
JOIN thread t USING (utid)
JOIN process p USING (upid)
WHERE s.name LIKE 'bindService:{com.android.memorylab%';

عمليات الربط بين النظام والتطبيق

يرتبط نظام التشغيل Android نفسه غالبًا بالخدمات في التطبيقات التابعة لجهات خارجية لتوفير الوظائف الأساسية. وغالبًا ما يكون الهدف من عمليات الربط هذه هو تقليل وقت الاستجابة. من خلال إبقاء عملية نشطة وفي الذاكرة، يتجنّب النظام النفقات العامة الباهظة لـ "تشغيل على البارد" (تحميل حزمة APK، وتهيئة وقت التشغيل، وإنشاء كائن التطبيق) عند حدوث تفاعل المستخدم المهم. تتوفّر روابط أخرى لمنع عمليات البدء البارد المتكرّرة للتطبيقات التي تحتاج إلى معالجة تدفقات أحداث في الخلفية.

في ما يلي بعض الأمثلة الواقعية التي يمكنك ملاحظتها على جهاز عادي:

VoiceInteractor

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

عندما يتم تفعيل مشغّل المساعد الرقمي (مثل الكلمة المفتاح "Ok Google" على هواتف Google Pixel)، يجب أن يستجيب المساعد الرقمي على الفور. لضمان ذلك، يحتفظ system_server بربط دائم بخدمة التفاعل الصوتي التي يختارها المستخدم.

إذا تحقّقت من حالات العمليات (على سبيل المثال، باستخدام dumpsys activity processes)، قد تظهر لك عملية مثل com.google.android.googlequicksearchbox:interactor في الحالة BFGS (خدمة مرتبطة تعمل في المقدّمة)، ويتم إبقاؤها نشطة من خلال ربط من system_server (معرّف المستخدم 1000).

NotificationListenerService

في بعض عمليات الربط بين النظام والتطبيق، لا يكون الهدف هو تقليل وقت الاستجابة، بل منع عمليات بدء التشغيل البارد المتكررة. NotificationListenerService، وهي خدمة تتلقّى مكالمات من النظام عند نشر إشعارات جديدة أو إزالتها، وهي مثال رئيسي على ذلك. قد يتلقّى مستخدم الهاتف الذكي العادي مئات الإشعارات على مدار اليوم. إذا تم إلغاء ربط النظام بأحد تطبيقات الاستماع إلى الإشعارات، من المحتمل أن تنتقل عملية هذا التطبيق إلى حالة التخزين المؤقت، وقد يتم إنهاؤها بواسطة LMK.

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

شاشة "الصفحة -1" (خلاصة الأخبار) في مشغّل التطبيقات

تجمع تطبيقات Launcher الحديثة عادةً بين وظيفة التنقّل الأساسية (رموز الشاشة الرئيسية والأدوات) وخلاصة الأخبار المتوفّرة على إحدى شاشات Launcher والمدمجة بسلاسة مع تجربة المستخدم في Launcher. قد يوفّر تطبيق آخر خلاصة الأخبار. على سبيل المثال، يدمج مشغّل التطبيقات على هواتف Google Pixel مع خلاصة يوفّرها تطبيق Google.

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

أمثلة شائعة أخرى

• مشغّل التطبيقات (HOME_APP_ADJ): يحتوي تطبيق مشغّل التطبيقات (الشاشة الرئيسية) على خانة خاصة به في قائمة الأولوية. وعلى الرغم من أنّ هذا الرقم لا يكون مرتبطًا دائمًا بخدمة، إلا أنّه يتم تعيينه على HOME_APP_ADJ (عادةً 600). يفضّل النظام إبقاء مشغّل التطبيقات نشطًا لأنّ المستخدم يعود إليه بشكل متكرّر. في الواقع، يفضّل النظام إيقاف التطبيق الذي تم استخدامه سابقًا (PREV_APP_ADJ = 700) بدلاً من إيقاف مشغّل التطبيقات، لأنّ إيقاف مشغّل التطبيقات سيؤدي إلى تجربة مستخدم بطيئة عند الخروج من أي تطبيق، إذ سيحتاج المستخدم إلى الانتظار حتى يتم تشغيل مشغّل التطبيقات من البداية.
• محرّر أسلوب الإدخال (IME): عند الكتابة، يرتبط النظام بتطبيق لوحة المفاتيح الذي اخترته (مثل Gboard). يؤدي ذلك إلى إبقاء عملية لوحة المفاتيح في حالة مرتفعة حتى إذا تم إخفاء لوحة المفاتيح مؤقتًا. يضمن ذلك إمكانية إعادة ظهور لوحة المفاتيح على الفور عند النقر على حقل نص آخر.
• عمليات الدفع باستخدام NFC: عند النقر بهاتفك للدفع، يرتبط النظام بخدمة الدفع باستخدام NFC (مثل "محفظة Google"). وغالبًا ما تتضمّن هذه المعاملات متطلبات صارمة في الوقت الفعلي من جهاز التاجر. إذا كان يجب إعادة تشغيل تطبيق الدفع، قد تنتهي مهلة المعاملة ويتعذّر إجراؤها.

المفاضلة بين الأداء والسرعة

على الرغم من أنّ عمليات الربط ضرورية لتحقيق الأداء الصحيح، فإنّها تؤثر سلبًا في سلامة ذاكرة النظام.

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

الأنماط المضادة الشائعة لربط الخدمات

وبما أنّ روابط الخدمات تزيد من قيمة oom_score_adj بشكل مباشر، فإنّ الأخطاء الطفيفة في دورة الحياة عند الحصول على الروابط أو تنظيمها يمكن أن تؤدي إلى تثبيت كميات كبيرة من الذاكرة في حالات مميّزة (BTOP أو BFGS أو PERC) لعدّة ساعات. احذر من الأنماط المضادة الشائعة التالية عند تصميم الخدمات المرتبطة أو تدقيقها.

unbindService() منسي في العملاء الذين يعيشون لفترة طويلة

يؤدي الربط بخدمة من عنصر Application أحادي النسخة أو مدير يعمل في الخلفية أو Activity يستدعي bindService() في onStart() بدون unbindService() مطابق في onStop() إلى تسرُّب ServiceConnection.

وطالما ظل هذا الربط نشطًا، ستكتسب العملية المستهدَفة الأولوية الأعلى للعميل. إذا كان العميل أحد مكونات النظام الدائمة أو تطبيقًا يعمل في المقدّمة، تظل عملية الخدمة المرتبطة مثبَّتة في BFGS أو BTOP إلى أجل غير مسمى (تظهر بالقرب من% 100 في procstats)، ما يمنع LMK من استعادة الذاكرة حتى عندما تكون الخدمة غير نشطة تمامًا.

الحل: اربط النطاقات بشكل صارم بدورة حياة المكوّن الذي يحتاج إليها، أو نفِّذ مهلة عدم نشاط تستدعي unbindService() بعد فترة من عدم النشاط. تجنَّب إلغاء الربط وإعادة الربط في كل طلب فردي لإجراء مكالمة RPC، لأنّ ذلك يؤدي إلى حدوث تدهور في الأداء وتكرار عبء إعداد Binder. بدلاً من ذلك، ادمج مجموعات العمل خلف مؤقت قصير للخمول (على سبيل المثال، من 5 إلى 30 ثانية).

تضمين خدمة مرتبطة مع واجهة مستخدم تتطلّب قدرًا كبيرًا من الذاكرة

يتم تلقائيًا تشغيل جميع المكوّنات في حزمة APK في العملية نفسها. إذا كان تطبيقك يعرض خدمة مرتبطة وخفيفة الوزن (مثل NotificationListenerService أو مقدّم أداة أو خدمة إضافة يربطها النظام أو مشغّل التطبيقات) في العملية نفسها التي يتم فيها عرض Activity الرئيسي، سترث العملية بأكملها حالة الخدمة المرتفعة (BFGS أو PERC، وعادةً ما تكون oom_score_adj بقيمة 200 أو أقل).

عندما يفتح المستخدم واجهة مستخدم تطبيقك، تُخصّص العملية تسلسلات هرمية كبيرة للعرض وصور نقطية تم فك ترميزها ومخازن مؤقتة للرسومات. عندما ينتقل المستخدم إلى شاشة أخرى، لا تنخفض الأولوية إلى CACHED (oom_score_adj أو أعلى من 900) لأنّ ربط الخدمة النشطة يحافظ على أولوية العملية. ويؤدي ذلك إلى حدوث مشكلتين متفاقمتين:

• عدم ضغط الذاكرة في الخلفية: لا يضغط نظام التشغيل CachedAppOptimizer العمليات إلا بعد أن تنتقل إلى الحالة CACHED.
• عدم تقليل حجم الذاكرة المخزّنة مؤقتًا وفقًا لخوارزمية LRU أو استرداد الذاكرة من خلال LMK: لا يقدّم النظام عمليات معاودة الاتصال لتقليل حجم الذاكرة في الخلفية المرتبطة بقائمة LRU المخزّنة مؤقتًا (TRIM_MEMORY_BACKGROUND والإصدارات الأحدث) عندما يكون ربط الخدمة يحافظ على حالة مرتفعة للعملية. إذا لم يحرّر تطبيقك موارد واجهة المستخدم بشكل صريح عند استدعاء TRIM_MEMORY_UI_HIDDEN أو Activity.onStop()، ستبقى عمليات تخصيص واجهة المستخدم القصوى مثبّتة في ذاكرة الوصول العشوائي (RAM) عند درجة OOM مميّزة لا يمكن لعملية LMK استردادها بسهولة.

الحلّ: يمكنك إخلاء ذاكرات التخزين المؤقت لواجهة المستخدم، والصور النقطية التي تم فك ترميزها، ومراجع العرض بشكل صريح عندما تتوقف واجهة المستخدم عن الظهور، وذلك باستخدام Activity.onStop() أو ComponentCallbacks2.onTrimMemory(TRIM_MEMORY_UI_HIDDEN) أو Application.ActivityLifecycleCallbacks أو ProcessLifecycleOwner. بدلاً من ذلك، يمكنك نقل الخدمة المرتبطة دائمًا إلى عملية منفصلة وخفيفة الوزن باستخدام سمة android:process في ملف البيان، كي يتمكّن النظام من نقل عملية واجهة المستخدم الرئيسية إلى الحالة CACHED لضغط الذاكرة أو استردادها بشكل مستقل.

إغفال علامات إيقاف الأولوية

يؤدي استدعاء bindService() مع BIND_AUTO_CREATE فقط إلى نقل الأولوية الكاملة للجدولة والذاكرة الخاصة بالمتصل إلى الخدمة المستهدفة. عندما يربط تطبيق يعمل في المقدّمة خدمة تعمل في الخلفية خاصة بالإحصاءات أو التسجيل أو الجلب المسبق باستخدام BIND_AUTO_CREATE فقط، تتم ترقية عامل الخلفية هذا إلى BTOP بدون قصد.

الحلّ: عند الربط بالخدمات المساعدة أو الخدمات التي تبذل قصارى جهدها والتي لا تحتاج إلى مستوى الحماية نفسه الذي توفّره واجهة المستخدم التي تعمل في المقدّمة، ادمِج BIND_AUTO_CREATE مع BIND_WAIVE_PRIORITY أو BIND_NOT_FOREGROUND أو BIND_NOT_PERCEPTIBLE حتى يتمكّن النظام من مواصلة إدارة العملية المستهدَفة في قائمة العناصر الأقل استخدامًا والأحدث (LRU) المخزَّنة مؤقتًا.

← Locality | ↑ Up | System-wide →