AOSP, GMS และ HMS Core แยกความแตกต่างของสถาปัตยกรรมบริการมือถือ

เมื่อพูดถึงระบบปฏิบัติการบนสมาร์ตโฟน หลายคนมักเรียกทุกอย่างรวมกันว่า Android แต่ในเชิงเทคนิคแล้ว โครงสร้างบริการบนอุปกรณ์มือถือแบ่งออกเป็นสามชั้นที่แยกจากกันชัดเจน ได้แก่ AOSP ซึ่งเป็นระบบปฏิบัติการโอเพนซอร์ส, GMS ซึ่งเป็นชุดบริการกรรมสิทธิ์ของ Google และ HMS Core ซึ่งเป็นชุดบริการที่ Huawei พัฒนาขึ้นเพื่อทำหน้าที่ทดแทน การแยกสามชั้นนี้ออกจากกันเป็นเงื่อนไขสำคัญของการทำความเข้าใจระบบนิเวศแอปยุคปัจจุบัน
AOSP รากฐานที่ทุกฝ่ายใช้ร่วมกัน
AOSP (Android Open Source Project) คือซอร์สโค้ดหลักของ Android ที่ Google เผยแพร่ภายใต้สัญญาอนุญาตแบบเปิด ผู้ผลิตทุกรายสามารถนำไปดัดแปลงใช้งานได้โดยไม่ต้องขออนุญาต ส่วนประกอบของ AOSP ครอบคลุมเคอร์เนล Linux, ระบบรันไทม์, เฟรมเวิร์กการจัดการแอป และแอปพื้นฐานบางตัว เช่น โปรแกรมโทรศัพท์และข้อความ แต่ AOSP ไม่มี Play Store, ไม่มีบริการแผนที่, ไม่มีระบบ Push Notification กลาง และไม่มีบริการบัญชี Google ใด ๆ ทั้งสิ้น
ด้วยเหตุนี้ อุปกรณ์ที่รัน AOSP ล้วน ๆ จึงใช้งานพื้นฐานได้ปกติ แต่แอปที่พึ่งพาบริการเสริมจะทำงานไม่ได้ทันที นี่คือเหตุผลที่ผู้ผลิตส่วนใหญ่เลือกติดตั้ง GMS เพิ่ม เพราะเป็นชุดบริการที่นักพัฒนาแอปทั่วโลกใช้เป็นมาตรฐาน อย่างไรก็ตาม GMS ไม่ใช่ตัวเลือกเดียว เมื่อผู้ผลิตไม่สามารถหรือไม่ต้องการใช้ GMS ก็ต้องสร้างชุดบริการของตนเองขึ้นมาทดแทน
GMS และ HMS Core ทำหน้าที่เดียวกันต่างที่เจ้าของ
GMS ให้บริการระดับเฟรมเวิร์กที่แอปเรียกใช้ผ่าน API มาตรฐาน เช่น Google Sign-In, Fused Location Provider, Firebase Cloud Messaging และ Google Play Billing ส่วน HMS Core ออกแบบมาให้มีโมดูลที่เทียบเคียงกันเกือบหนึ่งต่อหนึ่ง ได้แก่ HUAWEI ID สำหรับบัญชี, Push Kit สำหรับการแจ้งเตือน, Map Kit สำหรับแผนที่, Location Kit สำหรับตำแหน่ง และ IAP Kit สำหรับการซื้อในแอป แอปที่ย้ายมารองรับ HMS Core จึงต้องเปลี่ยนมาเรียก API ชุดใหม่ ซึ่งเป็นงานพัฒนาที่นักพัฒนาต้องลงทุนเพิ่ม
ในทางปฏิบัติ เมื่อผู้ใช้ค้นหาข้อมูลเรื่อง หัวเว่ย gms สิ่งที่พบมักเป็นคำอธิบายว่าอุปกรณ์รุ่นใหม่ใช้ HMS Core แทน GMS ทั้งหมด แต่ในเชิงสถาปัตยกรรม ระบบปฏิบัติการพื้นฐานยังคงสร้างจาก AOSP เหมือนเดิม สิ่งที่เปลี่ยนคือเลเยอร์บริการเท่านั้น การเข้าใจตรงนี้ช่วยอธิบายได้ว่าทำไมแอปที่พัฒนาให้รองรับ HMS จึงทำงานบนเครื่องเหล่านั้นได้ราบรื่น ขณะที่แอปที่ผูกกับ GMS โดยเฉพาะยังคงมีปัญหา
ผลกระทบต่อนักพัฒนาและผู้ใช้
สำหรับนักพัฒนา การมีสองเฟรมเวิร์กบริการหมายความว่าต้องตัดสินใจว่าจะพัฒนาแอปแบบใด ทางเลือกหลักคือพัฒนาแยกสองเวอร์ชัน ใช้ไลบรารีที่รองรับทั้งสองระบบ หรือหลีกเลี่ยงการพึ่งพาบริการเฉพาะฝั่ง แอปขนาดใหญ่จำนวนมากเลือกทำสองเวอร์ชันขนานกัน ส่งผลให้ผู้ใช้อุปกรณ์ HMS ได้รับประสบการณ์ใกล้เคียงเดิมมากขึ้นเรื่อย ๆ ขณะที่แอปขนาดเล็กบางตัวยังคงมีเฉพาะเวอร์ชัน GMS
สำหรับผู้ใช้ ข้อแตกต่างที่สัมผัสได้ชัดที่สุดคือช่องทางดาวน์โหลดแอป ระบบแจ้งเตือน และบริการบัญชี อุปกรณ์ GMS ใช้ Play Store เป็นศูนย์กลาง ขณะที่อุปกรณ์ HMS ใช้ AppGallery ร่วมกับเครื่องมือค้นหาแอปเสริม การเข้าใจโครงสร้างสามชั้นนี้ทำให้ประเมินข้อจำกัดและทางเลือกได้อย่างมีเหตุผล แทนที่จะมองว่าเป็นปัญหาเชิงซอฟต์แวร์ที่แก้ได้ด้วยการติดตั้งไฟล์เพิ่ม