كيفية قياس الحجم سوبر

يعد تغيير حجم القسم super بشكل صحيح أمرًا مهمًا لقابلية تحديث الجهاز. ويؤثر الحجم بشكل مباشر على عدد التحديثات التي يمكن للجهاز تلقيها وعدد المستخدمين الذين يمكنهم إجراء هذه التحديثات بنجاح.

هناك بعض المتغيرات الهامة التي يجب مراعاتها. الأول هو حجم المصنع ، وهو حجم جميع الأقسام الديناميكية عند وميض الجهاز لأول مرة. والثاني هو معدل النمو ، وهي النسبة المئوية لحجم نظام التشغيل الذي يزيد على مدار عمر الجهاز القابل للتحديث بالكامل.

بالإضافة إلى ذلك، يمكن لأجهزة A/B الافتراضية استخدام المساحة على /data أثناء التحديث، ويجب أخذ ذلك في الاعتبار عند تحديد super . إذا كانت هناك حاجة إلى مساحة كبيرة جدًا على /data ، فإن بعض المستخدمين غير قادرين (أو غير راغبين) في إجراء التحديث. ومع ذلك، إذا كان من المعروف أن معظم المستخدمين لديهم نسبة معينة من المساحة الفارغة، فيمكن للأجهزة أن تطرح هذه المساحة بشكل مريح من super . أو يمكن للأجهزة أن تضمن عدم الحاجة /data أبدًا، وذلك ببساطة عن طريق جعلها كبيرة super بما يكفي.

فيما يلي بعض النماذج للمساعدة في توجيه حجم القسم super بناءً على هذه المتغيرات.

الاعتماد على / البيانات

يشجع Virtual 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 جيجابايت.

دون الاعتماد على /data

إذا كنت تريد الحصول على وكالات السفر عبر الإنترنت التي لا تتطلب أبدًا مساحة لقطة على /data ، فإن تحديد super أمر بسيط.

بدون ضغط

بالنسبة لجهاز A/B الظاهري بدون ضغط، أو جهاز A/B عادي:

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

على سبيل المثال، لنأخذ بعين الاعتبار جهاز A/B افتراضي بحجم مصنع يبلغ 4 جيجابايت ونمو متوقع بنسبة 50%. للتأكد من أن هذا الجهاز لا يستخدم أبدًا /data للقطات عبر الهواء، ستبدو حساباته كما يلي:

  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 للقطات عبر الهواء، ستبدو حساباته كما يلي:

  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 الأقدم والأحدث لحساب النمو.