از 27 مارس 2025، توصیه می کنیم از android-latest-release
به جای aosp-main
برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
مدیریت فریم بافر مشتری
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
با شروع اندروید 13، فریم بافرهای جدیدی که در ترکیب کلاینت استفاده میشوند، هر زمان که وضوح نمایشگر تغییر میکند، اختصاص داده میشوند. این تخصیص توسط SurfaceFlinger در چرخه ابطال بعدی پس از تغییر وضوح انجام می شود.
مدیریت فریم بافر در هنگام سوئیچ وضوح
تغییرات وضوح به دلیل یکی از دو سناریو زیر رخ می دهد:
یک رویداد hotplug ، که توسط Hardware Composer (HWC) آغاز شده است، که هنگام جابجایی از یک نمایشگر خارجی به یک صفحه نمایش خارجی متفاوت که وضوح پیش فرض متفاوتی دارد، رخ می دهد.
در طول یک رویداد hotplug، دستههای فریمبافرهای قدیمی زمانی که دادههای صفحه نمایش قدیمی توزیع میشوند، آزاد میشوند.
یک سوئیچ حالت نمایش که توسط SurfaceFlinger راه اندازی شده است، که زمانی رخ می دهد که کاربر وضوح تصویر را با تنظیمات کاربر تغییر می دهد، یا یک برنامه وضوح را با preferredDisplayModeId
تغییر می دهد.
در طی یک سوئیچ حالت نمایش، دستههای فریم بافرهای مشتری موجود قبل از فراخوانی setActiveConfig
یا setActiveConfigWithConstraints
توسط SurfaceFlinger آزاد میشوند.
برای جلوگیری از مشکلات فاجعه بار، مانند تکه تکه شدن حافظه، در دستگاههایی که حافظه کافی برای فریم بافرهای قدیمی و جدید ذخیره نمیکنند، بسیار مهم است که HWC استفاده از فریمبافرهای قدیمی را متوقف کند و همانطور که در موارد زیر نشان داده شده است، هر دستهای را روی این فریمبافرها آزاد کند:
رها کردن دستهها به حافظه فریم بافر اجازه میدهد تا قبل از تخصیص فریمبافرهای جدید که SurfaceFlinger در چرخه بیاعتبار بعدی انجام میدهد، به طور کامل جابجا شود.
توصیه هایی برای مدیریت فریم بافر
اگر HWC به موقع دسته ها را به فریم بافرهای قدیمی رها نکند، تخصیص بافر فریم جدید قبل از تخصیص فریم بافر قدیمی انجام می شود. هنگامی که تخصیص جدید به دلیل پراکندگی یا سایر مسائل با شکست مواجه می شود، این می تواند مشکلات فاجعه باری ایجاد کند. حتی بدتر از آن، اگر HWC اصلاً این دسته ها را آزاد نکند، ممکن است نشت حافظه رخ دهد.
برای جلوگیری از شکست های فاجعه بار تخصیص، توصیه های زیر را دنبال کنید:
اگر HWC نیاز به استفاده از فریم بافرهای مشتری قدیمی تا زمانی که فریم بافرهای کلاینت جدید ارائه شود، ادامه دهد، مهم است که حافظه کافی برای فریم بافرهای قدیمی و جدید ذخیره کنید و احتمالاً الگوریتم های یکپارچه سازی را در فضای حافظه فریم بافر اجرا کنید.
یک مخزن حافظه اختصاصی برای فریم بافرها اختصاص دهید که از بقیه حافظه بافر گرافیکی جدا باشد. این مهم است زیرا بین توزیع و تخصیص مجدد فریم بافرها، یک فرآیند شخص ثالث می تواند تلاش کند تا حافظه گرافیکی را تخصیص دهد. اگر از همان مخزن حافظه گرافیکی توسط فریم بافر استفاده شود و اگر حافظه گرافیکی پر باشد، فرآیند شخص ثالث می تواند حافظه گرافیکی را که قبلاً توسط یک فریم بافر تخصیص داده شده بود اشغال کند، بنابراین حافظه کافی برای تخصیص مجدد فریم بافر باقی نمی ماند یا احتمالاً فضای حافظه را تکه تکه می کند.
تست مدیریت فریم بافر
به OEM ها توصیه می شود که مدیریت مناسب حافظه فریم بافر کلاینت را در سراسر سوئیچ های وضوح دستگاه خود آزمایش کنند که به شرح زیر است:
برای رویدادهای hotplug، به سادگی دو نمایشگر مختلف با وضوح متفاوت را جدا کرده و دوباره وصل کنید.
برای سوئیچهای حالت، از تست ModeSwitchingTestActivity
CTS Verifier برای شروع یک سوئیچ حالت برای آزمایش رفتار حافظه فریم بافر استفاده کنید. این تست میتواند مشکلاتی را که به سختی قابل تشخیص هستند، شناسایی کند.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-29 بهوقت ساعت هماهنگ جهانی."],[],[],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."]]