ปรับขนาดพาร์ติชันระดับซูเปอร์

การกำหนดขนาดพาร์ติชัน super อย่างถูกต้องเป็นสิ่งสำคัญต่อความสามารถในการอัปเดตอุปกรณ์ ขนาด ส่งผลโดยตรงต่อจำนวนการอัปเดตที่อุปกรณ์รับได้และจำนวนผู้ใช้ที่อัปเดต ได้สำเร็จ

โดยมีตัวแปรสำคัญ 2-3 อย่างที่ควรพิจารณา ส่วนแรกคือขนาดจากโรงงาน ซึ่งเป็นขนาดของพาร์ติชันแบบไดนามิกทั้งหมดเมื่อแฟลชอุปกรณ์เป็นครั้งแรก อย่างที่ 2 คืออัตราการเติบโต ซึ่งเป็นเปอร์เซ็นต์ที่ขนาดของระบบปฏิบัติการเพิ่มขึ้นตลอด อายุการใช้งานที่อัปเดตได้ของอุปกรณ์

นอกจากนี้ อุปกรณ์เสมือน 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)

ตัวอย่างเช่น ลองพิจารณาอุปกรณ์ 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)

ตัวอย่างเช่น พิจารณาอุปกรณ์ที่กำหนดค่าด้วยการบีบอัด Virtual A/B โดยมีขนาดจากโรงงาน 4 GB, การเติบโตที่คาดไว้ 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

ดังนั้น อุปกรณ์นี้ควรมีพาร์ติชัน 9.2 GB super

โดยไม่ต้องอาศัย /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 อาจไม่เพียงพอสำหรับการอัปเดตครั้งสุดท้าย สูตรด้านบนถือว่าการเติบโตของพาร์ติชันอาจเกิดขึ้นได้ทุกเมื่อ พื้นที่ที่ต้องใช้ในการอัปเดตครั้งสุดท้ายอาจเท่ากับพื้นที่ที่ต้องใช้ในการอัปเดตครั้งแรก

โปรดทราบว่าอัตราส่วนการบีบอัดเป็นค่าประมาณ รูปภาพระบบปฏิบัติการอาจบีบอัดได้ดีขึ้นหรือแย่ลง ขึ้นอยู่กับเนื้อหา หากใช้ระบบไฟล์ที่บีบอัด เช่น EROFS การบีบอัดเพิ่มเติมจาก Virtual A/B จะให้ผลตอบแทนลดลง ในกรณีนี้ คุณควรใช้สูตรที่ไม่ได้บีบอัดเป็นแนวทาง

คำนวณขนาด

หากต้องการหาค่าของ FactorySize ในตัวอย่างก่อนหน้า ให้บวกขนาดของพาร์ติชันแบบไดนามิกทั้งหมดเข้าด้วยกัน รูปภาพพาร์ติชันแบบไดนามิกของ 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ที่ เก่าที่สุดและล่าสุดเพื่อคำนวณการเติบโต