App Standby — คืออะไร ระดับการรอคอย และหลักการทำงาน

App Standby คืออะไร

App Standby — เป็นส่วนประกอบของระบบจัดการพลังงาน Android ที่เปิดตัวใน Android 6.0 (API 23) และได้รับการออกแบบใหม่ครั้งสำคัญใน Android 9 (API 28) หน้าที่ของมันคือระบุว่าแอปใดที่ผู้ใช้ใช้งานไม่บ่อย และจำกัดกิจกรรมเบื้องหลังของแอปเหล่านั้น: คำขอเครือข่าย, การซิงค์, JobScheduler และ AlarmManager แตกต่างจาก Doze ตรงที่ App Standby ไม่ขึ้นอยู่กับสถานะของหน้าจอหรือการเคลื่อนไหวของอุปกรณ์

ระบบจำแนกแอปออกเป็น 4 bucket (ระดับ): Active, Working Set, Frequent และ Rare แต่ละระดับกำหนดว่ากิจกรรมเบื้องหลังถูกจำกัดมากน้อยเพียงใด การเปลี่ยนระหว่างระดับเกิดขึ้นโดยอัตโนมัติตามรูปแบบการใช้งานแอป: ผู้ใช้เปิดแอปบ่อยแค่ไหน, รับการแจ้งเตือน, โต้ตอบกับวิดเจ็ต

App Standby ทำงานคู่กับ Doze Mode แต่ไม่ได้แทนที่มัน หาก Doze จำกัดกิจกรรมเบื้องหลังของแอปทั้งหมดเมื่ออุปกรณ์ไม่ได้ใช้งาน App Standby จะจำกัดแอปเฉพาะโดยไม่ขึ้นกับสถานะของอุปกรณ์ แอประดับ Rare จะมีข้อจำกัดแม้ในขณะที่ใช้โทรศัพท์อย่างจริงจัง หากผู้ใช้ไม่ได้เปิดมันเป็นเวลาหลายวัน

Bucket ใน Android 9+

ตั้งแต่ Android 9 (API 28) เป็นต้นไป Google ได้นำ App Standby Buckets — การจำแนกประเภทอย่างเป็นทางการพร้อมค่าตัวเลข — มาใช้ ระบบใช้การเรียนรู้ของเครื่องเพื่อทำนายการเปิดใช้แอปครั้งถัดไป หากแบบจำลองทำนายว่าแอปจะถูกเปิดในอีกไม่กี่ชั่วโมงข้างหน้า แอปจะได้รับ bucket Active หากการทำนายบ่งชี้ถึงการใช้งานที่หายาก — จะกำหนด Rare

App Standby ทำงานอย่างไร

App Standby วิเคราะห์ปัจจัยหลายประการเพื่อกำหนด bucket: เวลาตั้งแต่การเปิดแอปครั้งล่าสุดโดยผู้ใช้, ความถี่ในการโต้ตอบ (จำนวนการเปิดใช้ต่อวัน/สัปดาห์), การรับการแจ้งเตือน FCM, การมีวิดเจ็ตที่ใช้งานอยู่บนเดสก์ท็อป และการสมัครรับ AlarmManager ยิ่งแอปไม่ได้ใช้งานนานเท่าใด bucket ก็ยิ่งต่ำลงและข้อจำกัดก็ยิ่งเข้มงวดมากขึ้น

บริการระบบ UsageStatsManager รวบรวมสถิติการใช้งานแอปและส่งไปยัง StandbyController — ส่วนประกอบของเฟรมเวิร์กที่คำนวณ bucket สำหรับแต่ละแอป StandbyController ยังพิจารณาเหตุการณ์ของระบบด้วย: หลังการอัปเดตแอป bucket ของมันจะถูกรีเซ็ตเป็น Active เป็นเวลาสองสามวันเพื่อให้ผู้ใช้สามารถประเมินฟีเจอร์ใหม่ๆ

คุณสมบัติที่สำคัญ: App Standby ไม่ได้ฆ่ากระบวนการของแอป แต่จำกัดความสามารถเบื้องหลังของมัน แอปยังคงทำงานต่อไปหากผู้ใช้โต้ตอบกับมัน (bucket Active) ทันทีที่ผู้ใช้ปิดแอปและไม่กลับมา ระบบจะเริ่มนับเวลาไม่ได้ใช้งานและสามารถลด bucket ลงเป็น Working Set หรือ Frequent

ผลกระทบของ FCM ต่อ bucket

การรับข้อความ FCM high-priority สามารถเพิ่ม bucket ของแอปเป็น Active ได้ชั่วคราว ซึ่งทำให้แอปมีโอกาสทำงาน (ประมวลผลข้อความ, ซิงค์ข้อมูล) โดยไม่มีข้อจำกัด อย่างไรก็ตาม หลังจากประมวลผลเสร็จ bucket จะกลับไปเป็นค่าเดิม Google แนะนำให้ใช้กลไกนี้เพื่อส่งการแจ้งเตือนสำคัญ ไม่ใช่เพื่อทำให้แอป "มีชีวิตอยู่"

ระดับของ App Standby

App Standby ใช้ 4 ระดับ (bucket) เพื่อจำแนกแอป แต่ละระดับกำหนดเวลาหน่วงสำหรับงานเบื้องหลัง: ยิ่งระดับต่ำเท่าใด การหน่วงเวลาก็ยิ่งนานขึ้น ระบบย้ายแอประหว่างระดับโดยอัตโนมัติตามสถิติการใช้งานที่รวบรวมในช่วง 7–14 วันที่ผ่านมา

Active — แอปที่ใช้งานอยู่

Active — แอปที่ผู้ใช้โต้ตอบด้วยเมื่อเร็วๆ นี้ (เปิดใช้, รับการแจ้งเตือน หรือใช้วิดเจ็ต) ใน bucket นี้ไม่มีข้อจำกัด: JobScheduler ทำงานทันที, เครือข่ายพร้อมใช้งาน, AlarmManager ทำงานอย่างแม่นยำ แอปจะอยู่ใน Active จนกว่าผู้ใช้จะหยุดโต้ตอบกับมันเป็นเวลาหลายชั่วโมง

Working Set และ Frequent

Working Set — แอปถูกใช้งานเป็นประจำ (หลายครั้งต่อสัปดาห์) การหน่วงเวลางานเบื้องหลังสูงสุด 2 ชั่วโมง Frequent — แอปถูกใช้งานหลายครั้งต่อเดือน การหน่วงเวลาสูงสุด 4 ชั่วโมง ในทั้งสองระดับ เครือข่ายจะใช้ได้เฉพาะในหน้าต่างบำรุงรักษา และ AlarmManager อาจถูกหน่วงเวลา JobScheduler จะทำงานในหน้าต่างที่ใกล้ที่สุด

Rare — ใช้งานไม่บ่อย

Rare — ระดับที่เข้มงวดที่สุด กำหนดให้กับแอปที่ผู้ใช้ไม่ได้เปิดมากกว่า 30 วัน การหน่วงเวลางานเบื้องหลังสูงสุด 24 ชั่วโมง เครือข่ายถูกบล็อกอย่างสมบูรณ์นอกหน้าต่างบำรุงรักษา AlarmManager ทำงานเฉพาะกับแฟล็ก setAndAllowWhileIdle() โดยจำกัด 1 ครั้งต่อ 9 นาที การแจ้งเตือน FCM high-priority ยังคงถูกส่ง แต่ไม่สามารถเพิ่ม bucket ได้

ข้อจำกัดใน App Standby

App Standby กำหนดข้อจำกัดกับการดำเนินการเบื้องหลังหลายประเภท แตกต่างจาก Doze ตรงที่ข้อจำกัดของ App Standby ทำงานโดยไม่ขึ้นกับสถานะของหน้าจอและที่ชาร์จ นักพัฒนาควรออกแบบแอปโดยคำนึงถึงข้อจำกัดเหล่านี้ โดยเฉพาะอย่างยิ่งหากกลุ่มเป้าหมายใช้แอปไม่สม่ำเสมอ

JobScheduler และ WorkManager

JobScheduler — API หลักที่ได้รับผลกระทบจาก App Standby ขึ้นอยู่กับ bucket การดำเนินการงานจะล่าช้าตั้งแต่ 2 ถึง 24 ชั่วโมง WorkManager ซึ่งใช้ JobScheduler ภายใต้ฝาครอบ (บน API 23+) ก็ได้รับผลกระทบจากการหน่วงเวลาเหล่านี้เช่นกัน สำหรับงานที่สำคัญตามเวลา ให้ใช้ Expedited Work ซึ่งเรียกใช้ Foreground Service ภายใต้ฝาครอบและไม่ขึ้นกับ bucket

ข้อจำกัดเครือข่าย

แอปใน bucket Working Set, Frequent และ Rare ไม่สามารถทำคำขอเครือข่ายตามอำเภอใจได้ตลอดเวลา ระบบอนุญาตให้เข้าถึงเครือข่ายเฉพาะในหน้าต่างบำรุงรักษาที่ซิงค์กับ Doze สำหรับการส่งข้อมูลสำคัญ ให้ใช้ FCM high-priority ตามด้วยการซิงค์ในหน้าต่างบำรุงรักษา

AlarmManager

AlarmManager ใน App Standby ปฏิบัติตามกฎเดียวกันกับใน Doze: การปลุกแบบแม่นยำ (setExact()) จะถูกหน่วงเวลา และ setAndAllowWhileIdle() ถูกจำกัดที่ 1 ครั้งต่อ 9 นาที สำหรับ bucket Rare การหน่วงเวลาอาจถึง 24 ชั่วโมง ทำให้ AlarmManager ไม่เหมาะสำหรับการวางแผนงานที่แม่นยำในแอปที่ใช้งานไม่บ่อย

• JobScheduler — งานถูกหน่วงเวลา 2–24 ชั่วโมงขึ้นอยู่กับ bucket
• เครือข่าย — เข้าถึงได้เฉพาะในหน้าต่างบำรุงรักษาสำหรับ Working Set และต่ำกว่า
• AlarmManager — การปลุกแม่นยำถูกหน่วง; setAndAllowWhileIdle — 1/9 นาที
• SyncManager — การซิงค์บัญชีถูกหน่วงเวลาจนถึงหน้าต่างบำรุงรักษา
• Widget updates — ความถี่ในการอัปเดตวิดเจ็ตอาจลดลง

วิธีได้รับการยกเว้น

การยกเว้น จาก App Standby สามารถรับได้สองวิธี: ผ่านการตั้งค่าแบตเตอรี่ของผู้ใช้ (Whitelist ด้วยตนเอง) หรือผ่านระบบ Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS อย่างไรก็ตาม Google ควบคุมการเข้าถึงการยกเว้นอย่างเข้มงวด — แอปที่ไม่มีเหตุผลเพียงพอสำหรับการยกเว้น เสี่ยงที่จะถูกปฏิเสธใน Google Play

ผู้ใช้สามารถปิดข้อจำกัดสำหรับแอปเฉพาะด้วยตนเองผ่าน การตั้งค่า → แอป → [แอป] → แบตเตอรี่ → การเพิ่มประสิทธิภาพ → ไม่เพิ่มประสิทธิภาพ ซึ่งจะลบข้อจำกัดของ App Standby และ Doze สำหรับแอปที่เลือกอย่างสมบูรณ์ นักพัฒนาสามารถแสดงคำแนะนำหรือไดอะล็อกระบบให้ผู้ใช้ดู แต่ไม่สามารถบังคับเพิ่มแอปในรายการยกเว้น

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

เมื่อใดควรขอการยกเว้น

การขอ Whitelist มีความหมายเฉพาะสำหรับแอปที่มีฟังก์ชันเบื้องหลังที่สำคัญ: การนำทางแบบเรียลไทม์, การตรวจสอบสุขภาพ, การโทร VoIP, การรักษาความปลอดภัยอุปกรณ์ สำหรับแอปส่วนใหญ่ การใช้ Foreground Service หรือ WorkManager ก็เพียงพอ Google Play อาจปฏิเสธการเผยแพร่หากแอปขอการยกเว้นโดยไม่มีความจำเป็นที่ชัดเจน

// ขอการยกเว้นจาก App Standby
val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).apply {
    data = Uri.parse("package:\${applicationContext.packageName}")
}

// ตรวจสอบสถานะปัจจุบัน
val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
val isIgnoring = powerManager.isIgnoringBatteryOptimizations(packageName)

การทดสอบ App Standby

การทดสอบ App Standby ผ่าน ADB ช่วยให้คุณบังคับกำหนด bucket ใดๆ ให้กับแอปและตรวจสอบพฤติกรรมของมัน ซึ่งสำคัญอย่างยิ่งสำหรับแอปที่พึ่งพาการซิงค์เบื้องหลัง การแจ้งเตือน หรือการอัปเดตเป็นระยะ ควรทำการทดสอบบนอุปกรณ์จริงหรืออีมูเลเตอร์ที่ใช้ Android 9+

สำหรับการตั้งค่า bucket แบบบังคับ ให้ใช้คำสั่ง adb shell am set-standby-bucket [package] [bucket] โดย bucket สามารถเป็น: active, working_set, frequent หรือ rare สำหรับดู bucket ปัจจุบัน — adb shell am get-standby-bucket [package] ระบบยังอนุญาตให้จำลองการไม่ได้ใช้งานแอปเป็นเวลานานผ่านคำสั่ง adb shell dumpsys usagestats

# ตั้งค่า bucket Rare สำหรับแอป
$ adb shell am set-standby-bucket com.example.app rare

# ดู bucket ปัจจุบัน
$ adb shell am get-standby-bucket com.example.app

# รีเซ็ต buckets ทั้งหมดเป็น Active
$ adb shell dumpsys usagestats clear

# ดู buckets ทั้งหมดของระบบ
$ adb shell dumpsys usagestats

สิ่งที่ต้องตรวจสอบ

หลังจากตั้งค่า bucket Rare แล้ว ให้ตรวจสอบ: งาน WorkManager ทำงานภายใน 24 ชั่วโมงหรือไม่, AlarmManager ทำงานหรือไม่, การแจ้งเตือน FCM ถูกส่งหรือไม่, Foreground Service ทำงานโดยไม่มีข้อจำกัดหรือไม่ WorkManager ที่มีนโยบาย Expedited Work ควรทำงานทันทีแม้ใน bucket Rare เนื่องจากใช้ Foreground Service งาน WorkManager ปกติจะถูกหน่วงเวลาตาม bucket

แนวทางปฏิบัติที่ดีที่สุด

การพัฒนาแอปที่ทนทานต่อ App Standby ต้องใช้แนวทางที่รอบคอบต่องานเบื้องหลัง หลักการพื้นฐาน: อย่าถือว่าแอปอยู่ใน bucket Active เสมอไป ออกแบบงานเบื้องหลังให้ทำงานได้อย่างถูกต้องแม้มีการหน่วงเวลาตามแบบฉบับของ bucket Frequent และ Rare

ใช้ WorkManager กับ Expedited Work

Expedited Work (WorkManager 2.7+) เรียกใช้ Foreground Service ภายใต้ฝาครอบ ซึ่งทำให้งานดำเนินการทันทีโดยไม่ขึ้นกับ bucket นี่เป็นตัวเลือกที่เหมาะสมที่สุดสำหรับงานที่ไม่สามารถหน่วงเวลาได้: การส่งข้อความ, การซิงค์หลังการชำระเงิน, การจัดการสายเรียกเข้า งาน WorkManager ปกติจะดำเนินการในหน้าต่างบำรุงรักษาโดยคำนึงถึง bucket

FCM สำหรับการเปิดใช้งานอีกครั้ง

ใช้ข้อความ FCM high-priority เพื่อปลุกแอปจาก App Standby เมื่อแอปได้รับข้อความดังกล่าว bucket ของมันจะเพิ่มขึ้นเป็น Active ชั่วคราว และสามารถทำงานที่จำเป็น (การซิงค์, การอัปเดตข้อมูล) ได้ หลังจากประมวลผลเสร็จ bucket จะกลับไปเป็นระดับเดิม

หลีกเลี่ยงการคงอยู่ในหน่วยความจำอย่างถาวร

อย่าพยายามหลีกเลี่ยง App Standby ด้วยบริการเบื้องหลังถาวร WakeLock หรือข้อความ FCM เป็นระยะ Google ต่อสู้กับแนวปฏิบัติเหล่านี้อย่างจริงจัง — แอปอาจถูกทำเครื่องหมายว่าใช้พลังงานมากและถูกจำกัดอย่างเข้มงวดยิ่งขึ้น ใช้ WorkManager สำหรับงานเป็นระยะ และใช้ Foreground Service เฉพาะเมื่องานนั้นผู้ใช้มองเห็นได้จริง

• WorkManager — API ที่ต้องการ; Expedited Work ทำงานโดยไม่หน่วงเวลา
• FCM high-priority — เพิ่ม bucket เป็น Active ชั่วคราวเพื่อประมวลผลข้อความ
• อย่าหลีกเลี่ยง App Standby — ส่งผลให้ระบบบล็อกแอป
• Foreground Service — เปลี่ยนแอปเป็น Active ชั่วคราวระหว่างทำงาน
• ทดสอบ แอปใน bucket Rare และ Frequent ผ่าน ADB ก่อนทุกการเผยแพร่