หากเผยแพร่แอปไปยัง Google Play คุณควรสร้างและอัปโหลด Android App Bundle เมื่อดำเนินการดังกล่าว Google Play จะสร้างและแสดง APK ที่เพิ่มประสิทธิภาพแล้วโดยอัตโนมัติสำหรับการกำหนดค่าอุปกรณ์ของผู้ใช้แต่ละราย เพื่อให้ดาวน์โหลดเฉพาะโค้ดและทรัพยากรที่จำเป็นต่อการเรียกใช้แอปของคุณ การเผยแพร่ APK หลายรายการจะมีประโยชน์หากคุณไม่ได้เผยแพร่ไปยัง Google Play แต่คุณต้องสร้าง รับรอง และจัดการ APK แต่ละรายการด้วยตนเอง
เมื่อพัฒนาแอปพลิเคชัน Android เพื่อใช้ประโยชน์จาก APK หลายรายการใน Google Play สิ่งสำคัญคือการนำแนวทางปฏิบัติที่ดีมาใช้ตั้งแต่เริ่มต้น และป้องกันอาการปวดหัวโดยไม่จำเป็นในกระบวนการพัฒนา บทเรียนนี้จะแสดงวิธีสร้าง APK หลายรายการของแอป โดยแต่ละรายการจะครอบคลุมระดับ API ที่ต่างกันเล็กน้อย คุณยังจะได้รับเครื่องมือบางอย่างที่จำเป็นต่อการดูแลฐานโค้ด APK หลายรายการให้สะดวกที่สุดอีกด้วย
ยืนยันว่าคุณต้องมี APK หลายรายการ
เมื่อพยายามสร้างแอปพลิเคชันที่ทำงานข้ามแพลตฟอร์ม Android หลายรุ่นได้ โดยทั่วไปแล้วคุณต้องการให้แอปพลิเคชันใช้ประโยชน์จากฟีเจอร์ใหม่ๆ ในอุปกรณ์ใหม่โดยไม่ลดความเข้ากันได้แบบย้อนหลัง ในระยะแรกอาจดูเหมือนว่าการรองรับ APK หลายรายการ เป็นทางออกที่ดีที่สุด แต่เรื่องนี้มักไม่เป็นเช่นนั้น ส่วนการใช้ APK เดี่ยวแทนของคู่มือนักพัฒนาซอฟต์แวร์ APK หลายรายการมีข้อมูลที่เป็นประโยชน์บางอย่างเกี่ยวกับวิธีดำเนินการให้สำเร็จด้วย APK เดียว ซึ่งรวมถึงการใช้ไลบรารีการสนับสนุนของเรา นอกจากนี้ คุณยังดูวิธีเขียนโค้ดที่ทำงานเฉพาะ API บางระดับใน APK เดียวได้โดยไม่ต้องพึ่งเทคนิคที่มีราคาแพงสำหรับการคำนวณ เช่น การไตร่ตรองจาก บทความนี้
หากจัดการได้ การจำกัดแอปพลิเคชันของคุณไว้ใน APK เดียวมีข้อดีหลายประการ ดังนี้
- การเผยแพร่และการทดสอบทำได้ง่ายขึ้น
- มีฐานโค้ดเพียงฐานเดียวที่ต้องดูแลรักษา
- แอปพลิเคชันสามารถปรับตัวตามการเปลี่ยนแปลงการกำหนดค่าอุปกรณ์
- กู้คืนแอปในอุปกรณ์ต่างๆ ได้
- หมดห่วงเรื่องความชื่นชอบของตลาด พฤติกรรมจาก "การอัปเกรด" จาก APK หนึ่งไปยัง APK ถัดไป หรือ APK ที่ใช้กับอุปกรณ์ระดับใด
ส่วนที่เหลือของบทเรียนนี้จะถือว่าคุณได้ศึกษาหัวข้อดังกล่าว ซึมซับเนื้อหาในทรัพยากรที่ลิงก์อยู่อย่างละเอียด และพิจารณาแล้วว่า APK หลายรายการเป็นวิธีที่เหมาะสมสำหรับแอปพลิเคชันของคุณ
ทำแผนภูมิข้อกำหนดของคุณ
เริ่มด้วยการสร้างแผนภูมิง่ายๆ เพื่อระบุจำนวน APK ที่คุณต้องการและช่วง API ของแต่ละ APK ได้อย่างรวดเร็ว หน้าเวอร์ชันแพลตฟอร์มของเว็บไซต์นักพัฒนาแอป Android มีข้อมูลเกี่ยวกับจำนวนอุปกรณ์ที่ใช้งานอยู่ซึ่งใช้แพลตฟอร์ม Android เวอร์ชันหนึ่งๆ เพื่อช่วยในการอ้างอิง นอกจากนี้ แม้ว่าในตอนแรกจะฟังดูง่าย แต่การติดตามชุดระดับ API ที่แต่ละ APK จะกำหนดเป้าหมายจะยากขึ้นอย่างรวดเร็ว โดยเฉพาะในกรณีที่มีบางส่วนทับซ้อนกัน (ซึ่งมักจะเป็นเช่นนั้น) โชคดีที่สามารถสร้างแผนภูมิความต้องการได้อย่างรวดเร็วและง่ายดาย ทั้งยังสามารถอ้างอิงข้อมูลในภายหลังได้อย่างง่ายดาย
หากต้องการสร้างแผนภูมิ APK หลายรายการ ให้เริ่มต้นด้วยแถวของเซลล์ที่แสดงระดับ API ต่างๆ ของแพลตฟอร์ม Android ใส่เซลล์เกินที่ท้ายเพื่อแสดงถึง เวอร์ชันในอนาคตของ Android
3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
ตอนนี้มีเพียงสีในแผนภูมิให้แต่ละสีแสดงถึง APK นี่คือตัวอย่างหนึ่งของวิธีที่คุณ สามารถนำ APK แต่ละรายการไปใช้กับระดับ API บางระดับ
3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
เมื่อสร้างแผนภูมินี้แล้ว ให้แจกจ่ายให้กับทีม การสื่อสารของทีมเกี่ยวกับโปรเจ็กต์ทำได้ง่ายขึ้นทันที เพราะแทนที่จะถามว่า "APK สำหรับ API ระดับ 3-6 เป็นยังไงบ้าง รู้จัก Android 1.x เป็นอย่างไรบ้าง" คุณแค่พูดว่า "APK สีฟ้ามาแล้ว เป็นยังไงบ้าง"
นำโค้ดและทรัพยากรทั่วไปทั้งหมดไปวางในโปรเจ็กต์ไลบรารี
ไม่ว่าคุณจะปรับเปลี่ยนแอปพลิเคชัน Android ที่มีอยู่หรือเริ่มใหม่ตั้งแต่ต้น สิ่งแรกที่คุณควรทำกับฐานของโค้ด และสิ่งสำคัญที่สุดก็คือ ทุกอย่างที่รวมอยู่ในโปรเจ็กต์ไลบรารีต้องอัปเดตเพียงครั้งเดียว (เช่น สตริงที่แปลเป็นภาษาท้องถิ่น ธีมสี ข้อบกพร่องที่แก้ไขในโค้ดที่แชร์) ซึ่งจะช่วยประหยัดเวลาในการพัฒนาและลดโอกาสที่จะเกิดข้อผิดพลาดที่หลีกเลี่ยงได้ง่ายๆ
หมายเหตุ: แม้ว่ารายละเอียดการนำไปใช้เกี่ยวกับวิธีสร้างและรวมโปรเจ็กต์ห้องสมุดจะอยู่นอกเหนือขอบเขตของบทเรียนนี้ แต่คุณก็เรียนรู้ได้อย่างรวดเร็วโดยอ่านสร้างไลบรารี Android
หากคุณกำลังแปลงแอปพลิเคชันที่มีอยู่เพื่อใช้การรองรับ APK หลายรายการ ให้ค้นหาฐานของโค้ดสำหรับไฟล์สตริงที่แปลแล้ว รายการค่า สีของธีม ไอคอนเมนู และเลย์เอาต์ที่จะไม่เปลี่ยนไปใน APK ต่างๆ และนำข้อมูลทั้งหมดไปไว้ในโปรเจ็กต์ไลบรารี โค้ดที่ไม่เปลี่ยนแปลงมากนัก ควรไปอยู่ในโครงการไลบรารี คุณอาจพบว่าตัวเองขยายคลาสเหล่านี้เพื่อเพิ่มเมธอด 1-2 รายการจาก APK ไปยัง APK
ในทางกลับกัน หากคุณสร้างแอปพลิเคชันใหม่ตั้งแต่ต้น ให้ลองเขียนโค้ดในโปรเจ็กต์ไลบรารีก่อนให้มากที่สุดเท่าที่จะเป็นไปได้ จากนั้นเลื่อนลงไปแต่ละ APK เท่านั้นหากจำเป็น วิธีนี้จัดการได้ง่ายกว่าในระยะยาวเมื่อเทียบกับการเพิ่มเนื้อหาลงในคลังวิดีโอ 1 รายการ แล้วเพิ่มรายการอื่น แล้วอีกหลายเดือนหลังจากนั้น เพื่อพยายามตัดสินใจว่าจะย้าย BLOB นี้ไปยังส่วนของไลบรารีโดยไม่ต้องแก้ไขอะไรเพิ่มเติม
สร้างโปรเจ็กต์ APK ใหม่
คุณควรมีโปรเจ็กต์ Android แยกต่างหากสำหรับ APK แต่ละรายการที่จะเผยแพร่ วางโปรเจ็กต์ไลบรารีและโปรเจ็กต์ APK ที่เกี่ยวข้องทั้งหมดไว้ในโฟลเดอร์หลักเดียวกันเพื่อให้จัดระเบียบได้ง่าย นอกจากนี้ โปรดทราบว่า APK แต่ละรายการต้องมีชื่อแพ็กเกจเดียวกัน แม้ว่าไม่จำเป็นต้องแชร์ชื่อแพ็กเกจกับไลบรารีก็ตาม หากคุณมี APK 3 รายการตามรูปแบบที่อธิบายก่อนหน้านี้ ไดเรกทอรีรากอาจมีลักษณะดังนี้
alexlucas:~/code/multi-apks-root$ ls foo-blue foo-green foo-lib foo-red
เมื่อสร้างโปรเจ็กต์แล้ว ให้เพิ่มโปรเจ็กต์คลังเป็นข้อมูลอ้างอิงสำหรับโปรเจ็กต์ APK แต่ละโปรเจ็กต์ หากเป็นไปได้ ให้กำหนดกิจกรรมเริ่มต้นในโปรเจ็กต์ไลบรารี และขยายกิจกรรมดังกล่าวในโปรเจ็กต์ APK ของคุณ การมีการกำหนดกิจกรรมเริ่มต้นในโปรเจ็กต์ไลบรารีทำให้คุณมีโอกาสวางการเริ่มต้นแอปพลิเคชันทั้งหมดไว้ในที่เดียว เพื่อให้ APK แต่ละรายการไม่ต้องนำงาน "สากล" มาใช้ใหม่ เช่น การเริ่มต้น Analytics, การตรวจสอบการอนุญาตให้ใช้สิทธิ และขั้นตอนเริ่มต้นอื่นๆ ที่ไม่ได้เปลี่ยนแปลงมากนักจาก APK เป็น APK
ปรับไฟล์ Manifest
เมื่อผู้ใช้ดาวน์โหลดแอปพลิเคชันที่ใช้ APK หลายรายการผ่าน Google Play ระบบจะเลือก APK ที่ถูกต้องโดยใช้กฎง่ายๆ 2 ข้อดังนี้
- ไฟล์ Manifest ต้องแสดงให้เห็นว่า APK ดังกล่าวมีสิทธิ์
- APK ที่มีหมายเลขเวอร์ชันสูงสุดจะเป็นผู้ชนะ
ตัวอย่างเช่น เรามาลองชุด APK หลายรายการที่อธิบายไว้ก่อนหน้านี้ และสมมติว่าเราไม่ได้ตั้งระดับ API สูงสุดสำหรับ APK ใดก็ตาม เมื่อพิจารณาแยกกัน ช่วงของ APK แต่ละรายการจะมีลักษณะดังนี้
3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
เนื่องจาก APK ที่มี minSdkVersion สูงกว่าต้องมีรหัสเวอร์ชันที่สูงกว่าด้วย เราจึงทราบดีว่าในแง่ของค่า versionCode นั้น สีแดง ≥ เขียว ≥ น้ำเงิน เราจึงยุบแผนภูมิให้มีลักษณะดังต่อไปนี้ได้อย่างมีประสิทธิภาพ
3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
ตอนนี้ เรามาสมมติว่า APK สีแดงมีข้อกำหนดบางอย่างซึ่งอีก 2 รายการไม่มี หน้าตัวกรองใน Google Play ของคู่มือนักพัฒนาแอป Android มีรายการสาเหตุที่เป็นไปได้ทั้งหมด สมมติว่าสีแดงต้องใช้กล้องหน้า ความจริงแล้ว จุดประสงค์ทั้งหมดของ APK สีแดงคือการรวมกล้องหน้าเข้ากับฟังก์ชันการทำงานใหม่ที่ยอดเยี่ยมซึ่งเพิ่มเข้ามาใน API 11 แต่ปรากฏว่าอุปกรณ์ที่รองรับ API 11 บางรุ่นไม่มีกล้องหน้าด้วยซ้ำ สยองขวัญ
แต่โชคดีที่หากผู้ใช้เรียกดู Google Play จากอุปกรณ์ดังกล่าว Google Play จะดูไฟล์ Manifest และเห็นว่า Red ระบุกล้องหน้าเป็นข้อกำหนด แล้วจึงละเว้นแอปดังกล่าวโดยปริยาย เนื่องจากพิจารณาแล้วว่า Red กับอุปกรณ์นั้นไม่เข้ากัน จากนั้นระบบจะเห็นว่า ไม่เพียงแต่จะเข้ากันได้กับอุปกรณ์ที่มี API 11 ในอนาคต (เนื่องจากไม่ได้กำหนด maxSdkVersion) แต่ Green ยังไม่สนใจว่ามีกล้องหน้าหรือไม่ด้วย ผู้ใช้ยังคงดาวน์โหลดแอปจาก Google Play ได้ เพราะถึงแม้จะเกิดเหตุร้ายแรงเกี่ยวกับกล้องหน้า แต่ก็ยังมี APK ที่รองรับ API ระดับนั้นอยู่
เพื่อให้ APK ทั้งหมดของคุณอยู่ใน "แทร็ก" แยกกัน จึงจำเป็นต้องมีรูปแบบรหัสเวอร์ชันที่ดี รหัสที่แนะนำสามารถดูได้ที่ส่วนรหัสเวอร์ชันของคู่มือนักพัฒนาซอฟต์แวร์ของเรา เนื่องจากชุด APK ตัวอย่างต้องใช้ 1 ใน 3 มิติข้อมูลที่เป็นไปได้เท่านั้น การแยกแต่ละ APK ด้วย 1,000 ก็ถือว่าเพียงพอแล้ว ตั้งค่าตัวเลข 2 หลักแรกเป็น minSdkVersion สำหรับ APK ดังกล่าว จากนั้นจะเพิ่มขึ้นจากตัวเลขนั้น ซึ่งอาจมีลักษณะดังนี้
น้ำเงิน: 03001, 03002, 03003, 03004...
เขียว: 07001, 07002, 07003, 07004...
แดง:11001, 11002, 11003, 11004...
เมื่อนำทั้งหมดนี้มารวมกัน ไฟล์ Manifest ของ Android ก็น่าจะมีลักษณะดังต่อไปนี้
สีน้ำเงิน:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="03001" android:versionName="1.0" package="com.example.foo"> <uses-sdk android:minSdkVersion="3" /> ...
สีเขียว:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="07001" android:versionName="1.0" package="com.example.foo"> <uses-sdk android:minSdkVersion="7" /> ...
สีแดง:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="11001" android:versionName="1.0" package="com.example.foo"> <uses-sdk android:minSdkVersion="11" /> ...
ตรวจสอบเช็กลิสต์ก่อนการเปิดตัว
โปรดตรวจสอบรายการต่อไปนี้อีกครั้งก่อนอัปโหลดไปยัง Google Play โปรดอย่าลืมว่า APK เหล่านี้เกี่ยวข้องกับ APK หลายรายการโดยเฉพาะ และไม่ได้เป็นการรายการตรวจสอบที่สมบูรณ์สำหรับแอปพลิเคชันทั้งหมดที่อัปโหลดไปยัง Google Play แต่อย่างใด
- APK ทั้งหมดต้องมีชื่อแพ็กเกจเดียวกัน
- APK ทั้งหมดต้องรับรองด้วยใบรับรองเดียวกัน
- หาก APK ทับซ้อนกันในเวอร์ชันแพลตฟอร์ม รายการที่มี minSdkVersion สูงกว่าต้องมีรหัสเวอร์ชันที่สูงกว่า
- ตรวจสอบตัวกรองในไฟล์ Manifest อีกครั้งเพื่อหาข้อมูลที่ขัดแย้งกัน (APK ที่รองรับเฉพาะคัพเค้กในหน้าจอ XLARGE จะไม่เห็นไม่มีใครเห็น)
- ไฟล์ Manifest ของ APK แต่ละรายการต้องไม่ซ้ำกันในหน้าจอ พื้นผิว openGL หรือเวอร์ชันแพลตฟอร์มที่รองรับอย่างน้อย 1 รายการ
- ลองทดสอบ APK แต่ละรายการบนอุปกรณ์อย่างน้อย 1 เครื่อง แต่คุณมีโปรแกรมจำลองอุปกรณ์ที่ปรับแต่งได้มากที่สุดแห่งหนึ่งในอุตสาหกรรมอยู่ในเครื่องสำหรับพัฒนาซอฟต์แวร์ สุดๆ ไปเลย
นอกจากนี้ ควรตรวจสอบ APK ที่คอมไพล์แล้วก่อนจะเผยแพร่ผลิตภัณฑ์ออกสู่ตลาด เพื่อให้แน่ใจว่าไม่มีสิ่งใดที่ไม่คาดคิดที่อาจซ่อนแอปพลิเคชันของคุณบน Google Play ได้ อันที่จริงแล้ว การใช้ เครื่องมือ "aapt" ทำได้ง่ายๆ Aapt (เครื่องมือแพ็กเกจเนื้อหา Android) เป็นส่วนหนึ่งของกระบวนการสร้างสำหรับการสร้างและจัดแพ็กเกจแอปพลิเคชัน Android และเป็นเครื่องมือที่มีประโยชน์มากสำหรับการตรวจสอบ
>aapt dump badging package: name='com.example.hello' versionCode='1' versionName='1.0' sdkVersion:'11' uses-permission:'android.permission.SEND_SMS' application-label:'Hello' application-icon-120:'res/drawable-ldpi/icon.png' application-icon-160:'res/drawable-mdpi/icon.png' application-icon-240:'res/drawable-hdpi/icon.png' application: label='Hello' icon='res/drawable-mdpi/icon.png' launchable-activity: name='com.example.hello.HelloActivity' label='Hello' icon='' uses-feature:'android.hardware.telephony' uses-feature:'android.hardware.touchscreen' main supports-screens: 'small' 'normal' 'large' 'xlarge' supports-any-density: 'true' locales: '--_--' densities: '120' '160' '240'
เมื่อคุณตรวจสอบเอาต์พุต aapt อย่าลืมตรวจสอบว่าไม่มีค่าที่ขัดแย้งกันสำหรับหน้าจอการสนับสนุนและหน้าจอที่เข้ากันได้ รวมถึงไม่มีค่า "uses-feature" ที่ไม่ต้องการซึ่งเพิ่มเข้ามาเนื่องจากสิทธิ์ที่คุณตั้งค่าไว้ในไฟล์ Manifest ในตัวอย่างข้างต้น APK จะไม่แสดงแก่อุปกรณ์จำนวนมาก
เหตุผล การเพิ่มสิทธิ์ที่จำเป็น SEND_SMS จะเพิ่มข้อกำหนดฟีเจอร์ของ android.hardware.telephony โดยปริยาย เนื่องจาก API 11 คือ Honeycomb (เวอร์ชันที่เพิ่มประสิทธิภาพของ Android โดยเฉพาะสำหรับแท็บเล็ต) และไม่มีอุปกรณ์ Honeycomb ที่มีฮาร์ดแวร์สำหรับโทรศัพท์ Google Play จะกรอง APK นี้ออกในทุกกรณี จนกว่าอุปกรณ์ในอนาคตจะมีระดับ API ที่สูงกว่าและมีฮาร์ดแวร์โทรศัพท์
โชคดีที่ปัญหานี้แก้ไขได้ง่ายๆ ด้วยการเพิ่มค่าต่อไปนี้ลงในไฟล์ Manifest
<uses-feature android:name="android.hardware.telephony" android:required="false" />
เพิ่มข้อกําหนด android.hardware.touchscreen
โดยปริยายเช่นกัน หากต้องการให้ APK แสดงในทีวีที่ไม่ใช่อุปกรณ์หน้าจอสัมผัส คุณควรเพิ่มข้อมูลต่อไปนี้ลงในไฟล์ Manifest
<uses-feature android:name="android.hardware.touchscreen" android:required="false" />
เมื่อทำตามรายการตรวจสอบก่อนการเปิดตัวเรียบร้อยแล้ว ให้อัปโหลด APK ไปยัง Google Play ระบบอาจใช้เวลาสักครู่เพื่อให้แอปพลิเคชันปรากฏขึ้นเมื่อเรียกดู Google Play แต่เมื่อปรากฏแล้ว ให้ตรวจสอบอีกครั้งเป็นครั้งสุดท้าย ดาวน์โหลดแอปพลิเคชันลงในอุปกรณ์ทดสอบใดๆ ที่คุณอาจมี เพื่อให้แน่ใจว่า APK กำหนดเป้าหมายไปยังอุปกรณ์ที่ต้องการ ขอแสดงความยินดี ทุกอย่างเรียบร้อยแล้ว