کاهش مصرف حافظه گرافیکی

در پشته گرافیکی، یک کش بافر در هر لایه بین Composer HAL و SurfaceFlinger قرار می‌گیرد تا سربار مربوط به ارسال توصیفگرهای فایل از طریق IPC را کاهش دهد. قبل از Android 14، هنگامی که یک GraphicBufferProducer از SurfaceFlinger GraphicBufferConsumer جدا می‌شود، این کش بافر پاک نمی‌شد، مانند زمانی که MediaCodec از SurfaceView قطع می‌شود. با شروع اندروید 14، می‌توانید این کش بافر را به اجبار پاک کنید تا مصرف حافظه گرافیکی را کاهش دهید.

یکی از دو گزینه زیر را انتخاب کنید:

  • برای دستگاه‌هایی که با Android 14 و بالاتر راه‌اندازی می‌شوند، باید Composer HAL API جدید نسخه 3.2 را پیاده‌سازی کنید. این گزینه به صورت پیش فرض فعال است و بیشترین ذخیره حافظه را ذخیره می کند. دستگاه های ارتقا یافته به 14 و بالاتر نیز می توانند از این گزینه برای دستیابی به مزایای حافظه کامل استفاده کنند.
  • برای دستگاه‌هایی که به Android 14 ارتقا می‌یابند و نمی‌خواهید Composer HAL 3.2 API را برای آن‌ها پیاده‌سازی کنید، می‌توانید گزینه سازگار با عقب را فعال کنید. این گزینه تقریباً به اندازه گزینه قبلی حافظه ذخیره می کند.

دو بخش زیر نحوه پیاده سازی هر گزینه را توضیح می دهد.

API Composer HAL 3.2 را پیاده سازی کنید

برای دستیابی به مزایای کامل حافظه بافر گرافیکی، باید:

  1. پیاده سازی Composer HAL خود را به نسخه 3.2 به روز کنید.
  2. Process LayerCommand::bufferSlotsToClear با پاک کردن ورودی های حافظه پنهان بافر که با شماره های اسلات موجود در لیست مشخص شده اند.

API های Composer HAL 3.2 مربوط به حافظه بافر گرافیکی، از جمله LayerCommand:bufferSlotsToClear ، در LayerCommand.aidl- هستند.

گزینه backward-compatible را فعال کنید

گزینه کاهش حافظه سازگار با عقب، یک بافر واقعی در شکاف حافظه پنهان را با یک بافر نگهدارنده 1×1 جایگزین می کند، که منجر به صرفه جویی در حافظه برای همه اسلات های پاک شده، به جز اسلات بافر فعال فعلی می شود. برای دستیابی به مزایای صرفه جویی جزئی حافظه، گزینه سازگار با عقب را با تنظیم sysprop surface_flinger.clear_slots_with_set_layer_buffer روی true فعال کنید. این sysprop در فایل property_contexts یافت می شود.

تنظیم این sysprop به پیاده سازی Composer HAL شما نیاز دارد که چندین دستور setLayerBuffer برای یک لایه در یک چرخه فعلی به درستی مدیریت کند.

فعال کردن گزینه backward-compatible اثرات زیر را دارد:

  • برای HAL های AIDL: SurfaceFlinger چندین نمونه LayerCommand برای یک لایه ارسال می کند که هر کدام دارای یک BufferCommand است. هر BufferCommand شامل یک دسته بافر 1x1 و یک عدد اسلات برای اسلات بافر کش است که باید پاک شود.

  • برای HIDL HAL: SurfaceFlinger چندین دستور SELECT_DISPLAY ، SELECT_LAYER ، SET_BUFFER را ارسال می کند. این دستورات شامل یک دسته بافر 1x1 و یک عدد شکاف برای اسلات بافر کش است که باید پاک شود.

گزینه سازگار با عقب ممکن است باعث از کار افتادن Composer HAL در برخی دستگاه‌ها شود. ممکن است بتوانید Composer HAL خود را برای حل این مشکل تغییر دهید. کد کنترل کننده این رفتار در اینجا یافت می شود:

تست مصرف حافظه کش بافر گرافیکی

آزمایش‌ها نمی‌توانند تأیید کنند که آیا شکاف‌های حافظه پنهان توسط اجرای HAL پاک می‌شوند یا خیر. با این حال، می توانید از ابزارهای اشکال زدایی خود برای نظارت بر استفاده از بافر گرافیکی استفاده کنید. همانطور که نظارت می کنید، باید متوجه شوید که در سناریوهایی که در آن چندین ویدیوی مختلف متوقف می شوند و به سرعت در YouTube شروع می شوند، خطاهای کمتری وجود دارد.

تست‌های VTS در دسترس هستند که تأیید می‌کنند اجرای HAL از نظر عملکردی قادر به دریافت فراخوان‌های API جدید (HAL نسخه 3.2+) یا چند دستور setLayerBuffer برای پیاده‌سازی سازگار با عقب است. با این حال، این نباید تست کافی برای عملکرد مناسب در نظر گرفته شود، زیرا برخی از دستگاه‌ها این تست‌های VTS را پشت سر می‌گذارند، اما در موارد استفاده در دنیای واقعی شکست می‌خورند.

برای تست های جدید VTS، به لینک های زیر بروید:

،

در پشته گرافیکی، یک کش بافر در هر لایه بین Composer HAL و SurfaceFlinger قرار می‌گیرد تا سربار مربوط به ارسال توصیفگرهای فایل از طریق IPC را کاهش دهد. قبل از Android 14، هنگامی که یک GraphicBufferProducer از SurfaceFlinger GraphicBufferConsumer جدا می‌شود، این کش بافر پاک نمی‌شد، مانند زمانی که MediaCodec از SurfaceView قطع می‌شود. با شروع اندروید 14، می‌توانید این کش بافر را به اجبار پاک کنید تا مصرف حافظه گرافیکی را کاهش دهید.

یکی از دو گزینه زیر را انتخاب کنید:

  • برای دستگاه‌هایی که با Android 14 و بالاتر راه‌اندازی می‌شوند، باید Composer HAL API جدید نسخه 3.2 را پیاده‌سازی کنید. این گزینه به صورت پیش فرض فعال است و بیشترین ذخیره حافظه را ذخیره می کند. دستگاه های ارتقا یافته به 14 و بالاتر نیز می توانند از این گزینه برای دستیابی به مزایای حافظه کامل استفاده کنند.
  • برای دستگاه‌هایی که به Android 14 ارتقا می‌یابند و نمی‌خواهید Composer HAL 3.2 API را برای آن‌ها پیاده‌سازی کنید، می‌توانید گزینه سازگار با عقب را فعال کنید. این گزینه تقریباً به اندازه گزینه قبلی حافظه ذخیره می کند.

دو بخش زیر نحوه پیاده سازی هر گزینه را توضیح می دهد.

API Composer HAL 3.2 را پیاده سازی کنید

برای دستیابی به مزایای کامل حافظه بافر گرافیکی، باید:

  1. پیاده سازی Composer HAL خود را به نسخه 3.2 به روز کنید.
  2. Process LayerCommand::bufferSlotsToClear با پاک کردن ورودی های حافظه پنهان بافر که با شماره های اسلات موجود در لیست مشخص شده اند.

API های Composer HAL 3.2 مربوط به حافظه بافر گرافیکی، از جمله LayerCommand:bufferSlotsToClear ، در LayerCommand.aidl- هستند.

گزینه backward-compatible را فعال کنید

گزینه کاهش حافظه سازگار با عقب، یک بافر واقعی در شکاف حافظه پنهان را با یک بافر نگهدارنده 1×1 جایگزین می کند، که منجر به صرفه جویی در حافظه برای همه اسلات های پاک شده، به جز اسلات بافر فعال فعلی می شود. برای دستیابی به مزایای صرفه جویی جزئی حافظه، گزینه سازگار با عقب را با تنظیم sysprop surface_flinger.clear_slots_with_set_layer_buffer روی true فعال کنید. این sysprop در فایل property_contexts یافت می شود.

تنظیم این sysprop به پیاده سازی Composer HAL شما نیاز دارد که چندین دستور setLayerBuffer برای یک لایه در یک چرخه فعلی به درستی مدیریت کند.

فعال کردن گزینه backward-compatible اثرات زیر را دارد:

  • برای HAL های AIDL: SurfaceFlinger چندین نمونه LayerCommand برای یک لایه ارسال می کند که هر کدام دارای یک BufferCommand است. هر BufferCommand شامل یک دسته بافر 1x1 و یک عدد اسلات برای اسلات بافر کش است که باید پاک شود.

  • برای HIDL HAL: SurfaceFlinger چندین دستور SELECT_DISPLAY ، SELECT_LAYER ، SET_BUFFER را ارسال می کند. این دستورات شامل یک دسته بافر 1x1 و یک عدد شکاف برای اسلات بافر کش است که باید پاک شود.

گزینه سازگار با عقب ممکن است باعث از کار افتادن Composer HAL در برخی دستگاه‌ها شود. ممکن است بتوانید Composer HAL خود را برای حل این مشکل تغییر دهید. کد کنترل کننده این رفتار در اینجا یافت می شود:

تست مصرف حافظه کش بافر گرافیکی

آزمایش‌ها نمی‌توانند تأیید کنند که آیا شکاف‌های حافظه پنهان توسط اجرای HAL پاک می‌شوند یا خیر. با این حال، می توانید از ابزارهای اشکال زدایی خود برای نظارت بر استفاده از بافر گرافیکی استفاده کنید. همانطور که نظارت می کنید، باید متوجه شوید که در سناریوهایی که در آن چندین ویدیوی مختلف متوقف می شوند و به سرعت در YouTube شروع می شوند، خطاهای کمتری وجود دارد.

تست‌های VTS در دسترس هستند که تأیید می‌کنند اجرای HAL از نظر عملکردی قادر به دریافت فراخوان‌های API جدید (HAL نسخه 3.2+) یا چند دستور setLayerBuffer برای پیاده‌سازی سازگار با عقب است. با این حال، این نباید تست کافی برای عملکرد مناسب در نظر گرفته شود، زیرا برخی از دستگاه‌ها این تست‌های VTS را پشت سر می‌گذارند، اما در موارد استفاده در دنیای واقعی شکست می‌خورند.

برای تست های جدید VTS، به لینک های زیر بروید: