ข้อกำหนดด้านคุณภาพทางเทคนิคของ Play Console

ข้อกำหนดด้านคุณภาพทางเทคนิคของ Google Play ช่วยให้มั่นใจว่าผู้ใช้แอปของคุณใน Google Play จะได้รับประสบการณ์การใช้งานที่มีคุณภาพสูง ซึ่งเป็นส่วนหนึ่งของเสาหลัก 4 ประการของคุณภาพแอป Android

ข้อกำหนดด้านคุณภาพทางเทคนิคใน Google Play แบ่งออกเป็น 2 หมวดหมู่ ได้แก่

• ข้อกำหนดปัจจุบัน: ข้อกำหนดที่มีการบังคับใช้อยู่ในปัจจุบัน การปฏิบัติตามมาตรฐานเหล่านี้เป็นสิ่งสำคัญในการรักษาความเสถียร ประสิทธิภาพ และการค้นพบได้ของแอปใน Google Play
• ข้อกำหนดที่กำลังจะมีผล: มาตรฐานใหม่ที่ประกาศล่วงหน้า แม้ว่าข้อกำหนดเหล่านี้จะยังไม่มีผลบังคับใช้ แต่คุณควรใช้ช่วงเปลี่ยนผ่านนี้เพื่อประเมินแอป ผสานรวมเครื่องมือและ API ที่แนะนำ และดำเนินการเพื่อให้เป็นไปตามข้อกำหนดก่อนที่การบังคับใช้จะเริ่มต้นขึ้น

ข้อกำหนดที่กำลังจะมีขึ้น

ตามที่ประกาศไว้เมื่อวันที่ 26 สิงหาคม 2569 จะมีข้อกำหนดด้านคุณภาพทางเทคนิคสำหรับแอปและเกมที่เผยแพร่ใน Google Play ในเร็วๆ นี้ บทความในศูนย์ช่วยเหลือนี้จะให้รายละเอียดเพิ่มเติมเกี่ยวกับเกณฑ์ทางเทคนิค และมีจุดประสงค์เพื่อช่วยให้คุณเข้าใจและเตรียมพร้อมสำหรับข้อกำหนดใหม่ก่อนที่จะมีผลบังคับใช้

ลดการใช้งานหน่วยความจำ

ตั้งแต่เดือนกุมภาพันธ์ 2570 เป็นต้นไป แอปและเกมใน Google Play จะต้องเป็นไปตามเกณฑ์ลักษณะการทำงานที่ไม่ถูกต้องใหม่ ดูรายละเอียดเฉพาะด้านล่าง

การเพิ่มประสิทธิภาพโค้ด

ตั้งแต่เดือนกุมภาพันธ์ 2570 เป็นต้นไป แอปและเกมใน Google Play จะต้องเป็นไปตามเกณฑ์การเพิ่มประสิทธิภาพ ดูรายละเอียดเฉพาะด้านล่าง

การกู้คืนการลงชื่อเข้าใช้แบบไม่ต้องแตะ

ตั้งแต่เดือนเมษายน 2570 เป็นต้นไป แอปใน Google Play จะต้องรองรับข้อมูลเข้าสู่ระบบสำหรับการกู้คืนแบบไม่ต้องแตะ ดูรายละเอียดเฉพาะด้านล่าง

ลดการใช้งานหน่วยความจำ

Google Play กำหนดเกณฑ์ลักษณะการทำงานที่ไม่ถูกต้องไว้ใน Vitals หลักของแอปคุณ เราจะเปิดตัวการใช้งานหน่วยความจำเป็นเมตริก Vitals หลักใหม่ ซึ่งประกอบด้วย 2 เมตริก ได้แก่

1. การใช้งานหน่วยความจำ (RSS แบบไม่ระบุตัวตน + Swap)
2. การใช้งานหน่วยความจำบิตแมป

Google Play จะใช้ข้อมูล 28 วันล่าสุดในการประเมินคุณภาพของแอป เช่นเดียวกับเมตริก Android Vitals ที่มีอยู่ซึ่งมีเกณฑ์ลักษณะการทำงานที่ไม่ถูกต้อง

เมตริกเหล่านี้มีให้ใช้งานในส่วนหัวหน่วยความจำภายในภาพรวม Android Vitals รวมถึงภายใน Google Play Developer Reporting API ด้วย

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

ค่าของเมตริกเหล่านี้จะสุ่มตัวอย่างจากอุปกรณ์ของผู้ใช้ที่เลือกใช้ โดยไม่ระบุตัวบุคคลและรวบรวมไว้ ใน Play Console คุณจะเห็นเปอร์เซ็นไทล์ต่างๆ สำหรับแต่ละรายการ รวมถึงเปอร์เซ็นไทล์ที่ 90 ซึ่งใช้เพื่อประเมินประสิทธิภาพของแอปเทียบกับเกณฑ์ลักษณะการทำงานที่ไม่ถูกต้อง ค่าเปอร์เซ็นไทล์ที่ 90 หมายความว่า 10% ของตัวอย่างที่รวบรวมในช่วงระยะเวลา 1 วันมีจำนวนสูงกว่านั้น ตัวอย่างเช่น P90 ขนาด 1.7 GB บ่งชี้ว่า 90% ของตัวอย่างที่รวบรวมมีค่าน้อยกว่า 1.7 GB และ 10% ของตัวอย่างที่รวบรวมมีค่ามากกว่า 1.7 GB

ข้อกำหนดนี้มีผลกับรูปแบบของอุปกรณ์มือถือและแท็บเล็ตเท่านั้น

การใช้งานหน่วยความจำ

Anonymous Resident Set Size (Anon RSS) หมายถึงหน่วยความจำที่จัดสรรโดยแอปพลิเคชันของคุณโดยตรง (เช่น ฮีป Java/Kotlin, การจัดสรรหน่วยความจำแบบเนทีฟ และการแมปหน่วยความจำแบบไม่ระบุตัวตน) ซึ่งไม่สามารถแบ่งหน้าไปยังดิสก์ได้โดยไม่มี Swap บัญชี Swap สำหรับหน่วยความจำที่บีบอัดหรือแบ่งหน้าเป็น zRAM

เกณฑ์จะปรับให้เหมาะกับหมวดหมู่แอปพลิเคชัน (แอปเทียบกับเกม) และระดับ RAM ของอุปกรณ์เพื่อแสดงข้อจำกัดด้านฮาร์ดแวร์ที่แตกต่างกัน ตั้งแต่เดือนกุมภาพันธ์ 2570 เป็นต้นไป แอปและเกมใน Play จะต้องเป็นไปตามเกณฑ์ต่อไปนี้จึงจะถือว่าปฏิบัติตามนโยบาย

แอป

สถานะแอป	เบื้องหน้า	บริการที่ผู้ใช้รับรู้	เบื้องหลัง	แคช
RAM จริง	เปอร์เซ็นไทล์ที่ 90	เปอร์เซ็นไทล์ที่ 90	เปอร์เซ็นไทล์ที่ 90	เปอร์เซ็นไทล์ที่ 90
0 - 4 GB (หน่วยความจำทั้งหมด 0 MB - 3,200 MB)	-	-	-	-
4 GB (หน่วยความจำทั้งหมด 3,200 MB - 4,800 MB)	2 GB	1 GB	1 GB	-
6 GB (หน่วยความจำทั้งหมด 4,800 MB - 6,800 MB)	2.25 GB	1.25 GB	1.25 GB	-
8 GB (หน่วยความจำทั้งหมด 6,800 MB - 9,216 MB)	2.25 GB	1.5 GB	1.5 GB	-
12 GB (หน่วยความจำทั้งหมด 9,216 MB - 14,336 MB)	3.25 GB	1.75 GB	1.75 GB	-
16 GB (หน่วยความจำทั้งหมด 14,336 MB - 18,432 MB)	4.25 GB	2 GB	2 GB	-
16 GB ขึ้นไป (หน่วยความจำทั้งหมดมากกว่า 18,432 MB)	-	-	-	-

หมายเหตุ: ช่วงระดับ RAM แต่ละช่วงจะรวมค่าต่ำสุดไว้ด้วย หน่วยความจำทั้งหมดอาจต่ำกว่า RAM จริงที่โฆษณาไว้ของอุปกรณ์

เกม

สถานะแอป	เบื้องหน้า	บริการที่ผู้ใช้รับรู้	เบื้องหลัง	แคช
RAM จริง	เปอร์เซ็นไทล์ที่ 90	เปอร์เซ็นไทล์ที่ 90	เปอร์เซ็นไทล์ที่ 90	เปอร์เซ็นไทล์ที่ 90
0 - 4 GB (หน่วยความจำทั้งหมด 0 MB - 3,200 MB)	-	-	-	-
4 GB (หน่วยความจำทั้งหมด 3,200 MB - 4,800 MB)	2.25 GB	2.0 GB	2.0 GB	-
6 GB (หน่วยความจำทั้งหมด 4,800 MB - 6,800 MB)	2.75 GB	2.5 GB	2.5 GB	-
8 GB (หน่วยความจำทั้งหมด 6,800 MB - 9,216 MB)	3.5 GB	2.75 GB	2.75 GB	-
12 GB (หน่วยความจำทั้งหมด 9,216 MB - 14,336 MB)	4 GB	3.2 GB	3.2 GB	-
16 GB (หน่วยความจำทั้งหมด 14,336 MB - 18,432 MB)	5 GB	3.5 GB	3.5 GB	-
16 GB ขึ้นไป (หน่วยความจำทั้งหมดมากกว่า 18,432 MB)	-	-	-	-

หมายเหตุ: ช่วงระดับ RAM แต่ละช่วงจะรวมค่าต่ำสุดไว้ด้วย หน่วยความจำทั้งหมดอาจต่ำกว่า RAM จริงที่โฆษณาไว้ของอุปกรณ์ 

การใช้งานหน่วยความจำบิตแมป

การเก็บรักษาบิตแมปไว้เป็นเวลานานในสถานะแอปอื่นๆ นอกเหนือจากเบื้องหน้าอาจใช้หน่วยความจำมากเกินไป เนื่องจากไม่สามารถแสดงผลบิตแมปได้เว้นแต่ UI จะมองเห็นได้ โดยปกติแล้ว คุณไม่ควรเก็บรักษาบิตแมปไว้เป็นเวลานานในสถานะเหล่านี้ แต่แอปอาจได้รับการสุ่มตัวอย่างไม่นานหลังจากมีการเปลี่ยนแปลงสถานะที่คุณตอบสนองต่อ onTrimMemory และปล่อยหน่วยความจำที่เก็บไว้สำหรับบิตแมป ดังนั้นเกณฑ์เหล่านี้จึงสูงกว่า 0 เพื่อรับมือกับเรื่องนี้

สถานะแอป	เปอร์เซ็นไทล์ที่ 90
เบื้องหน้า
บริการที่ผู้ใช้รับรู้	> 200 MB
เบื้องหลัง	> 200 MB
แคช	> 400 MB

การเพิ่มประสิทธิภาพโค้ด DEX

การเพิ่มประสิทธิภาพแอปหรือเกมอย่างเหมาะสมจะช่วยให้โหลดได้เร็วขึ้น ใช้หน่วยความจำน้อยลง ปรับปรุงประสิทธิภาพการแสดงภาพและรันไทม์ รวมถึงลด ANR เครื่องมือเพิ่มประสิทธิภาพจะใช้การลดขนาด การเพิ่มประสิทธิภาพเชิงตรรกะ และการปรับให้ยากต่อการอ่าน (Obfuscation) ร่วมกันเพื่อให้บรรลุเป้าหมายนี้

ตั้งแต่เดือนกุมภาพันธ์ 2570 เป็นต้นไป แอปและเกมใน Google Play จะต้องเป็นไปตามข้อกำหนดขั้นต่ำด้านการเพิ่มประสิทธิภาพ คุณจะต้องเพิ่มประสิทธิภาพ การปรับให้ยากต่อการอ่าน (Obfuscation) และลดขนาดอย่างน้อย 25% สำหรับการอัปโหลดแอปไปยัง Play Console เราเข้าใจว่าไม่ใช่ทุกแอปหรือเกมที่ใช้โค้ด DEX เป็นจำนวนมาก ดังนั้นข้อกำหนดนี้จะมีผลบังคับใช้เฉพาะในกรณีที่คุณมีขนาด DEX ที่ไม่สามารถละเลยได้ คุณดูขนาด DEX รวมถึงเปอร์เซ็นต์การเพิ่มประสิทธิภาพสำหรับ App Bundle แต่ละรายการที่อัปโหลดได้ใน App Bundle Explorer ภายใน Play Console

ข้อกำหนดนี้มีผลกับทุกรูปแบบของอุปกรณ์

			เกม	แอป
การเพิ่มประสิทธิภาพโค้ด			เกมที่มีโค้ด DEX มากกว่า 50 MB	แอปที่มีโค้ด DEX มากกว่า 10 MB
การปรับให้ยากต่อการอ่าน (Obfuscation)			25%	25%
การเพิ่มประสิทธิภาพ			25%	25%
การลดขนาด			25%	25%

คุณสามารถใช้เครื่องมือใดก็ได้ เช่น R8 หรือเครื่องมือย่อขนาดแอปอื่นๆ เพื่อให้ถึงเกณฑ์ขั้นต่ำ 25%

คุณสามารถใช้เครื่องมือวิเคราะห์การกำหนดค่า R8 เพื่อรับข้อมูลเชิงลึกเพิ่มเติมและปรับแต่งประสิทธิภาพให้ดียิ่งขึ้น โปรดทราบว่าหากคุณเผยแพร่ผ่านไปป์ไลน์ CI/CD หรือในสภาพแวดล้อมขององค์กร บิลด์ในเครื่องอาจไม่ตรงกับบิลด์ที่อัปโหลดไปยัง Play Console เพื่อเผยแพร่ไปยังผู้ใช้ทุกประการ ดังนั้นจึงอาจมีความแตกต่างเล็กน้อย   

การกู้คืนการลงชื่อเข้าใช้แบบไม่ต้องแตะ

ตั้งแต่เดือนเมษายน 2570 เป็นต้นไป แอปที่รองรับการลงชื่อเข้าใช้ของผู้ใช้ (ไม่บังคับหรือบังคับ) ต้องรองรับการกู้คืนการลงชื่อเข้าใช้แบบไม่ต้องแตะเมื่อผู้ใช้เปลี่ยนจากอุปกรณ์ Android เครื่องเก่าไปยังเครื่องใหม่ และเลือกกู้คืนข้อมูลจากการโอนจากอุปกรณ์หนึ่งไปยังอีกอุปกรณ์หนึ่งหรือการสำรองข้อมูลในระบบคลาวด์ การลงชื่อเข้าใช้ด้วยตนเองระหว่างการตั้งค่าอุปกรณ์ไม่เพียงแต่สร้างความยุ่งยากในการเตรียมความพร้อมผู้ใช้งานใหม่และลดการคงผู้ใช้ไว้เท่านั้น แต่ยังทำให้แอปเสี่ยงต่อช่องโหว่ด้านความปลอดภัยที่ร้ายแรง เช่น ฟิชชิงและการขโมยข้อมูลเข้าสู่ระบบระหว่างการตั้งค่าด้วย Android Restore Credentials API เป็นวิธีหลักในการแก้ปัญหาเหล่านี้และเป็นไปตามข้อกำหนดนี้ โดยพร้อมใช้งานตั้งแต่ Android 9 ขึ้นไป

 ข้อยกเว้นและขอบเขต:

• แอปที่ผสานรวมกับ Block Store ภายในวันที่ 30 กันยายน 2569 เพื่อกู้คืนสถานะการลงชื่อเข้าใช้ของผู้ใช้จะถือว่าเป็นไปตามข้อกำหนดนี้
• แอปการจัดการอุปกรณ์ส่วนตัวและอุปกรณ์สำหรับองค์กรแบบถาวรอยู่นอกขอบเขตของข้อกำหนดนี้
• แอปที่อยู่ภายใต้ข้อบังคับด้านกฎระเบียบหรือการปฏิบัติตามข้อกำหนดที่เข้มงวดซึ่งส่งผลต่อวิธีการทำงานของฟีเจอร์การลงชื่อเข้าใช้ (เช่น บริการทางการเงินหรือการดูแลสุขภาพ) อาจมีสิทธิ์ได้รับการยกเว้น นักพัฒนาแอปต้องส่งคำขอยกเว้นสำหรับข้อกำหนดนี้ผ่าน Play Console ก่อนวันที่บังคับใช้
• ปัจจุบันเกมอยู่นอกขอบเขตของข้อกำหนดนี้ นักพัฒนาแอปจะได้รับคำแนะนำเฉพาะและโซลูชันที่ปรับแต่งมาสำหรับกรณีการใช้งานการตรวจสอบสิทธิ์ที่ซับซ้อนของเกมในปี 2570 สำหรับเกมที่รองรับบัญชีผู้ใช้บัญชีเดียว เราขอแนะนำอย่างยิ่งให้ใช้ Restore Credentials API เพื่อรองรับการลงชื่อเข้าใช้แบบไม่ต้องแตะ

เราจะเผยแพร่รายละเอียดเพิ่มเติมเกี่ยวกับข้อกำหนดและข้อยกเว้นในอีกไม่กี่เดือนข้างหน้า

กำลังผสานรวมและทดสอบ

ทดสอบการผสานรวมเพื่อให้แน่ใจว่าผู้ใช้จะได้รับประสบการณ์ที่ราบรื่นและคุณได้ปฏิบัติตามข้อกำหนดนี้ ทักษะ AI สำหรับการกู้คืนข้อมูลเข้าสู่ระบบที่เผยแพร่เมื่อเร็วๆ นี้จะช่วยให้คุณผสานรวมได้ง่ายขึ้น

รูปแบบของอุปกรณ์และเวอร์ชัน Android ที่อยู่ในขอบเขต

ข้อกำหนดนี้มีผลกับรูปแบบของอุปกรณ์มือถือ/แท็บเล็ตเท่านั้น ปัจจุบัน Restore Credentials API ไม่รองรับรูปแบบของอุปกรณ์อื่นๆ Restore Credentials พร้อมใช้งานใน Android 9 ขึ้นไป

คำถามที่พบบ่อยเกี่ยวกับข้อกำหนดที่กำลังจะมีขึ้น

ข้อกำหนดด้านหน่วยความจำ

ทำไม Google จึงเริ่มบังคับใช้เมตริกหน่วยความจำ

วิกฤตหน่วยความจำทั่วทั้งระบบนิเวศกำลังจะเกิดขึ้นเนื่องจากต้นทุน RAM ที่เพิ่มขึ้น การใช้หน่วยความจำที่ไม่มีประสิทธิภาพ เช่น แอปเดียวที่มีหน่วยความจำรั่วไหลอย่างควบคุมไม่ได้ซึ่งใช้หน่วยความจำของอุปกรณ์ไปเป็นส่วนใหญ่ จะทำให้อุปกรณ์กระตุกแบบข้ามเฟรมและปิดแอปอื่นๆ ที่ทำงานได้ดีในเบื้องหลัง Android ได้ประกาศขีดจำกัดหน่วยความจำที่เข้มงวด และ Play ต้องการตรวจสอบว่าแอปของคุณอยู่ภายในขีดจำกัดนี้และลดโอกาสที่อุปกรณ์จะต้องสิ้นสุดการทำงานของแอป

ฉันจะลดการใช้งานหน่วยความจำได้อย่างไร

ทำตามแนวทางปฏิบัติแนะนำสำหรับแอปและเกม กลยุทธ์สำคัญ ได้แก่ การปล่อยทรัพยากรใน onTrimMemory() (รวมถึงการใช้ประโยชน์จากเกมเอนจินเพื่อดำเนินการดังกล่าว) การหลีกเลี่ยงหน่วยความจำรั่วไหลแบบคงที่โดยใช้คอมโพเนนต์ที่รับรู้ถึงวงจร การจัดสรรโปรไฟล์และฮีปดัมป์โดยใช้ Perfetto และการลดงานที่ทำงานอยู่เบื้องหลังเป็นเวลานาน

ฉันจะลดการจัดสรรบิตแมปได้อย่างไร

ลดขนาดความละเอียดและถอดรหัสรูปภาพให้ตรงกับขนาดมุมมองการแสดงผลที่แน่นอน ใช้ไลบรารีการโหลดรูปภาพที่ทันสมัย (เช่น Coil หรือ Glide) ที่กำหนดค่าด้วยแคชที่คำนึงถึงหน่วยความจำ นำบิตแมปในหน่วยความจำที่ไม่ได้ใช้ออกเมื่อซ่อน UI (ผ่าน TRIM_MEMORY_UI_HIDDEN ใน onTrimMemory) และหลีกเลี่ยงการเก็บการอ้างอิงแบบคงที่ไปยังบิตแมปหรือการแสดงผล

ฉันจำเป็นต้องใช้ R8 เพื่อเพิ่มประสิทธิภาพโค้ดไหม

แม้ว่าเราจะขอแนะนำอย่างยิ่งให้ใช้ R8 เพื่อการเพิ่มประสิทธิภาพและข้อมูลเชิงลึกขั้นสูง แต่ก็มีเครื่องมือเพิ่มประสิทธิภาพอื่นๆ ที่พร้อมใช้งานและสามารถใช้เพื่อให้เป็นไปตามข้อกำหนดนี้ได้

เหตุใดข้อกำหนดของแอปและเกมจึงแตกต่างกัน

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

Play แยกแยะระหว่างแอปกับเกมอย่างไร

ซึ่งอิงตามหมวดหมู่ที่คุณกำหนดค่าได้ภายในการตั้งค่า Store ใน Play Console ซึ่งจะส่งผลต่อส่วนของ Play Store ที่แอปของคุณปรากฏ โปรดทราบว่าการเปลี่ยนหมวดหมู่ของแอปเป็นหมวดหมู่ที่ไม่ตรงกับฟังก์ชันหลักอย่างถูกต้องเพื่อพยายามให้มีคุณสมบัติตรงตามเกณฑ์ทางเทคนิคที่แตกต่างกันถือเป็นการละเมิดนโยบายข้อมูลเมตาของข้อมูลสินค้าใน Store

ข้อกำหนดเหล่านี้เกี่ยวข้องกับโปรแกรมประสบการณ์การใช้งานแอปและ Level Up Program อย่างไร

เมื่อการบังคับใช้เกณฑ์หน่วยความจำเหล่านี้มีผล แอปและเกมต้องเป็นไปตามเกณฑ์หน่วยความจำทั้งหมดเพื่อให้มีสิทธิ์หรือรักษาสิทธิ์เข้าร่วม AEP และ Level Up

ขีดจำกัดหน่วยความจำของ Android มีผลใน Android 17 ขึ้นไป ข้อกำหนดของ Play มีผลใน A17 ขึ้นไปเท่านั้นใช่ไหม

ไม่ Google Play จะประเมินแอปทุกเวอร์ชันที่มีข้อมูลอยู่ ซึ่งเป็น Android 13 ขึ้นไปสำหรับการใช้งานหน่วยความจำ (AnonRSS + Swap) และการใช้งานหน่วยความจำบิตแมป

เหตุใดจึงมีเกณฑ์ที่แตกต่างกันสำหรับ RSS Anon+Swap และ RAM แต่ละระดับ

การแยกตามระดับ RAM เป็นการรับทราบว่าอุปกรณ์แต่ละเครื่องมีระดับความคลาดเคลื่อนที่ยอมรับได้สำหรับการใช้งานหน่วยความจำมากเกินไปแตกต่างกันไป สิ่งที่ทำงานได้ดีในอุปกรณ์ขนาด 16 GB อาจทำงานได้ไม่ดีเท่าในอุปกรณ์ขนาด 4 GB คุณควรตรวจสอบว่าแอปไม่ใช้หน่วยความจำมากเกินไปใน RAM ทุกระดับ

รูปแบบของอุปกรณ์ใดบ้างที่อยู่ในขอบเขตของข้อกำหนดด้านหน่วยความจำ

สำหรับเมตริกการใช้งานหน่วยความจำ (RSS แบบไม่ระบุตัวตน + Swap) และการใช้งานหน่วยความจำบิตแมป รูปแบบของอุปกรณ์มือถือและแท็บเล็ตจะอยู่ในขอบเขต

มีเครื่องมือใดบ้างที่ช่วยให้ฉันเข้าใจการใช้งานหน่วยความจำได้มากขึ้น

• คุณสามารถเริ่มปรับปรุงหน่วยความจำสำหรับแอปหรือเกมได้โดยใช้คำแนะนำเกี่ยวกับหน่วยความจำ

• Google Play Console (Android Vitals): ตรวจสอบเมตริก P90 แบบต่อเนื่อง 28 วันสำหรับการใช้งานหน่วยความจำ (Anon RSS + Swap) และการใช้งานหน่วยความจำบิตแมป ซึ่งกรองได้ตามสถานะแอป (เบื้องหน้า, บริการที่ผู้ใช้รับรู้, เบื้องหลัง, แคช), ระดับ RAM ของอุปกรณ์ (เช่น 4-6 GB), เวอร์ชัน Android และรุ่นของแอป

• Google Play Developer Reporting API: ค้นหาเมตริกแบบเป็นโปรแกรมเพื่อทำให้การรายงานเป็นอัตโนมัติ ระบุการถดถอยของประสิทธิภาพ และผสานรวมข้อมูล Vitals เข้ากับแดชบอร์ดภายในของคุณ

• เครื่องมือสร้างโปรไฟล์หน่วยความจำและฮีปดัมป์ของ Android Studio: ตรวจสอบการจัดสรรแบบเรียลไทม์ในฮีป Java/Kotlin, หน่วยความจำแบบเนทีฟ และกราฟิก บันทึกและวิเคราะห์ฮีปดัมป์ (.hprof) เพื่อตรวจหาหน่วยความจำรั่วไหล, กิจกรรมที่ยังไม่เผยแพร่, บิตแมปที่ซ้ำกัน และเส้นทางการเก็บรักษา

• Perfetto และ System Tracing: ใช้ Perfetto (heapprofd) สำหรับการสุ่มตัวอย่างที่มีโอเวอร์เฮดต่ำของการจัดสรรเนทีฟและ Java เพื่อระบุ Callstack ที่ทำให้หน่วยความจำเพิ่มขึ้นอย่างรวดเร็ว การติดตามของระบบช่วยติดตามการใช้งานหน่วยความจำในการเปลี่ยนผ่านวงจรและเชื่อมโยงกับเหตุการณ์การหยุดทำงานเนื่องจากหน่วยความจำไม่เพียงพอ (lmkd) นอกจากนี้ยังมีทักษะการวิเคราะห์ AI (เช่น ทักษะ Perfetto AI) เพื่อวิเคราะห์การติดตามและฮีปดัมป์โดยอัตโนมัติด้วย

• เครื่องมือวิเคราะห์ในอุปกรณ์: ใช้ adb shell dumpsys meminfo <package_name> เพื่อดูรายละเอียดแบบเรียลไทม์ของ PSS, Private Dirty (Anon RSS), Swap Dirty (zRAM) และบิตแมป หรือใช้เครื่องมือ ComponentCallbacks2.onTrimMemory() สำหรับการวัดและส่งข้อมูลทางไกลของไคลเอ็นต์ที่กำหนดเอง

ทำไมจึงมีขนาด DEX ขั้นต่ำสำหรับการเพิ่มประสิทธิภาพโค้ด

แม้ว่าเราจะแนะนำให้เพิ่มประสิทธิภาพโค้ดอยู่เสมอเพื่อประโยชน์ด้านประสิทธิภาพมากมาย แต่เราก็สร้างสมดุลระหว่างความพยายามที่จำเป็นในการสร้างและเพิ่มประสิทธิภาพแอปหรือเกมควบคู่ไปกับประโยชน์ของผู้ใช้ ขนาด DEX ที่เล็ก (น้อยกว่า 10 MB สำหรับแอปและน้อยกว่า 50 MB สำหรับเกม) มีผลกระทบต่อหน่วยความจำที่ใช้ของอุปกรณ์อย่างจำกัด ดังนั้นเราจึงไม่ได้บังคับให้เพิ่มประสิทธิภาพโค้ดในส่วนนี้

การกู้คืนการลงชื่อเข้าใช้แบบไม่ต้องแตะ

คีย์การกู้คืนจะยังคงอยู่หรือไม่หากถอนการติดตั้งแอปและติดตั้งใหม่ในอุปกรณ์เครื่องเดียวกัน

ไม่ ระบบจะลบคีย์การกู้คืนโดยอัตโนมัติเมื่อถอนการติดตั้งแอป

ข้อกำหนดนี้มีผลกับอุปกรณ์ทุกรูปแบบไหม

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

ข้อกำหนดนี้มีผลบังคับใช้หรือไม่หากผู้ใช้ไม่ได้ลงชื่อเข้าใช้ หรือมีผลกับแอปที่ไม่มีบัญชีผู้ใช้ไหม

ไม่ ข้อกำหนดนี้ออกแบบมาเพื่อรักษาสถานะการลงชื่อเข้าใช้ที่ใช้งานอยู่ตลอดการเปลี่ยนอุปกรณ์

• แอปที่ไม่มีการลงชื่อเข้าใช้ของผู้ใช้: แอปที่ไม่มีบัญชีผู้ใช้หรือฟังก์ชันการเข้าสู่ระบบจะไม่ได้รับผลกระทบ

• ผู้ใช้ที่ออกจากระบบหรือผู้ใช้ชั่วคราว: หากผู้ใช้ออกจากระบบ ใช้โหมดผู้มาเยือน หรือออกจากระบบก่อนเปลี่ยนอุปกรณ์ แอปควรเปิดขึ้นในสถานะที่ไม่มีการตรวจสอบสิทธิ์แบบเดียวกันในอุปกรณ์ใหม่

การกู้คืนข้อมูลเข้าสู่ระบบใช้ได้กับวิธีการตรวจสอบสิทธิ์ทั้งหมดไหม

ใช่ Restore Credentials API ออกแบบมาให้ทำงานร่วมกับวิธีการตรวจสอบสิทธิ์ใดก็ได้โดยการอนุญาตให้แอปจัดเก็บคีย์การกู้คืน

Restore Credentials จะจัดการขอบเขตการให้สิทธิ์หรือการยืนยันแบบเพิ่มขั้นตอน (เช่น MFA) หรือไม่

• ไม่ Restore Credentials API ออกแบบมาเพื่อการตรวจสอบสิทธิ์เท่านั้น (การกู้คืนข้อมูลประจำตัวและเซสชันของผู้ใช้) แต่จะไม่จัดการคำขอการให้สิทธิ์รอง เช่น การให้สิทธิ์ OAuth หรือการตรวจสอบสิทธิ์แบบหลายปัจจัย

• เราขอแนะนำวิธีแบบ 2 ขั้นตอนดังนี้

  • กู้คืนข้อมูลประจำตัว: ใช้ Restore Credentials เพื่อสร้างสถานะการลงชื่อเข้าใช้หลักของผู้ใช้ขึ้นมาใหม่โดยไม่มีการแจ้งเตือนเมื่อเปิดแอปครั้งแรกในอุปกรณ์เครื่องใหม่

  • ให้สิทธิ์ตามบริบท: ขอสิทธิ์เข้าถึงทรัพยากรที่เฉพาะเจาะจง (เช่น สิทธิ์เข้าถึง Google ไดรฟ์) แบบทันท่วงทีเมื่อผู้ใช้เข้าถึงฟีเจอร์ที่ต้องใช้สิทธิ์ดังกล่าว หากจำเป็น คุณยังสามารถขอการตรวจสอบสิทธิ์แบบเพิ่มขั้นตอน (เช่น MFA) ได้ด้วย

ฉันจะทราบได้อย่างไรว่าการผสานรวมของฉันเป็นไปตามข้อกำหนดหรือไม่

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

ฉันจะทราบได้อย่างไรว่าแอปของฉันเป็นส่วนหนึ่งของข้อยกเว้น

เราจะให้คำแนะนำเพิ่มเติมเกี่ยวกับข้อยกเว้นในภายหลัง

ฉันจะจัดการกรณีการใช้งานการตรวจสอบสิทธิ์แบบหลายปัจจัย (MFA) ได้อย่างไร

Restore Credentials API ไม่ได้จัดการคำถาม MFA และไม่ได้มีไว้เพื่อข้ามนโยบายความปลอดภัยของแอป เมื่อดึงข้อมูลคีย์การกู้คืนในอุปกรณ์ใหม่ แอปของคุณต้องตัดสินใจว่าจะกำหนดให้มีการยืนยันแบบเพิ่มขั้นตอนเพิ่มเติมหรือไม่ การกู้คืนบริบทข้อมูลประจำตัวของผู้ใช้ (เช่น การแสดงข้อความ "ยินดีต้อนรับกลับมา คุณ Alex") เพียงพอที่จะเป็นไปตามข้อกำหนด อย่างไรก็ตาม โปรดทราบว่าการกู้คืนแบบอุปกรณ์ต่ออุปกรณ์เป็นหลักฐานที่ชัดเจนของการครอบครอง จึงไม่จำเป็นต้องใช้ขั้นตอน MFA เพิ่มเติม

ทำไมเกมจึงได้รับการยกเว้นจากข้อกำหนดนี้

ในเบื้องต้น เกมจะได้รับการยกเว้นเนื่องจากเรากำลังพัฒนาโซลูชันที่ปรับแต่งมาโดยเฉพาะสำหรับกรณีการใช้งานการตรวจสอบสิทธิ์ที่ซับซ้อน ซึ่งเป็นเรื่องปกติสำหรับเกม เราขอแนะนำอย่างยิ่งให้เกมที่รองรับการลงชื่อเข้าใช้ด้วยบัญชีเดียวใช้ Restore Credentials API เพื่อรองรับการลงชื่อเข้าใช้แบบไม่ต้องแตะ

ฉันจะใช้ Block Store เพื่อให้เป็นไปตามข้อกำหนดในการเตรียมความพร้อมใช้งานอุปกรณ์ใหม่ได้ไหม

ได้ การผสานรวมกับ Block Store อาจถือว่าเป็นไปตามข้อกำหนด แต่ต้องเป็นการผสานรวมที่เสร็จสมบูรณ์และใช้งานจริงในหรือก่อนวันที่ 30 กันยายน 2569 และกู้คืนสถานะการลงชื่อเข้าใช้ของผู้ใช้ได้สำเร็จ การผสานรวมประเภทอื่นๆ หรือการผสานรวมที่เสร็จสมบูรณ์หลังจากวันที่สิ้นสุดจะไม่ถือว่าเป็นไปตามข้อกำหนด

เหตุใดจึงมีการกำหนดวันที่ 30 กันยายน 2569 เป็นวันสุดท้ายสำหรับการผสานรวม Block Store

วันที่ 30 กันยายน 2569 เป็นเป้าหมายที่ชัดเจนสำหรับทีมที่กำลังผสานรวม Block Store อยู่ในขณะนี้ ซึ่งจะช่วยให้มั่นใจได้ว่าการติดตั้งใช้งานการลงชื่อเข้าใช้แบบไม่ต้องแตะที่มีอยู่จะยังคงใช้ได้ ขณะเดียวกันก็กำหนดให้การผสานรวมในอนาคตเป็นไปตามมาตรฐาน Credential Manager ที่แนะนำ

จะเกิดอะไรขึ้นเมื่อผู้ใช้ออกจากระบบหรือลบบัญชีในอุปกรณ์เครื่องเก่า 

แอปจะต้องลบคีย์การกู้คืนอย่างสม่ำเสมอ หากถอนการติดตั้งแอป ระบบจะลบคีย์การกู้คืนโดยอัตโนมัติ

ฉันจะทำอย่างไรกับผู้ใช้ในโหมดผู้มาเยือน

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

ฉันควรทำอย่างไรกับผู้ใช้ที่ใช้หลายบัญชีในอุปกรณ์เดียวกัน

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

ฉันจะส่งการแจ้งเตือนไปยังผู้ใช้ที่กู้คืนโดยไม่ต้องขอให้ผู้ใช้ให้สิทธิ์การแจ้งเตือนอีกครั้งได้ไหม

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

อื่นๆ

ข้อกำหนดเหล่านี้เป็นแบบไม่บังคับใช่ไหม

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

แหล่งข้อมูลที่มีประโยชน์

การเพิ่มประสิทธิภาพโค้ด

• เปิดใช้การเพิ่มประสิทธิภาพแอปด้วย R8 | คุณภาพของแอป | นักพัฒนาแอป Android
• ใช้ R8 ในโหมดเต็มรูปแบบ | คุณภาพของแอป | นักพัฒนาแอป Android
• ใช้เครื่องมือวิเคราะห์การกำหนดค่า R8 | คุณภาพแอป | นักพัฒนาแอป Android

การใช้งานหน่วยความจำ (RSS แบบไม่ระบุตัวตน + Swap)

• การใช้งานหน่วยความจำ (RSS แบบไม่ระบุตัวตน + Swap) | คุณภาพแอป | นักพัฒนาแอป Android 

การใช้งานหน่วยความจำบิตแมป

• การใช้งานหน่วยความจำบิตแมป | คุณภาพแอป | นักพัฒนาแอป Android 

กู้คืนข้อมูลเข้าสู่ระบบ

• ทำความเข้าใจการกู้คืนข้อมูลเข้าสู่ระบบ
• คู่มืออย่างเป็นทางการ: ใช้การกู้คืนข้อมูลเข้าสู่ระบบ
• เอกสารประกอบการทดสอบ: ทดสอบข้อมูลเข้าสู่ระบบสำหรับการกู้คืนใน Android Studio
• กรณีศึกษาเกี่ยวกับผลลัพธ์จากการใช้งานจริง: วิธีที่ Uber ลดการเข้าสู่ระบบด้วยตนเองได้ 4 ล้านครั้งต่อปี

ทักษะ

ทักษะคือวิธีการและแหล่งข้อมูลแบบโมดูลที่เพิ่มประสิทธิภาพด้วย AI ซึ่งช่วยให้ LLM เข้าใจและดำเนินการตามรูปแบบที่เฉพาะเจาะจงได้ดีขึ้น โดยเป็นไปตามแนวทางปฏิบัติแนะนำและคำแนะนำเกี่ยวกับการพัฒนา Android จาก developer.android.com คุณสามารถใช้ทักษะเหล่านี้ผ่าน Android CLI หรือเครื่องมืออื่นๆ ที่ใช้ LLM

• ทักษะการวิเคราะห์ R8: วิเคราะห์การกำหนดค่า R8 ของแอปและกฎการเก็บรักษา
• ทักษะ Perfetto AI: ใช้เพื่อตีความฮีปดัมป์และรับคำแนะนำที่นำไปใช้ได้จริงเพื่อปรับปรุงประสิทธิภาพของหน่วยความจำ
• ทักษะเครื่องมือสร้างโปรไฟล์ Android: ใช้เพื่อตีความฮีปดัมป์และการติดตาม รวมถึงรับคำแนะนำที่นำไปใช้ได้จริงเพื่อปรับปรุงประสิทธิภาพของหน่วยความจำ
• ทักษะ Restore Credentials: ใช้เพื่อรับความช่วยเหลือในการผสานรวมและทดสอบการตั้งค่าการกู้คืนข้อมูลเข้าสู่ระบบ

ข้อกำหนดปัจจุบัน

ข้อกำหนดทางเทคนิคที่มีอยู่ของ Google Play ประกอบด้วยเกณฑ์ลักษณะการทำงานที่ไม่ถูกต้องในชุด Vitals หลัก รวมถึงข้อกำหนดที่เกี่ยวข้องกับ App Bundle ที่คุณอัปโหลดไปยัง Play Console

Vitals หลักและความเสถียร

Google Play ตรวจสอบเมตริกประสิทธิภาพหลักเพื่อให้มั่นใจว่าแอปเป็นไปตามมาตรฐานความเสถียร การเกินเกณฑ์เหล่านี้อาจส่งผลต่อการค้นพบได้ของแอปคุณใน Google Play Store

• อัตราการขัดข้องที่ผู้ใช้รับรู้: เกณฑ์ 1.09% โดยรวม (ค่าเฉลี่ยในอุปกรณ์ต่างๆ), 8% ต่อรุ่นโทรศัพท์ และ 4% ต่อรุ่นนาฬิกา ดูข้อมูลเพิ่มเติม
• อัตรา ANR ที่ผู้ใช้รับรู้: เกณฑ์โดยรวม 0.47% (ค่าเฉลี่ยในอุปกรณ์ต่างๆ), 8% ต่อรุ่นโทรศัพท์ และ 5% ต่อรุ่นนาฬิกา ดูข้อมูลเพิ่มเติม
• Wake Lock บางส่วนที่มากเกินไป: เกณฑ์ 5% โดยรวม (ค่าเฉลี่ยในอุปกรณ์ต่างๆ) การทำให้อุปกรณ์ทำงานอยู่ตลอดเวลาจะทำให้แบตเตอรี่หมดโดยไม่จำเป็น โปรดตรวจสอบว่าคุณใช้ Wake Lock อย่างถูกต้องและพิจารณาใช้ WorkManager สำหรับงานที่ทำงานอยู่เบื้องหลัง ดูข้อมูลเพิ่มเติม
• การใช้งานแบตเตอรี่มากเกินไป: เกณฑ์ 1% ต่อรุ่นนาฬิกา ดูข้อมูลเพิ่มเติม

ข้อกำหนดทางเทคนิค

Google Play รองรับอุปกรณ์หลากหลายประเภทที่มีการกำหนดค่าฮาร์ดแวร์และสถาปัตยกรรมที่แตกต่างกัน สถาปัตยกรรมบางอย่างเป็นรากฐานสำคัญสำหรับอนาคตของ Android ดังนั้น App Bundle ใหม่ที่อัปโหลดไปยัง Play Console จึงต้องรองรับสถาปัตยกรรมดังกล่าวเพื่อให้เรามอบประสบการณ์การใช้งานแอปของคุณแก่ผู้ใช้ได้

• การรองรับ 64 บิต: แอปที่มีโค้ดแบบเนทีฟต้องรองรับสถาปัตยกรรมแบบ 64 บิตเท่านั้น ดูข้อมูลเพิ่มเติม
• การรองรับหน้าหน่วยความจำขนาด 16 KB: แอปที่มีโค้ดแบบเนทีฟต้องรองรับอุปกรณ์ที่มีหน้าหน่วยความจำขนาด 16 KB แอป Java/Kotlin เท่านั้นที่เข้ากันได้โดยค่าเริ่มต้น ดูข้อมูลเพิ่มเติม
• การรองรับ Wear OS 64 บิตและหน้าหน่วยความจำขนาด 16 KB: ต้องดำเนินการภายในวันที่ 15 กันยายน 2569 ดูข้อมูลเพิ่มเติม
• การรองรับ TV 64 บิตและหน้าหน่วยความจำขนาด 16 KB: ต้องดำเนินการตั้งแต่วันที่ 1 ส.ค. 2569 ดูข้อมูลเพิ่มเติม