نحوه اندازه گیری Super

اندازه صحیح پارتیشن super برای به روز رسانی دستگاه مهم است. اندازه به طور مستقیم بر تعداد به‌روزرسانی‌هایی که یک دستگاه می‌تواند انجام دهد و تعداد کاربرانی که می‌توانند آن به‌روزرسانی‌ها را با موفقیت انجام دهند، تأثیر می‌گذارد.

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

به‌علاوه، دستگاه‌های مجازی A/B می‌توانند از فضای روی /data در طول به‌روزرسانی استفاده کنند، و این باید هنگام اندازه‌گیری super در نظر گرفته شود. اگر فضای زیادی در /data نیاز باشد، برخی از کاربران قادر به دریافت به‌روزرسانی نیستند (یا نمی‌خواهند). با این حال، اگر مشخص باشد که اکثر کاربران درصدی از فضای خالی دارند، دستگاه‌ها می‌توانند به راحتی آن فضا را از super کم کنند. یا، دستگاه‌ها می‌توانند تضمین کنند که /data هرگز مورد نیاز نیست، به سادگی با بزرگ کردن super کافی.

در زیر چند مدل برای کمک به هدایت اندازه پارتیشن super بر اساس این متغیرها آورده شده است.

با تکیه بر داده /

A/B مجازی کوچک شدن super را تشویق می کند تا اندازه /data را افزایش دهد. مقداری از آن فضا در طول به روز رسانی مورد نیاز است. برای درک تأثیر بر قابلیت به‌روزرسانی، ضروری است بدانیم چند درصد از دستگاه‌ها احتمالاً در طول زمان آن مقدار فضای خالی خواهند داشت. تعیین این عدد به شدت به سخت افزار دستگاه و رفتار کاربران آن دستگاه بستگی دارد. در مثال‌های زیر، به این عدد AllowedUserdataUse گفته می‌شود.

بدون فشرده سازی

بدون فشرده‌سازی، یک OTA کامل به یک عکس فوری تقریباً به اندازه سیستم‌عامل نیاز دارد، بنابراین باید هنگام اندازه‌گیری super در نظر گرفته شود:

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  Super = Max(FinalDessertUpdate, FinalDessertSize * 2 - AllowedUserdataUse)

به عنوان مثال، یک دستگاه A/B مجازی با اندازه کارخانه 4 گیگابایت، رشد مورد انتظار 50 درصد و آگاهی از اینکه تقریباً همه کاربران 1 گیگابایت فضای خالی دارند (یا مایلند تا 1 گیگابایت فضا برای به روز رسانی آزاد کنند) را در نظر بگیرید. . برای این دستگاه، super را می توان به این اندازه اندازه داد:

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  Super = Max(6GB, 6GB * 2 - 1GB) = Max(6GB, 11GB)

بنابراین، این دستگاه باید دارای یک super 11 گیگابایتی باشد.

با فشرده سازی

با فشرده سازی، یک OTA کامل به یک عکس فوری تقریباً 70٪ از اندازه سیستم عامل نیاز دارد:

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  FinalOTASnapshotSize = FinalDessertSize * 0.7
  Super = Max(FinalDessertUpdate, FinalDessertSize + FinalOTASnapshotSize - AllowedUserdataUse)

به عنوان مثال، دستگاهی را در نظر بگیرید که با فشرده‌سازی A/B مجازی، با اندازه کارخانه 4 گیگابایت، رشد مورد انتظار 50 درصد و آگاهی از این که تقریباً همه کاربران 1 گیگابایت فضای آزاد دارند (یا مایل به آزاد کردن حداکثر 1 گیگابایت فضا هستند را در نظر بگیرید. یک به روز رسانی). برای این دستگاه، super را می توان به این اندازه اندازه داد:

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  FinalOTASnapshotSize = 6GB * 0.7 = 4.2GB
  Super = Max(6GB, 6GB + 4.2GB - 1GB) = Max(6GB, 9.2GB) = 9.2GB

بنابراین، این دستگاه باید دارای یک super 9.2 گیگابایتی باشد.

بدون اتکا به /داده

اگر می‌خواهید OTAهایی داشته باشید که هرگز به فضای عکس فوری در /data نیاز ندارند، اندازه‌گیری super ساده است.

بدون فشرده سازی

برای یک دستگاه A/B مجازی بدون فشرده سازی، یا یک دستگاه A/B معمولی:

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  Super = FinalDessertSize * 2

به عنوان مثال، یک دستگاه A/B مجازی با اندازه کارخانه 4 گیگابایت و رشد مورد انتظار 50 درصد را در نظر بگیرید. برای اطمینان از اینکه این دستگاه هرگز /data برای عکس‌های فوری OTA استفاده نمی‌کند، محاسبه آن به این صورت است:

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  Super = FinalDessertSize * 2 = 12GB

بنابراین، این دستگاه باید دارای یک super 12 گیگابایتی باشد.

با فشرده سازی

برای یک دستگاه مجازی A/B با فشرده سازی:

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  FinalOTASnapshotSize = FinalDessertSize * 0.7
  Super = FinalDessertSize + FinalOTASnapshotSize

به عنوان مثال، یک دستگاه فشرده سازی A/B مجازی با اندازه کارخانه 4 گیگابایت و رشد مورد انتظار 50 درصد را در نظر بگیرید. برای اطمینان از اینکه این دستگاه هرگز /data برای عکس‌های فوری OTA استفاده نمی‌کند، محاسبه آن به این صورت است:

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  FinalOTASnapshotSize = 6GB * 0.7 = 4.2GB
  Super = 6GB + 4.2GB = 10.2GB

بنابراین، این دستگاه باید دارای یک super 10.2 گیگابایتی باشد.

هشدارها

ممکن است وسوسه انگیز باشد که مشاهده کنید که اگر اندازه کارخانه 4 گیگابایت است، و به روز رسانی نهایی 5 گیگابایت است، پس super باید 9 گیگابایت باشد نه 10 گیگابایت. با این حال، اگر اولین به‌روزرسانی و به‌روزرسانی نهایی هر دو 5 گیگابایت باشند، ممکن است فضای super برای به‌روزرسانی نهایی ناکافی باشد. فرمول های بالا فرض می کنند که رشد پارتیشن می تواند در هر زمانی اتفاق بیفتد. فضای مورد نیاز برای اعمال به‌روزرسانی نهایی ممکن است همان فضایی باشد که برای اعمال به‌روزرسانی اول لازم است.

توجه داشته باشید که نسبت تراکم یک تخمین است. یک تصویر سیستم عامل بسته به محتوای آن ممکن است بهتر یا بدتر فشرده شود. اگر از یک سیستم فایل فشرده مانند EROFS استفاده می کنید، فشرده سازی اضافی از Virtual A/B بازده کاهشی دارد. در این مورد بهتر است از یکی از فرمول های غیر فشرده به عنوان راهنما استفاده کنید.

اندازه گیری

برای یافتن مقدار FinalDessertSize در مثال های بالا، اندازه تمام پارتیشن های پویا را با هم اضافه کنید. تصاویر پارتیشن پویا AOSP عبارتند از:

• system.img
• vendor.img
• product.img
• system_ext.img
• vendor_dlkm.img
• system_dlkm.img

دقت کنید که اندازه را بر اساس تصاویر پراکنده نشده محاسبه کنید. هنگام ساخت Android 12 یا پایین‌تر، تصاویر به‌طور پیش‌فرض پراکنده می‌شوند و می‌توان با simg2img آن‌ها را حذف کرد.

همچنین می توان اندازه پارتیشن را از بسته OTA محاسبه کرد. با انجام این کار، اندازه عکس فوری A/B مجازی برای هر پارتیشن نیز تخمین زده می‌شود:

  python3 system/update_engine/scripts/payload_info.py path/to/ota-package.zip

یا می توانید از ابزار تحلیل OTA استفاده کنید. این ابزار هیچ فایلی را آپلود نمی کند و بسته های OTA را به صورت محلی تجزیه و تحلیل می کند.

برای یافتن مقدار ExpectedGrowth ، از دستگاهی که قبلاً منتشر شده است استفاده کنید. از اولین و جدیدترین تصویر super برای محاسبه رشد استفاده کنید.