بهینه کردن مصرف حافظه

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

مصرف بالای حافظه می‌تواند منجر به مشکلاتی در عملکرد برنامه و سیستم شود، ازجمله:

• خود برنامه ممکن است کند یا با تأخیر شود، یا در بدترین حالت، بسته شود.
• خدمات سیستم قابل‌مشاهده برای کاربر (کنترل صدا، داشبورد «تنظیمات تصویر»، «دستیار صوتی»، و غیره) بسیار کند می‌شوند یا ممکن است اصلاً کار نکنند.
• فرایند خدمتگزار بستن ناشی از کمبود حافظه (LMK) ممکن است با بستن فرایندهای کم‌اهمیت‌تر به فشار بالای حافظه واکنش نشان دهد؛ سپس این مؤلفه‌ها ممکن است اندکی بعد بازراه‌اندازی شوند و باعث ایجاد جهش در رقابت بر سر منابع شوند که می‌تواند مستقیماً بر برنامه پیش‌زمینه‌ای تأثیر بگذارد.
• انتقال به «راه‌انداز» می‌تواند به‌طور قابل‌توجهی به‌تأخیر بیفتد و تا زمانی که انتقال کامل شود، برنامه پیش‌زمینه را درحالت غیرپاسخ‌گو نشان دهد.
• سیستم ممکن است از پس‌گیری مستقیم استفاده کند و اجرای رشته را به‌طور موقت درحین انتظار برای تخصیص حافظه متوقف کند. این مشکل می‌تواند برای هر رشته‌ای، مثل رشته اصلی یا رشته‌های مربوط به کدک، رخ دهد و احتمالاً باعث افت فریم صدا و ویدیو و اشکالات رابط کاربری شود.

ملاحظات حافظه در دستگاه‌های تلویزیون

دستگاه‌های تلویزیون معمولاً حافظه بسیار کمتری نسبت به تلفن‌ها یا رایانه‌های لوحی دارند. برای مثال، پیکربندی‌ای که می‌توانیم در تلویزیون ببینیم ۱ گیگابایت حافظه دسترسی تصادفی و وضوح ویدیو ۱۰۸۰ پیکسل است. درعین‌حال، اکثر برنامه‌های تلویزیون ویژگی‌های مشابهی دارند؛ بنابراین پیاده‌سازی مشابه و چالش‌های مشترکی دارند. این دو وضعیت مشکلاتی را ایجاد می‌کنند که در انواع دیگر دستگاه‌ها و برنامه‌ها دیده نمی‌شود:

• برنامه‌های تلویزیون رسانه‌ای معمولاً از هر دو نمای تصویر شبکه‌ای و تصاویر پس‌زمینه تمام‌صفحه تشکیل شده‌اند که نیاز به بار کردن تعداد زیادی تصویر در حافظه در مدت زمان کوتاهی دارند
• برنامه‌های تلویزیون جاری‌سازی‌های چندرسانه‌ای پخش می‌کنند که برای پخش ویدیو و صدا نیاز به تخصیص مقدار مشخصی از حافظه دارند و برای اطمینان از پخش روان به بافرهای رسانه‌ای قابل‌توجهی نیاز دارند.
• ویژگی‌های رسانه‌ای اضافی (جستجو، تغییر قسمت، تغییر قطعه صوتی، و غیره) اگر به‌درستی پیاده‌سازی نشوند، می‌توانند فشار حافظه اضافی ایجاد کنند.

آشنایی با دستگاه‌های تلویزیون

این راهنما در درجه اول بر مصرف حافظه برنامه و هدف‌های حافظه برای دستگاه‌های با حافظه دسترسی تصادفی پایین تمرکز دارد.

در دستگاه‌های تلویزیون، این ویژگی‌ها را درنظر بگیرید:

• حافظه دستگاه: مقدار «حافظه دسترسی تصادفی» (RAM) که دستگاه نصب کرده است.
• وضوح میانای کاربر دستگاه: وضوحی که دستگاه برای پرداز کردن میانای کاربر سیستم‌عامل و برنامه‌ها استفاده می‌کند؛ این وضوح معمولاً کمتر از وضوح ویدیو دستگاه است.
• وضوح ویدیو: حداکثر وضوحی که دستگاه می‌تواند ویدیوها را با آن پخش کند.

این امر منجر به دسته‌بندی انواع مختلف دستگاه و نحوه استفاده آن‌ها از حافظه می‌شود.

خلاصه دستگاه‌های تلویزیون

دستگاه‌های تلویزیون با حافظه دسترسی تصادفی پایین

این دستگاه‌ها در وضعیت محدودیت حافظه قرار دارند و ActivityManager.isLowRamDevice() را به درست گزارش خواهند کرد. برنامه‌هایی که در دستگاه‌های تلویزیون با حافظه دسترسی تصادفی پایین اجرا می‌شوند باید اقدامات کنترل حافظه اضافی را پیاده‌سازی کنند.

دستگاه‌های دارای ویژگی‌های زیر را در این دسته قرار می‌دهیم:

• دستگاه‌های ۱ گیگابایتی: ۱ گیگابایت حافظه دسترسی تصادفی، وضوح واسط کاربری ۷۲۰ پیکسل/HD ‏ (۱۲۸۰x۷۲۰)، وضوح ویدیو ۱۰۸۰ پیکسل/FullHD ‏ (۱۹۲۰x۱۰۸۰)
• دستگاه‌های ۱٫۵ گیگابایتی: ۱٫۵ گیگابایت حافظه دسترسی تصادفی، وضوح رابط کاربری ۱۰۸۰ پیکسل/وضوح بالای کامل (۱۹۲۰x۱۰۸۰)، وضوح ویدیو ۲۱۶۰ پیکسل/وضوح بسیار بالا/۴K (۳۸۴۰x۲۱۶۰)
• موقعیت‌های دیگری که در آن سازنده اصلی محصول به‌دلیل محدودیت‌های حافظه اضافی، پرچم ActivityManager.isLowRamDevice() را تعریف کرده است.

دستگاه‌های تلویزیون معمولی

این دستگاه‌ها با چنین وضعیت فشار حافظه قابل‌توجهی مواجه نمی‌شوند. ما این دستگاه‌ها را دارای ویژگی‌های زیر می‌دانیم:

• ‫≥۱٫۵ گیگابایت RAM، رابط کاربری ۷۲۰ پیکسل یا ۱۰۸۰ پیکسل، و وضوح ویدیو ۱۰۸۰ پیکسل
• ‫≥۲ گیگابایت RAM، رابط کاربری ۱۰۸۰ پیکسل، و وضوح ویدیو ۱۰۸۰ پیکسل یا ۲۱۶۰ پیکسل

این بدان معنا نیست که برنامه‌ها نباید به استفاده از حافظه در این دستگاه‌ها اهمیت دهند، زیرا برخی‌از سوءاستفاده‌های خاص از حافظه همچنان می‌تواند حافظه دردسترس را تمام کند و عملکرد ضعیفی داشته باشد.

هدف‌های حافظه در دستگاه‌های تلویزیون با حافظه دسترسی تصادفی پایین

هنگام اندازه‌گیری حافظه در این دستگاه‌ها، به‌شدت توصیه می‌کنیم بااستفاده از نمایه‌گر حافظه Android Studio، هر بخش از حافظه را پایش کنید. برنامه‌های تلویزیون باید میزان استفاده از حافظه خود را نمایه‌بندی کنند و تلاش کنند تا دسته‌های خود را زیر آستانه‌هایی که در این بخش تعریف می‌کنیم قرار دهند.

در بخش نحوه محاسبه حافظه توضیحات مفصلی درباره ارقام حافظه گزارش‌شده خواهید یافت. برای تعریف آستانه‌ها برای برنامه‌های تلویزیون، روی سه دسته حافظه تمرکز خواهیم کرد:

• ناشناس + مبادله: متشکل از Java + Native + حافظه تخصیص پشته در Android Studio.
• گرافیک: مستقیماً در ابزار نمایه‌گر گزارش شده است. معمولاً از بافت‌های گرافیکی تشکیل شده است.
• فایل: در Android Studio به‌عنوان دسته‌های «کد» + «موارد دیگر» گزارش شده است.

با این تعاریف، جدول زیر نشان می‌دهد که هر نوع گروه حافظه باید از حداکثر چه مقداری استفاده کند:

حداکثر حافظه کل (Anon+Swap + Graphics + File) نباید از موارد زیر بیشتر باشد:

• ۲۸۰ مگابایت از کل مصرف حافظه (Anon+Swap + Graphics + File) برای دستگاه‌های با حافظه دسترسی تصادفی کمتر از ۱ گیگابایت.

به‌شدت توصیه می‌شود از این موارد فراتر نروید:

• ‫۲۰۰ مگابایت استفاده از حافظه در (Anon+Swap + Graphics).

حافظه فایل

به‌عنوان راهنمایی کلی برای حافظه پشتیبان‌گیری‌شده فایل، به این موارد توجه کنید:

• به‌طورکلی، مدیریت حافظه سیستم‌عامل حافظه فایل را به‌خوبی مدیریت می‌کند.
• درحال‌حاضر متوجه نشده‌ایم که این ویژگی دلیل اصلی فشار حافظه باشد.

بااین‌حال، هنگام کار با حافظه «فایل» به‌طور کلی:

• کتابخانه‌های استفاده‌نشده را به ساخت خود اضافه نکنید و درصورت امکان، به‌جای کتابخانه‌های کامل از زیرمجموعه‌های کوچک کتابخانه‌ها استفاده کنید.
• فایل‌های بزرگ را در حافظه باز نگه ندارید و به‌محض اینکه کارتان با آن‌ها تمام شد، آن‌ها را ببندید.
• برای کلاس‌های جاوا و Kotlin، اندازه کد کامپایل‌شده را به‌حداقل برسانید، راهنمای کوچک کردن، مبهم‌سازی، و بهینه‌سازی برنامه را ببینید.

توصیه‌های ویژه تلویزیون

این بخش توصیه‌های ویژه‌ای برای بهینه‌سازی استفاده از حافظه در دستگاه‌های تلویزیون ارائه می‌دهد.

حافظه گرافیک

از قالب‌ها و وضوح‌های تصویر مناسب استفاده کنید.

• تصاویر با وضوح بالاتر از وضوح میانای کاربر دستگاه را بار نکنید. برای مثال، تصاویر ۱۰۸۰ پیکسل باید در دستگاه با رابط کاربری ۷۲۰ پیکسل به ۷۲۰ پیکسل کوچک شوند.
• درصورت امکان، از بیت‌مپ‌های پشتیبانی‌شده با سخت‌افزار استفاده کنید.
  • در کتابخانه‌هایی مثل Glide، ویژگی Downsampler.ALLOW_HARDWARE_CONFIG را که به‌طور پیش‌فرض غیرفعال است فعال کنید. فعال کردن این گزینه از تکرار کردن بیت‌مپ‌ها جلوگیری می‌کند، زیرا درغیراین‌صورت بیت‌مپ‌ها هم در حافظه گرافیکی و هم در حافظه ناشناس وجود خواهند داشت.
• از رندر کردن‌های میانی و رندر کردن‌های مجدد اجتناب کنید
  • این موارد را می‌توان با Android GPU Inspector شناسایی کرد:
  • در بخش «بافت‌ها» به‌دنبال تصاویری بگردید که مراحل رسیدن به پرداز نهایی هستند و فقط عناصر تشکیل‌دهنده آن نیستند، این تصاویر معمولاً «پرداز میانی» نامیده می‌شوند.
  • برای برنامه‌های «کیت توسعه نرم‌افزار Android» اغلب می‌توانید بااستفاده از پرچم چیدمان forceHasOverlappedRendering:false این موارد را بردارید تا پردازه‌های میانه‌ای را برای این چیدمان غیرفعال کنید.
  • اجتناب از چیدمان‌های هم‌پوشانی‌شده در چیدمان‌های هم‌پوشانی‌شده را به‌عنوان منبعی عالی ببینید.
• درصورت امکان، از بار کردن تصاویر جای‌بان خودداری کنید، از @android:color/ یا @color برای بافت‌های جای‌بان استفاده کنید.
• از ترکیب چند تصویر در دستگاه وقتی ترکیب می‌تواند به‌صورت آفلاین انجام شود خودداری کنید. ترجیح می‌دهد تصاویر مستقل را بار کند تا اینکه از تصاویر بارگیری‌شده ترکیب تصویر انجام دهد
• برای مدیریت بهتر «بیت‌مپ‌ها»، راهنمای مدیریت بیت‌مپ‌ها را دنبال کنید.

حافظه مبادله + ناشناس

Anon+Swap از تخصیص‌های Native + Java + Stack در Android Studio memory profiler تشکیل شده است. از ActivityManager.isLowMemoryDevice() برای بررسی اینکه آیا دستگاه محدودیت حافظه دارد یا نه استفاده کنید و با پیروی از این دستورالعمل‌ها، با این وضعیت سازگار شوید.

• رسانه:
  • بسته به RAM دستگاه و وضوح بازپخش ویدیو، اندازه متغیری برای میان‌گیرهای رسانه مشخص کنید. این باید ۱ دقیقه از بازپخش ویدیو را دربر بگیرد:
    1. ‫۴۰ تا ۶۰ مگابایت برای ۱ گیگابایت / ۱۰۸۰ پیکسل
    2. ‫۶۰ تا ۸۰ مگابایت برای ۱٫۵ گیگابایت / ۱۰۸۰ پیکسل
    3. ‫۸۰ تا ۱۰۰ مگابایت برای ۱٫۵ گیگابایت / ۲۱۶۰ پیکسل
    4. ‫۱۰۰ تا ۱۲۰ مگابایت برای ۲ گیگابایت / ۲۱۶۰ پیکسل
  • تخصیص‌های حافظه رسانه را هنگام تغییر قسمت آزاد کنید تا از افزایش مقدار کل حافظه ناشناس جلوگیری شود.
  • وقتی برنامه‌تان متوقف می‌شود، منابع رسانه‌ای را بلافاصله آزاد و متوقف کنید: از بازخوان‌های چرخه حیات فعالیت برای مدیریت منابع صوتی و ویدیویی استفاده کنید. اگر برنامه شما برنامه صوتی نیست، وقتی onStop در فعالیت‌هایتان اتفاق می‌افتد، پخش را متوقف کنید، همه کاری را که انجام می‌دهید ذخیره کنید، و منابعتان را آزاد کنید. برای زمان‌بندی کاری که بعداً نیاز دارید، به بخش کارها و هشدارها مراجعه کنید.
    • می‌توانید از عناصر آگاه از چرخه حیات مثل LiveData و LifecycleOwner برای کمک به مدیریت فراخوان‌های چرخه حیات «فعالیت» استفاده کنید.
    • برای اینکه کارتان از «چرخه حیات» آگاه باشد، می‌توانید از روال‌های مشترک Kotlin و جریان‌های Kotlin نیز استفاده کنید.
  • هنگام جستجوی ویدیو به حافظه میان‌گیر توجه کنید: توسعه‌دهندگان اغلب هنگام جستجو، ۱۵ تا ۶۰ ثانیه محتوای آینده را اختصاص می‌دهند تا ویدیو برای کاربر آماده باشد، اما این کار سربار حافظه اضافی ایجاد می‌کند. به‌طورکلی، تا زمانی که کاربر موقعیت ویدیو جدید را انتخاب نکرده است، بیش‌از ۵ ثانیه از بافر آینده استفاده نکنید. اگر اکیداً نیاز دارید که هنگام جستجو زمان اضافی را ازقبل میان‌گیری کنید، مطمئن شوید که:
    • بافر جستجو را ازقبل اختصاص دهید و از آن مجدداً استفاده کنید.
    • اندازه بافر نباید بزرگ‌تر از ۱۵ تا ۲۵ مگابایت باشد (بسته به حافظه دستگاه).
• تخصیص‌ها:
  • از راهنمایی حافظه گرافیک استفاده کنید تا مطمئن شوید تصاویر را در «حافظه ناشناس» تکرار نمی‌کنید
    • تصاویر اغلب بیشترین استفاده را از حافظه دارند، بنابراین تکرار آن‌ها می‌تواند فشار زیادی به دستگاه وارد کند. این امر به‌ویژه در حین پیمایش سنگین نمای شبکه‌ای تصاویر صادق است.
  • با حذف ارجاع‌های تخصیص‌ها هنگام جابه‌جایی صفحه‌ها، تخصیص‌ها را آزاد کنید: مطمئن شوید که هیچ ارجاعی به بیت‌مپ‌ها و اشیای باقی‌مانده وجود ندارد.
• کتابخانه‌ها:
  • تخصیص‌های حافظه نمایه از کتابخانه‌ها هنگام افزودن کتابخانه‌های جدید، زیرا ممکن است کتابخانه‌های اضافی را نیز بار کنند که ممکن است تخصیص‌هایی را نیز انجام دهند و پیوندها را ایجاد کنند.
• شبکه‌سازی:
  • درطول راه‌اندازی برنامه، تماس‌های شبکه را مسدود نکنید. این‌ها زمان راه‌اندازی برنامه را کند می‌کنند و در زمان راه‌اندازی، که حافظه به‌ویژه به‌دلیل بار برنامه محدود است، سربار حافظه اضافی ایجاد می‌کنند. ابتدا صفحه بارگیری یا صفحه آغازین را نشان دهید و درخواست‌های شبکه را پس‌از قرار گرفتن واسط کاربر انجام دهید.

اتصالات

پیوندها سربار حافظه اضافی را معرفی می‌کنند زیرا برنامه‌های دیگر را به حافظه می‌آورند یا مصرف حافظه برنامه پیوندشده را افزایش می‌دهند (اگر ازقبل در حافظه باشد) تا تماس API را تسهیل کنند. درنتیجه، این کار حافظه دردسترس برای برنامه پیش‌زمینه را کاهش می‌دهد. هنگام اتصال سرویس، به زمان و مدت استفاده از اتصال توجه کنید. به‌محض اینکه دیگر به آن نیاز نداشتید، حتماً پیوند را آزاد کنید.

پیوندهای معمول و روال‌های مطلوب:

• Play integrity API: برای بررسی یکپارچگی دستگاه استفاده می‌شود یکپارچگی
  • بررسی تمامیت دستگاه پس‌از صفحه بارگیری و قبل‌از پخش رسانه
  • پیش‌از پخش محتوا، به PlayIntegrity ارجاع دهید StandardIntegrityManager.
• کتابخانه خدمات صورت‌حساب Play: برای مدیریت اشتراک‌ها و خریدها بااستفاده از Google Play استفاده می‌شود
  • کتابخانه را پس‌از صفحه بارگیری مقداردهی اولیه کنید و همه کارهای صدور صورت‌حساب را قبل‌از پخش رسانه انجام دهید.
  • پس‌از اتمام استفاده از کتابخانه و همیشه قبل‌از پخش ویدیو یا رسانه، از BillingClient.endConnection() استفاده کنید.
  • از BillingClient.isReady() و BillingClient.getConnectionState() برای بررسی اینکه آیا سرویس قطع شده است یا نه استفاده کنید تا درصورت نیاز به انجام مجدد کار صورت‌حساب، این کار انجام شود، و سپس پس‌از اتمام، BillingClient.endConnection() را دوباره انجام دهید.
• GMS FontsProvider
  • بهتر است در دستگاه‌های با حافظه دسترسی تصادفی کم، به‌جای استفاده از ارائه‌دهنده قلم، از قلم‌های مستقل استفاده کنید، زیرا بارگیری قلم‌ها پرهزینه است و FontsProvider برای انجام این کار خدمات را ملزم می‌کند.
• کتابخانه دستیار Google: گاهی اوقات برای جستجو و جستجوی درون‌برنامه‌ای استفاده می‌شود، درصورت امکان این کتابخانه را جایگزین کنید.
  • برای برنامه‌های leanback: از کتابخانه Gboard تبدیل نوشتار به گفتار یا androidx.leanback استفاده کنید.
    • برای پیاده‌سازی جستجو، رهنمودهای جستجو را دنبال کنید.
    • توجه: leanback منسوخ شده است و برنامه‌ها باید به TV Compose منتقل شوند.
  • برای برنامه‌های «نوشتن»:
    • از «تبدیل نوشتار به گفتار» Gboard برای پیاده‌سازی جستجوی گفتاری استفاده کنید.
  • تماشای بعدی را پیاده‌سازی کنید تا محتوای رسانه‌ای در برنامه‌تان قابل‌کشف شود.

سرویس‌های پیش‌زمینه‌ای

سرویس‌های پیش‌زمینه نوع خاصی از سرویس هستند که به اعلان مرتبط هستند. این اعلان در سینی اعلان در تلفن‌ها و رایانه‌های لوحی نمایش داده می‌شود، اما دستگاه‌های تلویزیون سینی اعلان به همان معنای این دستگاه‌ها ندارند. حتی اگر خدمات پیش‌زمینه مفید باشند زیرا می‌توانند درحالی‌که برنامه در پس‌زمینه است درحال اجرا باقی بمانند، برنامه‌های تلویزیون باید از این دستورالعمل‌ها پیروی کنند:

در Android TV و Google TV، «سرویس‌های پیش‌زمینه‌ای» فقط مجازند پس‌از خروج کاربر از برنامه به اجرا ادامه دهند:

• برای برنامه‌های صوتی: «سرویس‌های پیش‌زمینه‌ای» فقط مجازند پس‌از خروج کاربر از برنامه به اجرای خود ادامه دهند تا قطعه صوتی را پخش کنند. سرویس باید بلافاصله پس‌از پایان بازپخش صدا متوقف شود.
• برای هر برنامه دیگری: همه «سرویس‌های پیش‌زمینه‌ای» باید متوقف شوند. وقتی کاربر از برنامه‌تان خارج می‌شود، زیرا اعلانی وجود ندارد که به کاربر اطلاع دهد برنامه همچنان درحال اجرا و مصرف منابع است.
• برای کارهای پس‌زمینه‌ای مثل به‌روزرسانی توصیه‌ها یا ویدیو بعدی، از WorkManager استفاده کنید.

مشاغل و زنگ ساعت

WorkManager جدیدترین «میانای برنامه‌سازی کاربردی» Android برای زمان‌بندی کارهای تکرارشونده پس‌زمینه‌ای است. ‫WorkManager درصورت دردسترس بودن از JobScheduler جدید (کیت توسعه نرم‌افزار 23+) و درصورت دردسترس نبودن از AlarmManager قدیمی استفاده می‌کند. برای روال‌های مطلوب انجام کارهای زمان‌بندی‌شده در تلویزیون، این توصیه‌ها را دنبال کنید:

• در کیت توسعه نرم‌افزار ۲۳ و بالاتر، از استفاده از میاناهای برنامه‌سازی کاربردی AlarmManager، به‌ویژه AlarmManager.set()، AlarmManager.setExact() و روش‌های مشابه اجتناب کنید، زیرا این روش‌ها به سیستم اجازه نمی‌دهند زمان مناسب برای اجرای کارها را تعیین کند (برای مثال، زمانی که دستگاه در حالت آماده‌به‌کار است).
• در دستگاه‌های با حافظه دسترسی تصادفی کم، از اجرای کارها خودداری کنید، مگر اینکه کاملاً ضروری باشد. درصورت نیاز، از WorkManager WorkRequest فقط برای به‌روزرسانی توصیه‌ها پس‌از بازپخش استفاده کنید و سعی کنید این کار را درحالی‌که برنامه هنوز باز است انجام دهید.

• ‫WorkManager را Constraints تعریف کنید تا به سیستم اجازه دهید کارها را در زمان مناسب اجرا کند:

Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .setRequiresStorageNotLow(true)
    .setRequiresDeviceIdle(true)
    .build()
Memory.kt

Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .setRequiresStorageNotLow(true)
    .setRequiresDeviceIdle(true)
    .build()

• اگر باید کارها را به‌طور منظم اجرا کنید (برای مثال، برای به‌روزرسانی تماشای بعدی براساس فعالیت تماشای محتوای کاربر در برنامه شما در دستگاهی دیگر)، مصرف حافظه را با پایین نگه داشتن مصرف حافظه کار زیر ۳۰ مگابایت پایین نگه دارید.

ملاحظات کلی حافظه

دستورالعمل‌های زیر اطلاعات کلی درباره توسعه «برنامه Android» ارائه می‌دهد:

• تخصیص‌های شیء را به‌حداقل برسانید، استفاده مجدد از شیء را بهینه کنید، و هر شیء استفاده‌نشده را فوراً لغو تخصیص کنید.
  • به اشیا، به‌ویژه بیت‌مپ‌ها، ارجاع ندهید.
  • از System.gc() و فراخوانی‌های مستقیم آزاد کردن حافظه استفاده نکنید زیرا این فراخوانی‌ها در فرایند مدیریت حافظه سیستم تداخل ایجاد می‌کنند: برای مثال، در دستگاه‌هایی که از zRAM استفاده می‌کنند، فراخوانی اجباری gc() می‌تواند به‌دلیل فشرده‌سازی و باز کردن فشرده حافظه، استفاده از حافظه را به‌طور موقت افزایش دهد.
  • از LazyList مانند آنچه در مرورگر کاتالوگ در «نوشتن» یا RecyclerView در ابزارک «میانای کاربر Leanback» که اکنون منسوخ شده است استفاده کنید تا نماها را دوباره استفاده کنید و عناصر فهرست را دوباره ایجاد نکنید.
  • عناصری را که از ارائه‌دهندگان محتوای خارجی خوانده شده‌اند به‌صورت محلی در حافظه نهان ذخیره کنید و فاصله‌های زمانی به‌روزرسانی را به‌گونه‌ای تعریف کنید که از تخصیص حافظه خارجی اضافی جلوگیری شود.
• نشت‌های احتمالی حافظه را بررسی کنید.
  • مراقب موارد معمول نشت حافظه مانند ارجاعات درون رشته‌های ناشناس، تخصیص مجدد بافرهای ویدیویی که هرگز آزاد نمی‌شوند، و سایر موقعیت‌های مشابه باشید.
  • از heap dump برای اشکال‌زدایی نشت حافظه استفاده کنید.
• نمایه‌های پایه تولید کنید تا مقدار گردآوری هم‌زمان موردنیاز هنگام اجرای برنامه در شروع سرد به حداقل برسد.

آشنایی با پس‌گیری حافظه مستقیم

وقتی برنامه Android TV درخواست حافظه می‌کند و سیستم تحت فشار است، هسته Linux که زیربنای Android است ممکن است مجبور شود از بازپس‌گیری مستقیم حافظه استفاده کند.

این فرایند شامل توقف کامل هر رشته تخصیص‌دهنده برای انتظار صفحات حافظه آزادشده است. این اتفاق زمانی رخ می‌دهد که بازپس‌گیری پس‌زمینه نتواند به‌طور پیش‌کنشی استخر حافظه کافی را حفظ کند.

این امر می‌تواند منجر به وقفه‌های قابل‌توجه یا لرزش در تجربه کاربر شود، زیرا سیستم تا زمانی که حافظه کافی دردسترس قرار گیرد، تخصیص رشته‌ها را متوقف می‌کند. در این معنا، تخصیص رشته‌ها محدود به فراخوانی‌های کد برنامه مثل malloc() نیست؛ برای مثال، حافظه باید به صفحه در صفحه‌های کد اختصاص داده شود.

خلاصه ابزارها

• از ابزار نمایه‌گر حافظه Android Studio برای بررسی مصرف حافظه درطول استفاده استفاده کنید.
  • از heapdump برای بررسی تخصیص‌های شیء و بیت‌مپ خاص استفاده کنید.
  • از نمایه‌گر حافظه بومی برای بررسی تخصیص‌های غیر Java یا Kotlin استفاده کنید.
• برای بررسی تخصیص‌های گرافیک، از Android GPU Inspector استفاده کنید.