โลกของการพัฒนาแอปแอนดรอยด์นั้น สิ่งที่นักพัฒนาไม่สามารถมองข้ามไปได้เลย นั่นก็คือ Android Version ทั้งนี้ก็เพราะว่า Android เป็น Platform ที่มีการอัปเดตอยู่ตลอดในทุกๆปี ในขณะที่เวอร์ชันล่าสุด ณ ตอนที่เขียนบทความนี้เป็น Android 10 (ส่วน Android 11 ก็ใกล้จะ Stable Release ในอีกไม่นาน) แต่ยังมีผู้ใช้ Android 5 - 7 มากถึง 33% จากทั้งหมด
ทั้งนี้ก็เพราะว่าระบบแอนดรอยด์นั้นไม่ได้เข้มงวดเรื่องการอัปเดตเวอร์ชันมากนัก และส่วนใหญ่ก็ขึ้นอยู่กับผู้ผลิตและจำหน่ายอุปกรณ์แอนดรอยด์ของแต่ละแบรนด์เป็นหลัก ซึ่งส่วนใหญ่ก็จะคอยหมั่นอัปเดตให้แค่ 1-3 เวอร์ชันเท่านั้น จึงเป็นที่มาว่าทำไมในปัจจุบันถึงยังมีผู้ใช้แอนดรอยด์ที่เป็นเวอร์ชันเก่าๆอยู่
ดังนั้นจึงเป็นเรื่องพื้นฐานอย่างหนึ่งสำหรับนักพัฒนาที่จะต้องทำแอปให้รองรับกับแอนดรอยด์หลายๆเวอร์ชัน เพื่อให้แอปสามารถรองรับกับผู้ใช้ได้มากที่สุดเท่าที่ทำได้
ซึ่งส่วนใหญ่ก็จะคุ้นเคยกับคำว่า Minimum SDK Version หรือ minSdkVersion ใน build.gradle กันอยู่แล้วเนอะ แต่ในบทความนี้จะมาพูดถึงอีกตัวหนึ่งที่สำคัญไม่แพ้กัน และมีชื่อเรียกว่า Target API Level หรือ Target SDK Version นั่นเอง
// build.gradle
android {
...
defaultConfig {
minSdkVersion 21
targetSdkVersion 29
...
}
}Target API Level คืออะไร?
เมื่อ minSdkVersion เป็นการกำหนดเวอร์ชันขั้นต่ำที่แอปจะรองรับ ดังนั้น targetSdkVersion ก็มีไว้กำหนดเวอร์ชันสูงสุดที่แอปมั่นใจว่าจะทำงานได้อย่างไม่มีปัญหา
Target API Level ไม่ใช่การกำหนดเวอร์ชันสูงสุดที่แอปจะรองรับ เพราะยังไงแอปก็สามารถเปิดบนเวอร์ชันใหม่กว่าได้เสมอ
ที่ต้องมีการกำหนด Target API Level ไว้ในโปรเจคก็เพราะว่า ทุกครั้งที่แอนดรอยด์ประกาศเวอร์ชันใหม่ในแต่ละปี ไม่ได้มีแค่เพียงตัวเลขเวอร์ชันที่เปลี่ยนไปเท่านั้น แต่รวมไปถึงการเปลี่ยนแปลงในเรื่อง Feature, Platform และ API ด้วย จึงทำให้นักพัฒนาแอปก็จะต้องคอยอัปเดตโค้ดในโปรเจคของตัวเองให้รองรับกับเวอร์ชันใหม่ๆอยู่เสมอด้วยเช่นกัน
และการกำหนด Target API Level ก็เปรียบเสมือนการบอกว่าโค้ดของแอปนั้นๆรองรับจนถึงแอนดรอยด์เวอร์ชันไหนนั่นเอง ถึงแม้ว่าจะเปิดใช้งานบนแอนดรอยด์ท่ีเวอร์ชันใหม่กว่าได้ แต่ก็อาจจะทำงานได้ไม่สมบูรณ์ตามที่เวอร์ชันนั้นๆกำหนดไว้
Target API Level ส่งผลอย่างไรต่อการอัปเดตเวอร์ชันบนแอนดรอยด์?
ในปัจจุบันนี้ทีมพัฒนาแอนดรอยด์ได้เปลี่ยนรูปแบบในการ Release โดยแบ่งเป็น Developer Preview, Beta Release และ Final Release เพื่อให้นักพัฒนาแอปและผู้ใช้ทั่วไปสามารถทดสอบแอปที่มีอยู่ได้ เพื่อให้มั่นใจว่าในวันที่ Final Release ปล่อยออกมา แอปจะสามารถรองรับและใช้งานได้อย่างสมบูรณ์
ซึ่งระยะเวลาในแต่ละเวอร์ชันก็จะกินเวลานานถึง 8 - 10 เดือนก็จริง แต่ทว่าก็ยังไม่เพียงพอที่จะรอให้นักพัฒนาแอปทั่วโลกทำการ Migrate ให้แอปรองรับกับแอนดรอยด์เวอร์ชันใหม่
นั่นก็เพราะว่าในช่วงเวลาที่เหมาะสำหรับการเริ่ม Migrate ได้นั้นก็จะอยู่ช่วง Beta Release เป็นต้นไป เพราะเป็นช่วงที่ API ทั้งหมดจะไม่มีการเปลี่ยนแปลงแล้ว ซึ่งก็จะมีระยะเวลาแค่ 3 - 4 เดือนเท่านั้น
อาจจะฟังดูเหมือนเป็นเรื่องง่ายและมีเวลาเยอะมากพอ แต่เอาเข้าจริงแล้วสำหรับแอปขนาดใหญ่ที่มีการอัปเดตอยู่ตลอดเวลา การจะหา Slot ว่างเพื่อทำการ Migrate ได้นั้นถือเป็นเรื่องที่ยากพอสมควร เพราะต้องดูว่ามีอะไรที่เปลี่ยนแปลงบ้าง อะไรที่กระทบกับโค้ดที่มีอยู่ในแอป และการเปลี่ยนแปลงบางอย่างอาจจะกระทบมากจนต้องเปลี่ยน Solution ไปเลยก็ว่าได้
แต่เอาเข้าจริง เวลาที่แอนดรอยด์จะอัปเดตเป็นเวอร์ชันใหม่ สิ่งที่เปลี่ยนแปลงในเวอร์ชันใหม่ๆนั้นก็จะมีแค่ "Behavior Changes (การเปลี่ยนแปลงการทำงานที่มีอยู่)" กับ "New Features (การเพิ่มความสามารถใหม่ๆ)"
โดยทีมพัฒนาของแอนดรอยด์แยกระหว่างทั้ง 2 อย่างนี้ออกจากกัน เพราะว่าสิ่งที่จะกระทบกับแอปที่มีอยู่ในตลาดก็คือ Behavior Changes ในขณะที่ New Features ไม่ได้ส่งผลซักเท่าไร เพราะมักจะเป็นการเพิ่มคำสั่งใหม่ๆเข้ามา (ไม่ได้เรียกใช้งานก็ไม่ทำงาน)
และนอกจากนี้ก็จะทำการแบ่ง Behavior Changes เป็นอีก 2 กลุ่มด้วยกันคือ
- High Impact Behavior Changes ที่ส่งผลให้แอปที่เรียกใช้งานสิ่งนั้นไม่สามารถทำงานได้ และมีโอกาสกระทบกับแอปเป็นจำนวนมาก
- Low Impact Behavior Changes ที่ไม่ส่งผลกับการทำงานของแอปมากนัก
เนื่องจาก High Impact Behavior Changes มีโอกาสที่จะส่งผลกระทบกับแอปทั้งหลาย มีความเสี่ยงต่อการบังคับใช้งานทันที จึงทำให้ทีมพัฒนาของแอนดรอยด์เลือกที่จะใช้ Target API Level เป็นตัวกำหนดว่าจะให้ High Impact Behavior Changes มีผลกับแอปตัวไหนบ้าง
ดังนั้นการที่นักพัฒนาจะอัปเดตเลขของ Target API Level ให้สูงขึ้นเพื่อรองรับในแต่ละเวอร์ชัน ก็จะต้องตรวจสอบว่า High Impact Behavior Changes ในเวอร์ชันนั้นๆส่งผลกระทบต่อแอปของตนเองหรือไม่
ถ้าแบบนั้นไม่ต้องอัปเดต Target API Level ก็ได้นี่?
ในเมื่อการอัปเดต Target API Level ให้สูงขึ้น ก็จะมีแต่โอกาสเจอปัญหามากขึ้น และเพิ่มงานให้กับนักพัฒนา แล้วจะทำไปทำไมในเมื่อนักพัฒนาสามารถใช้เป็นเวอร์ชันเก่าต่อไป โดยที่แอปก็ทำงานได้ปกติ
ต้องเข้าใจก่อนว่า Target API Level เป็นวิธีที่ทีมพัฒนาของแอนดรอยด์ใช้เพื่อชะลอระยะเวลาของผลกระทบที่เกิดจาก Behavior Changes แต่ท้ายที่สุดก็ต้องการให้แอปรองรับอยู่ดี เพื่อให้ผู้ใช้ได้รับประสบการณ์ที่ดีที่สุดในแต่ละเวอร์ชัน
จึงเลือกใช้วิธีบังคับให้นักพัฒนาต้องอัปเดตเป็น Target API Level ล่าสุด ผ่าน Google Play แทน ดังนั้นนักพัฒนาก็จะต้องทำการอัปเดต Target API Level ภายในเวลาที่กำหนดเพื่อให้แอปของตนเองสามารถอัปโหลดขึ้น Google Play ได้นั่นเอง
โดย Google Play จะแบ่งระหว่าง New Apps (ส่งขึ้น Google Play ครั้งแรก) และ App Updates (อัปเดตเวอร์ชันใหม่) ซึ่งทั้ง 2 แบบนี้จะมีช่วงเวลาในการบังคับให้อัปเดต Target API Level ที่ต่างกัน โดยเริ่มมีผลกับ New Apps ก่อน แล้วตามด้วย App Updates ในช่วงเวลาต่อมา
ส่วนแอปตัวไหนที่ Target API Level เวอร์ชันต่ำมากๆ ถึงแม้จะอยู่บน Google Play ได้อยู่ แต่เมื่อผู้ใช้ดาวน์โหลดแอปเหล่านั้นมาติดตั้งในเครื่องก็จะได้ข้อความแจ้งเตือนจาก Google Play Protected เพื่อบอกให้ผู้ใช้รับรู้อีกด้วย
และนอกจาก App Store หลักอย่าง Google Play แล้ว บน App Store เจ้าอื่นๆไม่ว่าจะเป็นของ Huawei, OPPO, Vivo, Xiaomi, Baidu, Alibaba, and Tencent ก็จะใช้วิธีแบบเดียวกัน เพื่อบังคับให้นักพัฒนาอัปเดต Target API Level ในแอปของตนเอง เพียงแต่อาจจะกำหนดเลขเวอร์ชันที่แตกต่างกันออกไปในแต่ละ App Store
จึงเป็นที่มาว่าทำไมสุดท้ายแล้วนักพัฒนาจะต้องอัปเดต Target API Level ให้กับแอปอยู่เสมอนั่นเอง
จะรู้ได้อย่างไรว่าในแต่ละเวอร์ชันมีเรื่องอะไรบ้างที่เป็น High Impact Behavior Changes?
ทุกครั้งที่มีการปล่อยแอนดรอยด์เวอร์ชันใหม่ นักพัฒนาสามารถเข้าไปดูใน Documentation ของแต่ละเวอร์ชันได้เลย จะมีอธิบายไว้ในหัวข้อ Behavior changes ซึ่งมีการแบ่งเป็น All apps กับ Apps targeting Android .. (High Impact Behavior Changes)
ยกตัวอย่างเช่น Behavior Changes ของ Android 11
ซึ่งจะมีการอธิบายถึงการทำงานที่เปลี่ยนแปลงไปในเวอร์ชันนั้นๆ และโค้ดที่โดนผลกระทบและต้องแก้ไข และวิธีแก้ไขปัญหา เพื่อให้นักพัฒนาสามารถ Migrate ได้ง่ายนั่นเอง