در پشته گرافیکی، یک حافظه پنهان بافر به ازای هر لایه بین Composer HAL و SurfaceFlinger قرار دارد تا سربار مرتبط با ارسال توصیف‌گرهای فایل از طریق IPC را کاهش دهد. قبل از اندروید ۱۴، سیستم این حافظه پنهان بافر را هنگامی که یک GraphicBufferProducer از GraphicBufferConsumer مربوط به SurfaceFlinger جدا می‌شود، پاک نمی‌کرد، به عنوان مثال، هنگامی که یک MediaCodec از SurfaceView جدا می‌شود. با شروع اندروید ۱۴، می‌توانید این حافظه پنهان بافر را به زور پاک کنید تا مصرف حافظه گرافیکی کاهش یابد.
از بین دو گزینه زیر یکی را انتخاب کنید:
- برای دستگاه‌هایی که با اندروید ۱۴ و بالاتر عرضه می‌شوند، باید Composer HAL API جدید نسخه ۳.۲ را پیاده‌سازی کنید. این گزینه به طور پیش‌فرض فعال است و حداکثر مقدار حافظه را ذخیره می‌کند. دستگاه‌هایی که به ۱۴ و بالاتر ارتقا می‌یابند نیز می‌توانند از این گزینه برای دستیابی به مزایای کامل حافظه استفاده کنند.
- برای دستگاه‌هایی که به اندروید ۱۴ ارتقا می‌دهند و نمی‌خواهید Composer HAL 3.2 API را روی آنها پیاده‌سازی کنید، می‌توانید گزینه سازگاری با نسخه‌های قبلی را فعال کنید. این گزینه تقریباً به اندازه گزینه قبلی در مصرف حافظه صرفه‌جویی می‌کند.
دو بخش زیر نحوه اجرای هر گزینه را توضیح می‌دهد.
پیاده‌سازی رابط برنامه‌نویسی کاربردی Composer HAL 3.2
برای دستیابی به مزایای کامل حافظه بافر گرافیکی، باید:
- پیاده‌سازی Composer HAL خود را به نسخه ۳.۲ به‌روزرسانی کنید.
- با پاک کردن ورودی‌های حافظه نهان بافر که با شماره اسلات‌های موجود در لیست مشخص شده‌اند،
LayerCommand::bufferSlotsToClearرا پردازش کنید.
رابط‌های برنامه‌نویسی کاربردی (API) مربوط به حافظه بافر گرافیکی در Composer HAL 3.2، از جمله LayerCommand::bufferSlotsToClear ، در فایل LayerCommand.aidl قرار دارند.
گزینه سازگاری با نسخه‌های قبلی را فعال کنید
گزینه کاهش حافظه سازگار با نسخه‌های قبلی، یک بافر واقعی در اسلات کش را با یک بافر جایگزین ۱x۱ جایگزین می‌کند. این امر منجر به صرفه‌جویی در حافظه برای همه اسلات‌های پاک‌شده، به جز اسلات بافر فعال فعلی، می‌شود. برای دستیابی به مزایای صرفه‌جویی جزئی در حافظه، گزینه سازگار با نسخه‌های قبلی را با تنظیم sysprop مربوط به surface_flinger.clear_slots_with_set_layer_buffer روی true فعال کنید. این sysprop در فایل property_contexts یافت می‌شود.
تنظیم این sysprop مستلزم آن است که پیاده‌سازی Composer HAL شما به درستی چندین دستور setLayerBuffer برای همان لایه در یک چرخه فعلی واحد مدیریت کند.
فعال کردن گزینه سازگاری با نسخه‌های قبلی، اثرات زیر را دارد:
برای HAL های AIDL: SurfaceFlinger چندین نمونه
LayerCommandبرای یک لایه واحد ارسال می‌کند که هر کدام دارای یکBufferCommandواحد هستند. هرBufferCommandشامل یک دسته بافر 1x1 و یک شماره اسلات برای اسلات بافر کش است که نیاز به پاکسازی دارد.برای HAL های HIDL: SurfaceFlinger چندین دستور
SELECT_DISPLAY،SELECT_LAYER،SET_BUFFERارسال می‌کند. این دستورات حاوی یک دسته بافر 1x1 و یک شماره اسلات برای اسلات بافر کش هستند که نیاز به پاکسازی دارد.
گزینه سازگاری با نسخه‌های قبلی ممکن است باعث شود Composer HAL در برخی دستگاه‌ها از کار بیفتد. شما می‌توانید Composer HAL خود را برای حل این مشکل تغییر دهید. کدی که این رفتار را کنترل می‌کند در اینجا یافت می‌شود:
تست مصرف حافظه کش بافر گرافیکی
آزمایش‌ها نمی‌توانند تأیید کنند که آیا پیاده‌سازی‌های HAL اسلات‌های حافظه پنهان را پاک می‌کنند یا خیر. با این حال، می‌توانید از ابزارهای اشکال‌زدایی خود برای نظارت بر استفاده از بافر گرافیکی استفاده کنید. هنگام نظارت، ممکن است در سناریوهایی که چندین ویدیوی مختلف در YouTube به سرعت متوقف و شروع می‌شوند، متوجه خطاهای کمبود حافظه کمتری شوید.
تست‌های VTS موجود هستند که تأیید می‌کنند پیاده‌سازی HAL از نظر عملکردی قادر به دریافت فراخوانی‌های API جدید (HAL نسخه ۳.۲+) یا چندین دستور setLayerBuffer برای پیاده‌سازی سازگار با نسخه‌های قبلی است. با این حال، این نباید به عنوان آزمایش کافی برای عملکرد مناسب در نظر گرفته شود، زیرا برخی از دستگاه‌ها این تست‌های VTS را پشت سر می‌گذارند، اما در موارد استفاده در دنیای واقعی شکست می‌خورند.
برای مشاهده تست‌های جدید VTS به لینک‌های زیر مراجعه کنید: