การเพิ่มประสิทธิภาพหน่วยความจำเป็นสิ่งสําคัญในการช่วยให้ประสิทธิภาพราบรื่น ป้องกันการขัดข้องของแอป และรักษาความเสถียรของระบบและประสิทธิภาพของแพลตฟอร์ม แม้ว่าคุณควรตรวจสอบและเพิ่มประสิทธิภาพการใช้หน่วยความจำในทุกแอป แต่อุปกรณ์แอปเนื้อหาสำหรับทีวีก็มีความท้าทายเฉพาะตัวที่แตกต่างจากแอป Android ทั่วไปสำหรับอุปกรณ์พกพา
การใช้หน่วยความจําสูงอาจทําให้เกิดปัญหาเกี่ยวกับลักษณะการทํางานของแอปและระบบ ซึ่งรวมถึงปัญหาต่อไปนี้
- ตัวแอปอาจทำงานช้าหรือกระตุก หรือในกรณีที่เลวร้ายที่สุดคือแอปอาจปิดไป
- บริการของระบบที่ผู้ใช้มองเห็น (การควบคุมระดับเสียง การตั้งค่ารูปภาพ แดชบอร์ด ผู้ช่วยเสียง ฯลฯ) ทำงานช้ามากหรืออาจไม่ทำงานเลย
- คอมโพเนนต์ของระบบอาจถูกหยุดทำงาน จากนั้นคอมโพเนนต์เหล่านี้จะรีสตาร์ท ซึ่งจะทริกเกอร์การแย่งชิงทรัพยากรอย่างรุนแรงและส่งผลต่อแอปที่ทำงานอยู่เบื้องหน้าโดยตรง
- การเปลี่ยนไปยัง Launcher อาจล่าช้าอย่างมาก และทำให้แอปที่ทำงานอยู่เบื้องหน้าดูเหมือนไม่ตอบสนองจนกว่าการเปลี่ยนจะเสร็จสมบูรณ์
- ระบบอาจเข้าสู่สถานการณ์การเรียกคืนโดยตรง โดยหยุดการดำเนินการของเธรดชั่วคราวขณะรอการจัดสรรหน่วยความจำ ปัญหานี้อาจเกิดขึ้นกับเธรดใดก็ได้ เช่น เธรดหลักหรือเธรดที่เกี่ยวข้องกับตัวแปลงรหัส ซึ่งอาจส่งผลให้เฟรมเสียงและวิดีโอตัดออก และ UI ขัดข้อง
ข้อควรพิจารณาเกี่ยวกับหน่วยความจำในอุปกรณ์ทีวี
โดยทั่วไปอุปกรณ์ทีวีจะมีหน่วยความจำน้อยกว่าโทรศัพท์หรือแท็บเล็ตอย่างมาก เช่น การกำหนดค่าที่เราเห็นบนทีวีคือ RAM 1 GB และความละเอียดวิดีโอ 1080p ในขณะเดียวกัน แอปทีวีส่วนใหญ่ก็มีฟีเจอร์ที่คล้ายกัน จึงมีการใช้งานที่คล้ายกันและพบปัญหาที่พบได้ทั่วไป สถานการณ์ 2 อย่างนี้เป็นปัญหาที่อุปกรณ์และแอปประเภทอื่นๆ ไม่ได้พบ
- โดยปกติแล้ว แอปทีวีสำหรับสื่อจะประกอบด้วยทั้งมุมมองรูปภาพแบบตารางกริดและภาพพื้นหลังแบบเต็มหน้าจอ ซึ่งต้องโหลดรูปภาพจำนวนมากลงในหน่วยความจำในช่วงเวลาสั้นๆ
- แอปทีวีเล่นสตรีมมัลติมีเดีย ซึ่งจำเป็นต้องจัดสรรหน่วยความจำจำนวนหนึ่งเพื่อเล่นวิดีโอและเสียง รวมถึงต้องมีบัฟเฟอร์สื่อจำนวนมากเพื่อให้การเล่นราบรื่น
- ฟีเจอร์สื่อเพิ่มเติม (การกรอ การเปลี่ยนตอน การเปลี่ยนแทร็กเสียง เป็นต้น) อาจทำให้หน่วยความจำทำงานหนักขึ้นหากติดตั้งใช้งานอย่างไม่ถูกต้อง
ทำความเข้าใจอุปกรณ์ทีวี
คู่มือนี้มุ่งเน้นที่การใช้งานหน่วยความจําของแอปและเป้าหมายหน่วยความจําสําหรับอุปกรณ์ที่มี RAM ต่ำเป็นหลัก
ในอุปกรณ์ทีวี ให้พิจารณาถึงลักษณะต่อไปนี้
- หน่วยความจำของอุปกรณ์: ปริมาณหน่วยความจำเข้าถึงโดยสุ่ม (RAM) ที่ติดตั้งในอุปกรณ์
- ความละเอียด UI ของอุปกรณ์: ความละเอียดที่อุปกรณ์ใช้แสดงผล UI ของระบบปฏิบัติการและแอปพลิเคชัน ซึ่งโดยทั่วไปจะต่ำกว่าความละเอียดวิดีโอของอุปกรณ์
- ความละเอียดของวิดีโอ: ความละเอียดสูงสุดที่อุปกรณ์เล่นวิดีโอได้
ด้วยเหตุนี้ เราจึงจัดหมวดหมู่อุปกรณ์ประเภทต่างๆ และวิธีที่อุปกรณ์ควรใช้หน่วยความจํา
สรุปเกี่ยวกับอุปกรณ์ทีวี
หน่วยความจำของอุปกรณ์ | ความละเอียดของวิดีโอในอุปกรณ์ | ความละเอียดของ UI ของอุปกรณ์ | isLowRAMDevice() |
---|---|---|---|
1 GB | 1080p | 720p | ใช่ |
1.5 GB | 2160p | 1080p | ใช่ |
≥1.5 GB | 1080p | 720p หรือ 1080p | ไม่* |
≥2 GB | 2160p | 1080p | ไม่* |
อุปกรณ์ทีวีที่มี RAM ต่ำ
อุปกรณ์เหล่านี้อยู่ในสถานการณ์ที่หน่วยความจําจํากัด และจะรายงาน ActivityManager.isLowRAMDevice()
เป็น "จริง" แอปพลิเคชันที่ทำงานบนอุปกรณ์ทีวีที่มี RAM ต่ำต้องใช้มาตรการควบคุมหน่วยความจำเพิ่มเติม
เราถือว่าอุปกรณ์ที่มีลักษณะต่อไปนี้จัดอยู่ในหมวดหมู่นี้
- อุปกรณ์ 1 GB: RAM 1 GB, ความละเอียด UI 720p/HD (1280x720), ความละเอียดวิดีโอ 1080p/FullHD (1920x1080)
- อุปกรณ์ 1.5 GB: RAM 1.5 GB, ความละเอียด UI 1080p/FullHD (1920x1080), ความละเอียดวิดีโอ 2160p/UltraHD/4K (3840x2160)
- สถานการณ์อื่นๆ ที่ OEM กำหนด Flag
ActivityManager.isLowRAMDevice()
ไว้เนื่องจากข้อจำกัดด้านหน่วยความจำเพิ่มเติม
อุปกรณ์ทีวีทั่วไป
อุปกรณ์เหล่านี้ไม่มีปัญหาเกี่ยวกับหน่วยความจำมากนัก เราพิจารณาว่าอุปกรณ์เหล่านี้มีลักษณะต่อไปนี้
- RAM อย่างน้อย 1.5 GB, UI ความละเอียด 720p หรือ 1080p และความละเอียดวิดีโอ 1080p
- RAM อย่างน้อย 2 GB, UI ความละเอียด 1080p และความละเอียดวิดีโอ 1080p หรือ 2160p
แต่ก็ไม่ได้หมายความว่าแอปไม่ควรสนใจการใช้หน่วยความจำในอุปกรณ์เหล่านี้ เนื่องจากการใช้หน่วยความจำอย่างไม่ถูกต้องบางอย่างอาจยังทำให้หน่วยความจำที่มีอยู่หมดและทํางานได้ไม่ดี
เป้าหมายหน่วยความจำในอุปกรณ์ทีวีที่มี RAM ต่ำ
เมื่อวัดหน่วยความจำในอุปกรณ์เหล่านี้ เราขอแนะนําอย่างยิ่งให้ตรวจสอบหน่วยความจําทุกส่วนโดยใช้เครื่องมือวิเคราะห์หน่วยความจําของ Android Studio แอปทีวีควรวิเคราะห์การใช้งานหน่วยความจำและพยายามจัดหมวดหมู่ให้ต่ำกว่าเกณฑ์ที่เรากำหนดไว้ในส่วนนี้
ในส่วนวิธีนับหน่วยความจำ คุณจะเห็นคำอธิบายโดยละเอียดของตัวเลขหน่วยความจำที่รายงาน สำหรับคำจำกัดความของเกณฑ์สำหรับแอปทีวี เราจะมุ่งเน้นที่หมวดหมู่หน่วยความจำ 3 หมวดหมู่ต่อไปนี้
- Anonymous + Swap: ประกอบด้วยหน่วยความจำการจัดสรร Java + เนทีฟ + สแต็กใน Android Studio
- กราฟิก: รายงานในเครื่องมือโปรไฟล์โดยตรง โดยทั่วไปประกอบด้วยพื้นผิวกราฟิก
- ไฟล์: รายงานเป็นหมวดหมู่ "โค้ด" + "อื่นๆ" ใน Android Studio
เมื่อใช้คําจํากัดความเหล่านี้ ตารางต่อไปนี้จะระบุค่าสูงสุดที่กลุ่มหน่วยความจําแต่ละประเภทควรใช้
ประเภทหน่วยความจำ | วัตถุประสงค์ | เป้าหมายการใช้งาน (1 GB) |
---|---|---|
นิรนาม + Swap (Java + เนทีฟ + สแต็ก) | ใช้สำหรับการจัดสรร บัฟเฟอร์สื่อ ตัวแปร และงานอื่นๆ ที่ใช้หน่วยความจำมาก | < 160 MB |
กราฟิก | GPU ใช้สำหรับพื้นผิวและบัฟเฟอร์ที่เกี่ยวข้องกับการแสดงผล | 30-40 MB |
ไฟล์ | ใช้สำหรับหน้าโค้ดและไฟล์ในหน่วยความจำ | 60-80 MB |
หน่วยความจําทั้งหมดสูงสุด (Anon+Swap + กราฟิก + ไฟล์) ต้องไม่เกินค่าต่อไปนี้
- การใช้หน่วยความจำทั้งหมด 280 MB (Anon+Swap + Graphics + File) สำหรับอุปกรณ์ที่มี RAM ต่ำ 1 GB
เราขอแนะนำอย่างยิ่งว่าอย่าให้เกิน
- การใช้งานหน่วยความจำ 200 MB ใน (Anon+Swap + Graphics)
หน่วยความจำของไฟล์
คำแนะนำทั่วไปสำหรับหน่วยความจำที่สำรองข้อมูลไฟล์มีดังนี้
- โดยทั่วไปแล้ว การจัดการหน่วยความจำของระบบปฏิบัติการจะจัดการหน่วยความจำของไฟล์ได้ดี
- เราไม่พบว่าปัญหานี้เป็นต้นเหตุหลักของปัญหาหน่วยความจําเต็มในขณะนี้
อย่างไรก็ตาม เมื่อจัดการกับหน่วยความจำของไฟล์โดยทั่วไป ให้ทำดังนี้
- อย่ารวมไลบรารีที่ไม่ได้ใช้ไว้ในบิลด์ และใช้ไลบรารีชุดย่อยเล็กๆ แทนไลบรารีแบบสมบูรณ์เมื่อเป็นไปได้
- อย่าเปิดไฟล์ขนาดใหญ่ไว้ในหน่วยความจำและปิดไฟล์ทันทีที่ใช้เสร็จ
- ลดขนาดโค้ดที่คอมไพล์แล้วสำหรับคลาส Java และ Kotlin โปรดดูคำแนะนำลดขนาด สร้างความสับสน และเพิ่มประสิทธิภาพแอป
รายการแนะนำเฉพาะทางทีวี
ส่วนนี้จะให้คำแนะนำเฉพาะสำหรับการเพิ่มประสิทธิภาพการใช้หน่วยความจำในอุปกรณ์ทีวี
หน่วยความจำกราฟิก
ใช้รูปแบบและความละเอียดของรูปภาพที่เหมาะสม
- อย่าโหลดรูปภาพที่มีความละเอียดสูงกว่าความละเอียดของ UI ของอุปกรณ์ เช่น รูปภาพ 1080p ควรปรับขนาดเป็น 720p ในอุปกรณ์ UI 720p
- ใช้บิตแมปที่ฮาร์ดแวร์รองรับเมื่อเป็นไปได้
- ในไลบรารีอย่าง Glide ให้เปิดใช้ฟีเจอร์
Downsampler.ALLOW_HARDWARE_CONFIG
ซึ่งปิดอยู่โดยค่าเริ่มต้น การเปิดใช้การตั้งค่านี้จะหลีกเลี่ยงการสร้างบิตแมปซ้ำ ซึ่งจะอยู่ในทั้งหน่วยความจำกราฟิกและหน่วยความจำที่ไม่ระบุตัวตน
- ในไลบรารีอย่าง Glide ให้เปิดใช้ฟีเจอร์
- หลีกเลี่ยงการแสดงผลขั้นกลางและการแสดงผลอีกครั้ง
- ปัญหาเหล่านี้สามารถระบุได้ด้วย Android GPU Inspector
- มองหารูปภาพในส่วน "พื้นผิว" ซึ่งเป็นขั้นตอนที่นำไปสู่การเรนเดอร์ขั้นสุดท้าย ไม่ใช่แค่องค์ประกอบที่ประกอบกัน โดยทั่วไปแล้วเราเรียกสิ่งนี้ว่า"เรนเดอร์ขั้นกลาง"
- สําหรับแอปพลิเคชัน Android SDK คุณมักจะนํารายการเหล่านี้ออกได้โดยใช้
forceHasOverlappedRendering:false
เพื่อสร้างค่าแฟล็กเลย์เอาต์เพื่อปิดใช้การแสดงผลขั้นกลางสําหรับเลย์เอาต์นี้ - โปรดดูหลีกเลี่ยงการแสดงผลที่ทับซ้อนกันซึ่งเป็นแหล่งข้อมูลที่ยอดเยี่ยมเกี่ยวกับการแสดงผลที่ทับซ้อนกัน
- หลีกเลี่ยงการโหลดรูปภาพที่ใช้เป็นตัวยึดตำแหน่ง หากเป็นไปได้ ให้ใช้
@android:color/
หรือ@color
สำหรับพื้นผิวที่ใช้เป็นตัวยึดตำแหน่ง - หลีกเลี่ยงการคอมโพสหลายรูปภาพในอุปกรณ์เมื่อสามารถคอมโพสแบบออฟไลน์ได้ แนะนำให้โหลดรูปภาพเดี่ยวแทนการคอมโพสรูปภาพจากรูปภาพที่ดาวน์โหลด
- ทำตามคำแนะนำการจัดการบิตแมปเพื่อจัดการบิตแมปได้ดียิ่งขึ้น
หน่วยความจํา Anon+Swap
Anon+Swap ประกอบด้วยการจัดสรรแบบ Native + Java + Stack ในเครื่องมือวิเคราะห์หน่วยความจำของ Android Studio
ใช้
ActivityManager.isLowMemoryDevice()
เพื่อตรวจสอบว่าอุปกรณ์มีหน่วยความจำจำกัดหรือไม่ และปรับให้เข้ากับสถานการณ์นี้โดยทำตามหลักเกณฑ์เหล่านี้
- สื่อ:
- ระบุขนาดที่เปลี่ยนแปลงได้สำหรับบัฟเฟอร์สื่อโดยขึ้นอยู่กับ RAM ของอุปกรณ์และความละเอียดของการเล่นวิดีโอ การดำเนินการนี้ควรใช้เวลา 1 นาทีในการเล่นวิดีโอ
- 40-60 MB สำหรับ 1 GB / 1080p
- 60-80 MB สำหรับ 1.5 GB / 1080p
- 80-100 MB สำหรับ 1.5 GB / 2160p
- 100-120 MB สำหรับ 2 GB / 2160p
- การจัดสรรหน่วยความจำสื่อว่างเมื่อเปลี่ยนตอนเพื่อป้องกันไม่ให้หน่วยความจำแบบไม่ระบุตัวตนทั้งหมดเพิ่มขึ้น
- ปล่อยและหยุดทรัพยากรสื่อทันทีเมื่อแอปหยุดทำงาน: ใช้การเรียกกลับวงจรของกิจกรรมเพื่อจัดการทรัพยากรเสียงและวิดีโอ หากคุณไม่ใช่แอปเสียง ให้หยุดเล่นเมื่อ
onStop()
เกิดขึ้นในกิจกรรมของคุณ บันทึกงานทั้งหมดที่คุณกำลังทำอยู่ และตั้งค่าให้ปล่อยทรัพยากร เพื่อกำหนดเวลางานที่คุณอาจต้องใช้ในภายหลัง ดูส่วนงานและการแจ้งเตือน- คุณสามารถใช้คอมโพเนนต์ที่รับรู้วงจร เช่น
LiveData
และLifecycleOwner
เพื่อช่วยจัดการกับการเรียกใช้วงจรของกิจกรรม - คุณยังใช้ Coroutines ของ Kotlin และ Flow ของ Kotlin เพื่อให้ Lifecycle ของงานทราบได้ด้วย
- คุณสามารถใช้คอมโพเนนต์ที่รับรู้วงจร เช่น
- ให้ความสำคัญกับหน่วยความจำของบัฟเฟอร์เมื่อกรอวิดีโอ: นักพัฒนาแอปมักจัดสรรพื้นที่เก็บข้อมูลสำหรับเนื้อหาในอนาคตเพิ่มเติม 15-60 วินาทีเมื่อต้องการเตรียมวิดีโอให้พร้อมสําหรับผู้ใช้ แต่วิธีนี้จะทำให้หน่วยความจําเพิ่มขึ้น
โดยทั่วไปแล้ว อย่าบัฟเฟอร์วิดีโอล่วงหน้านานกว่า 5 วินาทีจนกว่าผู้ใช้จะเลือกตำแหน่งวิดีโอใหม่ หากจำเป็นต้องบัฟเฟอร์ล่วงหน้าเพิ่มเติมขณะกรอไปข้างหน้า ให้ทำดังนี้
- จัดสรรบัฟเฟอร์การกรอล่วงหน้าและนำกลับมาใช้ใหม่
- บัฟเฟอร์ควรมีขนาดไม่เกิน 15-25 MB (ขึ้นอยู่กับหน่วยความจำของอุปกรณ์)
- ระบุขนาดที่เปลี่ยนแปลงได้สำหรับบัฟเฟอร์สื่อโดยขึ้นอยู่กับ RAM ของอุปกรณ์และความละเอียดของการเล่นวิดีโอ การดำเนินการนี้ควรใช้เวลา 1 นาทีในการเล่นวิดีโอ
- การจัดสรร:
- ใช้คําแนะนําเกี่ยวกับหน่วยความจํากราฟิกเพื่อให้มั่นใจว่าคุณไม่ได้ทำซ้ำรูปภาพในหน่วยความจําที่ไม่ระบุตัวตน
- รูปภาพมักเป็นผู้ใช้หน่วยความจำมากที่สุด ดังนั้นการคัดลอกรูปภาพจึงอาจทำให้อุปกรณ์ทำงานหนัก โดยเฉพาะอย่างยิ่งเมื่อมีการไปยังส่วนต่างๆ ของมุมมองตารางกริดรูปภาพเป็นจำนวนมาก
- ปล่อยการจัดสรรโดยยกเลิกการอ้างอิงเมื่อย้ายหน้าจอ ตรวจสอบว่าไม่มีข้อมูลอ้างอิงถึงบิตแมปและออบเจ็กต์เหลืออยู่
- ใช้คําแนะนําเกี่ยวกับหน่วยความจํากราฟิกเพื่อให้มั่นใจว่าคุณไม่ได้ทำซ้ำรูปภาพในหน่วยความจําที่ไม่ระบุตัวตน
- คลัง:
- การจัดสรรหน่วยความจำโปรไฟล์จากไลบรารีเมื่อเพิ่มไลบรารีใหม่ เนื่องจากไลบรารีอาจโหลดไลบรารีเพิ่มเติมด้วย ซึ่งอาจทำให้เกิดการจัดสรรและสร้างการเชื่อมโยง
- เครือข่าย:
- อย่าทำการเรียกใช้เครือข่ายแบบบล็อกระหว่างการเริ่มต้นแอป เนื่องจากจะทําให้เวลาเริ่มต้นแอปพลิเคชันช้าลงและสร้างภาระเพิ่มเติมของหน่วยความจําเมื่อเริ่มต้นใช้งาน ซึ่งหน่วยความจําถูกจํากัดโดยภาระของแอป แสดงหน้าจอที่ขึ้นว่ากำลังโหลดหรือหน้าจอแนะนำก่อน แล้วส่งคำขอเครือข่ายเมื่อมี UI
การเชื่อมโยง
การเชื่อมโยง จะเพิ่มภาระด้านหน่วยความจําเพิ่มเติมเนื่องจากนําแอปพลิเคชันอื่นๆ ไปยังหน่วยความจํา หรือเพิ่มการบริโภคหน่วยความจําของแอปที่เชื่อมโยง (หากอยู่ในหน่วยความจําอยู่แล้ว) เพื่ออํานวยความสะดวกในการเรียก API ด้วยเหตุนี้ จึงลดหน่วยความจำที่ใช้ได้สำหรับแอปที่ทำงานอยู่เบื้องหน้า เมื่อทำการเชื่อมโยงบริการ ให้คำนึงถึงเวลาและระยะเวลาที่คุณใช้การเชื่อมโยง อย่าลืมยกเลิกการเชื่อมโยงทันทีที่ไม่จำเป็นต้องใช้
การเชื่อมโยงทั่วไปและแนวทางปฏิบัติแนะนำ
- Play Integrity API: ใช้เพื่อตรวจสอบความสมบูรณ์ของอุปกรณ์
- ตรวจสอบความสมบูรณ์ของอุปกรณ์หลังจากหน้าจอการโหลดและก่อนเล่นสื่อ
- ปล่อยการอ้างอิง PlayIntegrity
StandardIntegrityManager
ก่อนเล่นเนื้อหา
- คลังการเรียกเก็บเงินของ Play: ใช้สำหรับจัดการการสมัครใช้บริการและการซื้อโดยใช้ Google Play
- เริ่มต้นคลังหลังจากหน้าจอการโหลด และจัดการการเรียกเก็บเงินทั้งหมดก่อนเล่นสื่อ
- ใช้
BillingClient.endConnection()
เมื่อใช้ไลบรารีเสร็จแล้ว และก่อนเล่นวิดีโอหรือสื่อทุกครั้ง - ใช้
BillingClient.isReady()
และBillingClient.getConnectionState()
เพื่อตรวจสอบว่าบริการถูกตัดการเชื่อมต่อหรือไม่ในกรณีที่ต้องดำเนินการเรียกเก็บเงินอีกครั้ง จากนั้นให้ทำBillingClient.endConnection()
อีกครั้งหลังจากดำเนินการเสร็จสิ้น
- GMS FontsProvider
- แนะนำให้ใช้แบบอักษรแบบสแตนด์อโลนในอุปกรณ์ที่มี RAM ต่ำแทนที่จะใช้ผู้ให้บริการแบบอักษร เนื่องจากการดาวน์โหลดแบบอักษรมีค่าใช้จ่ายสูงและ FontsProvider จะเชื่อมโยงบริการเพื่อดำเนินการดังกล่าว
- ไลบรารี Google Assistant: บางครั้งใช้สำหรับการค้นหาและการค้นหาในแอป ให้แทนที่ไลบรารีนี้หากเป็นไปได้
- สำหรับแอป Leanback: ใช้การอ่านออกเสียงข้อความของ Gboard หรือใช้ไลบรารี androidx.leanback
- ปฏิบัติตามหลักเกณฑ์ของ Search สำหรับการใช้การค้นหา
- หมายเหตุ: เราเลิกใช้งาน leanback แล้วและแอปควรเปลี่ยนไปใช้ TV Compose
- สำหรับแอปคอมโพสิท
- ใช้ฟีเจอร์การอ่านออกเสียงข้อความของ Gboard เพื่อใช้การค้นหาด้วยเสียง
- ใช้ Watch Next เพื่อให้เนื้อหาสื่อในแอปของคุณค้นพบได้
- สำหรับแอป Leanback: ใช้การอ่านออกเสียงข้อความของ Gboard หรือใช้ไลบรารี androidx.leanback
บริการที่ทำงานอยู่เบื้องหน้า
บริการที่ทำงานอยู่เบื้องหน้าเป็นบริการประเภทพิเศษที่เชื่อมโยงกับการแจ้งเตือน การแจ้งเตือนนี้จะแสดงในถาดการแจ้งเตือนบนโทรศัพท์และแท็บเล็ต แต่อุปกรณ์ทีวีจะไม่มีถาดการแจ้งเตือนในลักษณะเดียวกับอุปกรณ์เหล่านั้น แม้ว่าบริการที่ทำงานอยู่เบื้องหน้าจะมีประโยชน์เนื่องจากสามารถทำงานต่อไปได้ขณะที่แอปพลิเคชันทำงานอยู่เบื้องหลัง แต่แอปทีวีต้องเป็นไปตามหลักเกณฑ์ต่อไปนี้
ใน Android TV และ Google TV บริการที่ทำงานอยู่เบื้องหน้าจะได้รับอนุญาตให้ทำงานต่อไปได้ในกรณีต่อไปนี้เท่านั้นเมื่อผู้ใช้ออกจากแอป
- สำหรับแอปเสียง: อนุญาตให้บริการที่ทำงานอยู่เบื้องหน้าทำงานต่อไปได้ก็ต่อเมื่อผู้ใช้ออกจากแอปเพื่อเล่นแทร็กเสียงต่อไป บริการต้องหยุดลงทันทีหลังจากการเล่นเสียงสิ้นสุดลง
- สำหรับแอปอื่นๆ: บริการที่ทำงานอยู่เบื้องหน้าทั้งหมดต้องหยุดทำงาน เมื่อผู้ใช้ออกจากแอป เนื่องจากไม่มีการแจ้งเตือนเพื่อแจ้งให้ผู้ใช้ทราบว่าแอปยังคงทำงานอยู่และกำลังใช้ทรัพยากร
- สำหรับงานเบื้องหลัง เช่น การอัปเดตคําแนะนําหรือวิดีโอแนะนํา ให้ใช้
WorkManager
งานและการปลุก
WorkManager
เป็น Android API ที่ทันสมัยสำหรับการกำหนดเวลางานที่เกิดซ้ำในเบื้องหลัง
WorkManager จะใช้ JobScheduler
เวอร์ชันใหม่เมื่อมี (SDK 23 ขึ้นไป) และใช้ AlarmManager
เวอร์ชันเก่าหากไม่มี แนวทางปฏิบัติแนะนำต่อไปนี้เป็นแนวทางปฏิบัติแนะนำสำหรับงานที่กำหนดเวลาไว้บนทีวี
- หลีกเลี่ยงการใช้ API
AlarmManager
ใน SDK 23 ขึ้นไป โดยเฉพาะAlarmManager.set()
,AlarmManager.setExact()
และวิธีการที่คล้ายกัน เนื่องจากไม่อนุญาตให้ระบบตัดสินใจเวลาที่เหมาะสมในการเรียกใช้งาน (เช่น เมื่ออุปกรณ์ไม่มีการใช้งาน) - ในอุปกรณ์ที่มี RAM ต่ำ ให้หลีกเลี่ยงการเรียกใช้งาน เว้นแต่จำเป็นจริงๆ หากจำเป็น ให้ใช้ WorkManager
WorkRequest
สำหรับการอัปเดตคำแนะนำหลังจากเล่นเท่านั้น และพยายามดำเนินการขณะที่แอปยังเปิดอยู่ - กำหนด WorkManager
Constraints
เพื่อให้ระบบเรียกใช้งานของคุณในเวลาที่เหมาะสม
Kotlin
Constraints.Builder() .setRequiredNetworkType(NetworkType.CONNECTED) .setRequiresStorageNotLow(true) .setRequiresDeviceIdle(true) .build()
Java
Constraints.Builder() .setRequiredNetworkType(NetworkType.CONNECTED) .setRequiresStorageNotLow(true) .setRequiresDeviceIdle(true) .build()
- หากต้องเรียกใช้งานเป็นประจำ (เช่น เพื่ออัปเดตดูรายการถัดไปตามกิจกรรมการดูเนื้อหาของผู้ใช้ในแอปบนอุปกรณ์เครื่องอื่น) ให้ใช้หน่วยความจําให้น้อยที่สุดโดยให้ปริมาณการใช้หน่วยความจําของงานน้อยกว่า 30 MB
หลักเกณฑ์ทั่วไปอื่นๆ
หลักเกณฑ์ต่อไปนี้ให้ข้อมูลทั่วไปเกี่ยวกับการพัฒนาแอป Android
- ลดการจัดสรรออบเจ็กต์ให้เหลือน้อยที่สุด เพิ่มประสิทธิภาพการใช้ออบเจ็กต์ซ้ำ และยกเลิกการจัดสรรออบเจ็กต์ที่ไม่ได้ใช้โดยทันที
- อย่าเก็บการอ้างอิงของออบเจ็กต์ โดยเฉพาะบิตแมป
- หลีกเลี่ยงการใช้
System.gc()
และการเรียกใช้หน่วยความจําโดยตรงเนื่องจากจะรบกวนกระบวนการจัดการหน่วยความจําของระบบ เช่น ในอุปกรณ์ที่ใช้ zRAM การเรียกใช้gc()
โดยไม่ตั้งใจอาจทําให้การใช้งานหน่วยความจําเพิ่มขึ้นชั่วคราวเนื่องจากการบีบอัดและการขยายตัวของหน่วยความจํา - ใช้
LazyList
เช่น ที่แสดงในเครื่องมือเลือกแคตตาล็อกใน "เขียน" หรือRecyclerView
ในชุดเครื่องมือ UI ของ Leanback ที่เลิกใช้งานแล้วเพื่อนำมุมมองมาใช้ซ้ำและไม่ต้องสร้างองค์ประกอบรายการขึ้นมาใหม่ - แคชองค์ประกอบที่อ่านจากผู้ให้บริการเนื้อหาภายนอกซึ่งไม่น่าจะเปลี่ยนแปลงและกำหนดช่วงเวลาการอัปเดตเพื่อป้องกันการจัดสรรหน่วยความจำภายนอกเพิ่มเติม
- ตรวจสอบการสูญเสียหน่วยความจําที่อาจเกิดขึ้น
- ระวังกรณีการรั่วไหลของหน่วยความจำทั่วไป เช่น การอ้างอิงภายในเธรดที่ไม่ระบุตัวตน การจัดสรรบัฟเฟอร์วิดีโอใหม่ซึ่งไม่เคยมีการคืนค่า และสถานการณ์อื่นๆ ที่คล้ายกัน
- ใช้การดัมพ์ฮีปเพื่อแก้ไขข้อบกพร่องหน่วยความจำรั่วไหล
- สร้างโปรไฟล์พื้นฐานเพื่อลดจํานวนการคอมไพล์แบบทันท่วงทีที่จําเป็นเมื่อเรียกใช้แอปใน Cold Start
สรุปเครื่องมือ
- ใช้เครื่องมือ เครื่องมือวิเคราะห์หน่วยความจำของ Android Studio เพื่อตรวจสอบปริมาณการใช้หน่วยความจำระหว่างการใช้งาน
- ใช้ heapdump เพื่อตรวจสอบการจัดสรรออบเจ็กต์และบิตแมปที่เฉพาะเจาะจง
- ใช้เครื่องมือวิเคราะห์หน่วยความจำแบบเนทีฟเพื่อตรวจสอบการจัดสรรที่ไม่ใช่ Java หรือ Kotlin
- ใช้ Android GPU Inspector เพื่อตรวจสอบการจัดสรรกราฟิก