از Android 13 به بعد، هرگاه وضوح نمایشگر تغییر کند، سیستم میانگیرهای قاب جدیدی را که درطول ترکیببندی کارخواه استفاده میشود اختصاص میدهد. SurfaceFlinger این تخصیص را در چرخه نامعتبر کردن بعدی پساز تغییر وضوح انجام میدهد.
مدیریت بافر قاب درطول تغییرات وضوح
تغییرات وضوح به یکی از دو سناریو زیر رخ میدهد:
رویداد اتصال گرم، که توسط Hardware Composer (HWC) آغاز میشود، زمانی رخ میدهد که از یک نمایشگر خارجی به نمایشگر خارجی دیگری که وضوح پیشفرض متفاوتی دارد جابهجا میشوید.
درطول رویداد اتصال داغ، HWC دستگیرهها را به قاببافرهای قدیمی وقتی دادههای نمایشگر قدیمی را لغو تخصیص میدهد منتشر میکند.
یک کلید تغییر حالت نمایش که توسط SurfaceFlinger آغاز میشود و زمانی رخ میدهد که بااستفاده از تنظیمات کاربر وضوح را تغییر دهید، یا برنامهای بااستفاده از
preferredDisplayModeIdوضوح را تغییر دهد.درطول تعویض حالت نمایشگر، SurfaceFlinger قبلاز فراخوانی
setActiveConfigیاsetActiveConfigWithConstraints، دستگیرهها را به قابهای بافر مشتری موجود واگذار میکند.
برای جلوگیری از مشکلات فاجعهبار مانند تکهتکه شدن حافظه در دستگاههای بدون حافظه کافی برای قاببافر، HWC باید دستگیرههای قاببافرهای قدیمی را آزاد کند. این مورد در موارد زیر بسیار مهم است:
برای رویدادهای اتصال سریع، بلافاصله قبلاز فراخوانی
onHotplug.برای تغییر حالت، بلافاصله پساز فراخوانی
setActiveConfigیاsetActiveConfigWithConstraints.
با آزاد کردن دستهها، حافظه قاببافر بهطور کامل تخصیص لغو میشود قبلاز اینکه SurfaceFlinger قاببافرهای جدید را درطول چرخه نامعتبر کردن بعدی تخصیص دهد.
توصیههایی برای مدیریت قاببافر
اگر HWC دستگیرهها را بهموقع به قاببافرهای قدیمی واگذار نکند، تخصیص قاببافر جدید قبلاز تخصیص قاببافر قدیمی رخ میدهد. این امر میتواند وقتی تخصیص جدید بهدلیل تکهتکه شدن یا مشکلات دیگر با شکست مواجه میشود، مشکلات فاجعهباری ایجاد کند. بدتر از آن، اگر HWC این دستگیرهها را اصلاً آزاد نکند، ممکن است نشت حافظه رخ دهد.
برای جلوگیری از خطاهای تخصیص فاجعهبار، این توصیهها را دنبال کنید:
اگر HWC باید تا زمان ارائه بافرهای قاب مشتری جدید به استفاده از بافرهای قاب مشتری قدیمی ادامه دهد، باید حافظه کافی برای بافرهای قاب قدیمی و جدید رزرو کند و احتمالاً الگوریتمهای یکپارچهسازی را در فضای حافظه بافر قاب اجرا کند.
یک استخر حافظه اختصاصی برای میانگیرهای قاب اختصاص دهید که از بقیه حافظه میانگیر گرافیکی جدا باشد. این مهم است زیرا فرایند طرف سوم ممکن است تلاش کند حافظه گرافیکی را بین لغو تخصیص و تخصیص مجدد قاببافر تخصیص دهد. اگر بافر فریم از همان مخزن حافظه گرافیکی استفاده کند و اگر حافظه گرافیکی پر باشد، فرایند شخص ثالث میتواند حافظهای را که قبلاً توسط بافر فریم اختصاص داده شده است اشغال کند. این امر میتواند منجر به حافظه ناکافی برای تخصیص مجدد قاببافر یا تکهتکه شدن حافظه شود.
مدیریت میانگیر قاب آزمایشی
به «تولیدکنندگان تجهیزات اصلی» توصیه میشود که مدیریت صحیح حافظه بافر قاب کارخواه را در تغییرات وضوح دستگاهشان آزمایش کنند، که به این شرح است:
برای رویدادهای اتصال و قطع اتصال، دو نمایشگر مختلف با وضوحهای متفاوت را قطع و وصل کنید.
برای کلیدهای حالت، از آزمایش CTS Verifier
ModeSwitchingTestActivityبرای شروع کلید حالت جهت آزمایش رفتار حافظه میانگیر قاب استفاده کنید. این آزمایش میتواند مشکلاتی را که تشخیص آنها ازطریق برنامه دشوار است بهصورت دیداری شناسایی کند.