การกำหนดขนาดของ super พาร์ติชันอย่างถูกต้องเป็นสิ่งสำคัญสำหรับความสามารถในการอัปเดตอุปกรณ์ ขนาดส่งผลโดยตรงต่อจำนวนการอัปเดตที่อุปกรณ์สามารถรับได้และจำนวนผู้ใช้ที่สามารถรับการอัปเดตเหล่านั้นได้สำเร็จ
มีตัวแปรสำคัญบางประการที่ต้องพิจารณา อย่างแรกคือ ขนาดโรงงาน ซึ่งเป็นขนาดของพาร์ติชั่นไดนามิกทั้งหมดเมื่ออุปกรณ์ถูกแฟลชครั้งแรก อย่างที่สองคือ อัตราการเติบโต ซึ่งเป็นเปอร์เซ็นต์ที่ขนาดระบบปฏิบัติการเพิ่มขึ้นตลอดอายุการใช้งานที่อัปเดตได้ของอุปกรณ์
นอกจากนี้ อุปกรณ์ A/B เสมือนยังสามารถใช้พื้นที่บน /data ในระหว่างการอัปเดตได้ และจะต้องพิจารณาสิ่งนี้เมื่อปรับขนาด super หากจำเป็นต้องใช้พื้นที่มากเกินไป /data ผู้ใช้บางรายจะไม่สามารถ (หรือไม่เต็มใจ) ที่จะทำการอัปเดต อย่างไรก็ตาม หากทราบว่าผู้ใช้ส่วนใหญ่มีพื้นที่ว่างเป็นเปอร์เซ็นต์ อุปกรณ์ต่างๆ ก็สามารถลบพื้นที่นั้นออกจาก super ได้อย่างสบายๆ หรืออุปกรณ์สามารถรับประกันได้ว่า /data ไม่จำเป็น เพียงแค่ทำให้มี super ใหญ่เพียงพอ
ด้านล่างนี้คือบางรุ่นเพื่อช่วยแนะนำขนาดพาร์ติชัน super ตามตัวแปรเหล่านี้
อาศัย /data
A/B เสมือนสนับสนุนการลด super เพื่อให้สามารถเพิ่มขนาดของ /data ได้ จำเป็นต้องใช้พื้นที่บางส่วนในระหว่างการอัพเดต เพื่อให้เข้าใจถึงผลกระทบต่อความสามารถในการอัปเดต จำเป็นต้องทราบว่าอุปกรณ์กี่เปอร์เซ็นต์ที่มีแนวโน้มว่าจะมีพื้นที่ว่างขนาดนั้นเมื่อเวลาผ่านไป การหาตัวเลขนี้ขึ้นอยู่กับฮาร์ดแวร์ของอุปกรณ์และพฤติกรรมผู้ใช้ของอุปกรณ์นั้นเป็นอย่างมาก ในตัวอย่างด้านล่าง หมายเลขนี้เรียกว่า AllowedUserdataUse
โดยไม่ต้องบีบอัด
หากไม่มีการบีบอัด OTA แบบเต็มจะต้องมีสแน็ปช็อตที่มีขนาดใกล้เคียงกับระบบปฏิบัติการ ดังนั้นจะต้องนำมาพิจารณาเมื่อปรับขนาด super :
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) Super = Max(FinalDessertUpdate, FinalDessertSize * 2 - AllowedUserdataUse)
ตัวอย่างเช่น ลองพิจารณาอุปกรณ์ Virtual A/B ที่มีขนาดโรงงาน 4 GB คาดว่าจะเติบโต 50% และความรู้ที่ว่าผู้ใช้เกือบทั้งหมดมีพื้นที่ว่าง 1 GB (หรือเต็มใจที่จะเพิ่มพื้นที่ว่างสูงสุด 1 GB สำหรับการอัปเดต) . สำหรับอุปกรณ์นี้ super สามารถกำหนดขนาดได้ดังนี้:
FinalDessertSize = 4GB + (4GB * 0.5) = 6GB Super = Max(6GB, 6GB * 2 - 1GB) = Max(6GB, 11GB)
ดังนั้นอุปกรณ์นี้ควรมีพาร์ติชั่น super ขนาด 11 GB
ด้วยการบีบอัด
ด้วยการบีบอัด OTA แบบเต็มจะต้องมีสแน็ปช็อตประมาณ 70% ของขนาดของระบบปฏิบัติการ:
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) FinalOTASnapshotSize = FinalDessertSize * 0.7 Super = Max(FinalDessertUpdate, FinalDessertSize + FinalOTASnapshotSize - AllowedUserdataUse)
ตัวอย่างเช่น ลองพิจารณาอุปกรณ์ที่กำหนดค่าด้วยการบีบอัด A/B เสมือน โดยมีขนาดโรงงาน 4GB คาดว่าจะเติบโต 50% และความรู้ที่ว่าผู้ใช้เกือบทั้งหมดมีพื้นที่ว่าง 1 GB (หรือเต็มใจที่จะเพิ่มพื้นที่ว่างสูงสุด 1 GB สำหรับ การปรับปรุง). สำหรับอุปกรณ์นี้ 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 GB
โดยไม่ต้องพึ่งพา /data
หากคุณต้องการมี OTA ที่ไม่ต้องใช้พื้นที่สแนปช็อตบน /data การปรับขนาด super นั้นตรงไปตรงมา
โดยไม่ต้องบีบอัด
สำหรับอุปกรณ์ A/B เสมือนที่ไม่มีการบีบอัด หรืออุปกรณ์ A/B ปกติ:
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) Super = FinalDessertSize * 2
ตัวอย่างเช่น พิจารณาอุปกรณ์ A/B เสมือนที่มีขนาดโรงงาน 4 GB และคาดว่าจะเติบโต 50% เพื่อให้แน่ใจว่าอุปกรณ์นี้ไม่เคยใช้ /data สำหรับสแนปช็อต OTA การคำนวณจะมีลักษณะดังนี้:
FinalDessertSize = 4GB + (4GB * 0.5) = 6GB Super = FinalDessertSize * 2 = 12GB
ดังนั้นอุปกรณ์นี้ควรมีพาร์ติชั่น super 12 GB
ด้วยการบีบอัด
สำหรับอุปกรณ์ A/B เสมือนที่มีการบีบอัด:
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) FinalOTASnapshotSize = FinalDessertSize * 0.7 Super = FinalDessertSize + FinalOTASnapshotSize
ตัวอย่างเช่น พิจารณาอุปกรณ์บีบอัด A/B เสมือนที่มีขนาดโรงงาน 4 GB และคาดว่าจะเติบโต 50% เพื่อให้แน่ใจว่าอุปกรณ์นี้ไม่เคยใช้ /data สำหรับสแนปช็อต OTA การคำนวณจะมีลักษณะดังนี้:
FinalDessertSize = 4GB + (4GB * 0.5) = 6GB FinalOTASnapshotSize = 6GB * 0.7 = 4.2GB Super = 6GB + 4.2GB = 10.2GB
ดังนั้นอุปกรณ์นี้ควรมีพาร์ติชั่น super 10.2 GB
คำเตือน
อาจสังเกตได้ว่าหากขนาดจากโรงงานคือ 4 GB และการอัปเดตครั้งสุดท้ายคือ 5 GB ดังนั้น super จะต้องมีขนาด 9 GB แทนที่จะเป็น 10 GB อย่างไรก็ตาม หากการอัปเดตครั้งแรกและการอัปเดตครั้งสุดท้ายมีทั้ง 5 GB พื้นที่ใน super อาจไม่เพียงพอสำหรับการอัปเดตครั้งสุดท้าย สูตรข้างต้นถือว่าการเติบโตของพาร์ติชันอาจเกิดขึ้นได้ตลอดเวลา พื้นที่ที่จำเป็นในการใช้การอัปเดตครั้งสุดท้ายอาจเหมือนกับพื้นที่ที่จำเป็นสำหรับการใช้การอัปเดตครั้งแรก
โปรดทราบว่าอัตราส่วนกำลังอัดเป็นเพียงค่าประมาณเท่านั้น อิมเมจ OS อาจบีบอัดดีขึ้นหรือแย่ลงขึ้นอยู่กับเนื้อหา หากใช้ระบบไฟล์บีบอัด เช่น 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 อิมเมจที่เก่าที่สุดและล่าสุดเพื่อคำนวณการเติบโต