اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release
بدلاً من aosp-main
لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
إدارة إطار التخزين المؤقت للعميل
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
بدءًا من الإصدار 13 من نظام التشغيل Android، يتم تخصيص إطارات عرض جديدة، والتي يتم استخدامها أثناء عملية compositing في العملاء، عند تغيُّر درجة دقة الشاشة. ينفِّذ SurfaceFlinger عملية التخصيص هذه في دورة إبطال التالية
بعد تغيير درجة الدقة.
إدارة إطار الذاكرة أثناء تبديل درجة الدقة
تحدث تغييرات الدقة بسبب أحد السيناريوهَين التاليَين:
حدث hotplug، وهو حدث بدأه "أداة إنشاء الأجهزة" (HWC)، والذي يحدث عند التبديل من شاشة خارجية واحدة إلى شاشة خارجية مختلفة ذات دقة تلقائية مختلفة.
أثناء حدث hotplug، يتم تحرير مقابض إطارات الذاكرة القديمة
عند إلغاء تخصيص بيانات العرض القديمة.
تبديل وضع العرض الذي يبدأه SurfaceFlinger، والذي يحدث عندما يغيّر
المستخدم الدقة باستخدام إعدادات المستخدم،
أو عندما يغيّر أحد التطبيقات الدقة باستخدام preferredDisplayModeId
.
أثناء تبديل وضع العرض، يُطلق SurfaceFlinger عناوين ذاكرة التخزين المؤقت لإطارات العميل الحالية
قبل استدعاء setActiveConfig
أو setActiveConfigWithConstraints
.
لتجنّب حدوث مشاكل خطيرة، مثل تجزئة الذاكرة، على الأجهزة التي
لا تحجز ذاكرة كافية لإطارَي التخزين المؤقت القديم والجديد، من الضروري
أن يتوقف "العرض التقديمي للرسومات في الأجهزة الجوّالة" عن استخدام إطارَي التخزين المؤقت القديمين وأن يُطلق أي
مرجعَي ذاكرة لإطارَي التخزين المؤقت هذين كما هو موضّح في الحالات التالية:
يسمح تحرير المعرّفات بإلغاء تخصيص ذاكرة إطار التخزين المؤقت بالكامل
قبل تخصيص إطارات تخزين مؤقت جديدة ينفّذها SurfaceFlinger
أثناء دورة إلغاء الصلاحية التالية.
اقتراحات لإدارة ذاكرة التخزين المؤقت للإطار
إذا لم تُفرِج واجهة برمجة التطبيقات لوحدة معالجة الرسومات عن مقابض ذاكرة التخزين المؤقت للإطارات القديمة في الوقت المناسب،
يحدث تخصيص ذاكرة التخزين المؤقت للإطار الجديد قبل إزالة تخصيص ذاكرة التخزين المؤقت للإطار القديم. ويمكن أن يؤدي ذلك إلى حدوث مشاكل خطيرة عند تعذُّر عملية التوزيع الجديدة
بسبب التجزئة أو مشاكل أخرى. والأسوأ من ذلك، إذا
لم تُطلق معالجة "الطلبات العالية الخطورة" هذه الأسماء المعرِّفة على الإطلاق، يمكن أن يؤدي ذلك إلى
تسرُّب الذاكرة.
لتجنُّب حالات تعذُّر التخصيص بشكلٍ كارثي، اتّبِع الاقتراحات التالية:
إذا كان يجب أن يواصل "العرض المتقدّم للرسومات" استخدام إطارات عرض العملاء القديمة إلى أن يتم توفير ملفّات عرض العملاء الجديدة، من المهم حجز ذاكرة كافية لملفّات العرض القديمة والجديدة، وربما تشغيل خوارزميات إزالة التجزئة على مساحة ذاكرة ملفّ العرض.
تخصيص ذاكرة مخصّصة لإطارات الذاكرة التي تكون منفصلة عن
باقي ذاكرة المخزن المؤقت للرسومات وهذا أمر مهم لأنّه بين
إلغاء تخصيص وإعادة تخصيص إطارات الذاكرة، يمكن لعملية تابعة لجهة خارجيةمحاولة تخصيص ذاكرة الرسومات. إذا كان إطار التخزين المؤقت للرسومات يستخدم ذاكرة الرسومات نفسها وكانت ذاكرة الرسومات ممتلئة، يمكن للعملية التابعة لجهة خارجية أن تشغَل ذاكرة الرسومات التي تم تخصيصها سابقًا لإطار التخزين المؤقت للرسومات، وبالتالي لن تتوفّر ذاكرة كافية لإعادة تخصيص إطار التخزين المؤقت للرسومات أو قد يؤدي ذلك إلى تجزئة مساحة الذاكرة.
اختبار إدارة إطار الذاكرة
ننصح المصنّعين الأصليّين للأجهزة باختبار إدارة ذاكرة إطار التخزين المؤقت للعميل بشكلٍ سليم على مستوى
مبدّلات الدقة لجهازهم، كما هو موضّح أدناه:
بالنسبة إلى أحداث التوصيل السريع، ما عليك سوى فصل شاشتَين مختلفتَين بدقةَين مختلفتَين وإعادة توصيلها.
بالنسبة إلى عمليات تبديل الأوضاع، استخدِم اختبار ModeSwitchingTestActivity
CTS
Verifier لبدء تبديل الوضع من أجل اختبار سلوك ذاكرة إطار التخزين المؤقت.
يمكن لهذا الاختبار تحديد المشاكل التي يصعب رصدها
برمجيًا بشكل مرئي.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["# Client framebuffer management\n\nStarting with Android 13, new framebuffers, used during\n[client](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/DisplayCommand.aidl#113)\ncomposition, are allocated whenever the display resolution changes. This\nallocation is performed by SurfaceFlinger on the next *invalidate* cycle\nafter a resolution change.\n\nFramebuffer management during resolution switches\n-------------------------------------------------\n\nResolution changes occur due to one of the following\ntwo scenarios:\n\n- A [hotplug event](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerCallback.aidl#41),\n initiated by Hardware Composer (HWC), which occurs when swapping from one external\n display to a different external display that has a different default resolution.\n\n During a hotplug event, the handles to the old framebuffers are released\n when the old display data is deallocated.\n- A display mode switch initiated by SurfaceFlinger, which occurs when the\n user changes the resolution with [user settings](https://android.googlesource.com/platform/frameworks/base/+/refs/heads/android16-release/core/java/android/hardware/display/DisplayManager.java#1209),\n or an app changes the resolution with [`preferredDisplayModeId`](https://developer.android.com/reference/android/view/WindowManager.LayoutParams#preferredDisplayModeId).\n\n During a display mode switch, the handles to existing client framebuffers\n are released by SurfaceFlinger before calling [`setActiveConfig`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerClient.aidl#550)\n or [`setActiveConfigWithConstraints`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerClient.aidl#577).\n\nTo avoid catastrophic problems, such as memory fragmentation, on devices that\ndon't reserve enough memory for the old and new framebuffers, it's critical\nthat HWC ceases to use the old framebuffers and releases any\nhandles to these framebuffers as shown in the following cases:\n\n- For hotplug events, immediately before calling [`onHotplug`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerCallback.aidl#41).\n\n- For mode switches, immediately after the call to [`setActiveConfig`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerClient.aidl#550)\n or [`setActiveConfigWithConstraints`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerClient.aidl#577).\n\nReleasing the handles allows the framebuffer memory to be fully deallocated\nprior to the allocation of new framebuffers that SurfaceFlinger performs\nduring the next *invalidate* cycle.\n\n### Recommendations for framebuffer management\n\nIf HWC doesn't release handles to old framebuffers in time,\nthe new framebuffer allocation takes place before the old framebuffer\ndeallocation. This can cause catastrophic problems when the new allocation fails\ndue to fragmentation or other issues. Even worse, if\nHWC doesn't release these handles at all, a memory leak can\noccur.\n\nTo avoid catastrophic allocation failures, follow these recommendations:\n\n- If HWC needs to continue using the old client framebuffers until the new\n client framebuffers are provided, then it's critical to reserve enough memory\n for both the old and new framebuffers, and possibly run defragmentation\n algorithms on the framebuffer memory space.\n\n- Allocate a dedicated memory pool for the framebuffers that's separate from\n the rest of the graphic buffer memory. This is important because between\n deallocation and reallocation of the framebuffers, a third-party process can\n attempt to allocate graphics memory. If the same graphics memory pool is\n used by the framebuffer and if the graphics memory is full, the third-party\n process can occupy the graphics memory previously allocated by a framebuffer,\n thus leaving insufficient memory for the framebuffer reallocation or, possibly\n fragmenting the memory space.\n\nTest framebuffer management\n---------------------------\n\nOEMs are advised to test for proper client framebuffer memory management across\nresolution switches for their device, described as follows:\n\n- For hotplug events, simply unplug and reconnect two different displays with\n different resolutions.\n\n- For mode switches, use the [`ModeSwitchingTestActivity`](https://cs.android.com/android/platform/superproject/+/android-latest-release:cts/apps/CtsVerifier/src/com/android/cts/verifier/tv/display/ModeSwitchingTestActivity.java;l=47-53;drc=c80d948aff1e7df5c2dc0ddba0d1cd63a90e4d9c) CTS\n Verifier test to initiate a mode switch for testing framebuffer memory behavior.\n This test can visually identify problems that are hard to detect\n programmatically."]]