استفاده از حافظه را بهینه کنید

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

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

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

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

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

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

درک دستگاه‌های تلویزیون

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

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

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

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

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

دستگاه‌های تلویزیونی با رم کم

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

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

• دستگاه‌های ۱ گیگابایتی : ۱ گیگابایت رم، وضوح رابط کاربری ۷۲۰p/HD (1280x720)، وضوح تصویر ۱۰۸۰p/FullHD (1920x1080)
• دستگاه‌های ۱.۵ گیگابایتی : ۱.۵ گیگابایت رم، وضوح رابط کاربری ۱۰۸۰p/FullHD (1920x1080)، وضوح تصویر ۲۱۶۰p/UltraHD/4K (3840x2160)
• سایر موقعیت‌هایی که در آن‌ها تولیدکننده اصلی (OEM) به دلیل محدودیت‌های حافظه اضافی، پرچم ActivityManager.isLowRAMDevice() را تعریف کرده است.

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

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

• ۱.۵ گیگابایت رم یا بیشتر، رابط کاربری ۷۲۰p یا ۱۰۸۰p و وضوح تصویر ۱۰۸۰p
• رم بیشتر یا مساوی ۲ گیگابایت، رابط کاربری ۱۰۸۰p و وضوح تصویر ۱۰۸۰p یا ۲۱۶۰p

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

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

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

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

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

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

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

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

اکیداً توصیه می‌شود از موارد زیر تجاوز نکنید:

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

حافظه فایل

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

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

با این حال، هنگام برخورد با حافظه فایل به طور کلی:

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

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

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

حافظه گرافیکی

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

• تصاویر را با وضوح بالاتر از وضوح رابط کاربری دستگاه بارگذاری نکنید. برای مثال، تصاویر 1080p باید در دستگاهی با رابط کاربری 720p به 720p کاهش حجم پیدا کنند.
• در صورت امکان از بیت‌مپ‌های دارای پشتیبانی سخت‌افزاری استفاده کنید .
  • در کتابخانه‌هایی مانند Glide، ویژگی Downsampler.ALLOW_HARDWARE_CONFIG را که به طور پیش‌فرض غیرفعال است، فعال کنید. فعال کردن این ویژگی از کپی شدن بیت‌مپ‌ها که در غیر این صورت هم در حافظه گرافیکی و هم در حافظه ناشناس وجود خواهند داشت، جلوگیری می‌کند.
• از رندرهای میانی و رندرهای مجدد خودداری کنید
  • این موارد را می‌توان با Android GPU Inspector شناسایی کرد:
  • در بخش «بافت‌ها» به دنبال تصاویری باشید که گام‌هایی به سوی رندر نهایی هستند، نه اینکه فقط عناصر تشکیل‌دهنده‌ی آنها باشند، این معمولاً «رندر میانی» نامیده می‌شود.
  • برای برنامه‌های SDK اندروید، اغلب می‌توانید این موارد را با استفاده از پرچم طرح‌بندی forceHasOverlappedRendering:false برای غیرفعال کردن رندرهای میانی برای این طرح‌بندی، حذف کنید.
  • برای اطلاع از رندرهای همپوشانی، به مقاله Avoid Overlapping Renders مراجعه کنید.
• در صورت امکان از بارگذاری تصاویر جایگزین خودداری کنید ، برای بافت‌های جایگزین @android:color/ ‎ یا @color ‎ استفاده کنید.
• از ترکیب چندین تصویر در دستگاه خودداری کنید ، زمانی که ترکیب‌بندی می‌تواند به صورت آفلاین انجام شود. ترجیح می‌دهید تصاویر مستقل را بارگذاری کنید تا اینکه ترکیب‌بندی تصویر را از تصاویر دانلود شده انجام دهید.
• برای کار بهتر با بیت‌مپ‌ها، راهنمای مدیریت بیت‌مپ‌ها را دنبال کنید.

حافظه آنون+سواپ

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

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

صحافی‌ها

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

اتصالات معمول و بهترین شیوه‌ها:

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

خدمات پیش‌زمینه

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

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

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

کارها و هشدارها

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

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

• Constraints WorkManager را تعریف کنید تا سیستم بتواند وظایف شما را در زمان مناسب اجرا کند:

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

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

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

ملاحظات کلی در مورد حافظه

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

• تخصیص اشیاء را به حداقل برسانید، استفاده مجدد از اشیاء را بهینه کنید و اشیاء بلااستفاده را فوراً از تخصیص خارج کنید.
  • ارجاع به اشیاء، به خصوص بیت‌مپ‌ها، را نگه ندارید .
  • از استفاده از System.gc() و فراخوانی‌های حافظه با آزادسازی مستقیم خودداری کنید، زیرا در فرآیند مدیریت حافظه سیستم اختلال ایجاد می‌کنند: به عنوان مثال، در دستگاه‌هایی که از zRAM استفاده می‌کنند، فراخوانی اجباری gc() می‌تواند به دلیل فشرده‌سازی و رفع فشرده‌سازی حافظه، به طور موقت استفاده از حافظه را افزایش دهد.
  • از LazyList همانطور که در یک مرورگر کاتالوگ در Compose یا RecyclerView در جعبه ابزار Leanback UI که اکنون منسوخ شده است نشان داده شده است، برای استفاده مجدد از نماها و عدم ایجاد مجدد عناصر لیست استفاده کنید.
  • عناصری که از ارائه‌دهندگان محتوای خارجی خوانده می‌شوند و بعید است تغییر کنند را به صورت محلی ذخیره کنید و فواصل به‌روزرسانی را طوری تعریف کنید که از تخصیص حافظه خارجی اضافی جلوگیری شود.
• نشت حافظه احتمالی را بررسی کنید.
  • مراقب موارد معمول نشت حافظه مانند ارجاعات درون رشته‌های ناشناس، تخصیص مجدد بافرهای ویدیویی که هرگز آزاد نمی‌شوند و سایر موقعیت‌های مشابه باشید.
  • برای اشکال‌زدایی نشت حافظه از heap dump استفاده کنید.
• پروفایل‌های پایه ایجاد کنید تا میزان کامپایل درجا (just-in-time compilation) مورد نیاز هنگام اجرای برنامه در حالت شروع سرد (cold start) به حداقل برسد.

درک بازیابی مستقیم حافظه

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

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

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

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

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