งานเบื้องหลังในการพัฒนาแอปมือถือ: คืออะไร มีกี่ประเภท และทำงานอย่างไร

งานเบื้องหลังคืออะไร?

งานเบื้องหลังคือโค้ดใดๆ ที่ทำงานเมื่อแอปไม่อยู่ในเบื้องหน้า (หน้าจอที่ใช้งานอยู่) ซึ่งอาจรวมถึง: การซิงค์ข้อมูลกับเซิร์ฟเวอร์เป็นระยะ การดาวน์โหลดไฟล์ขนาดใหญ่ การประมวลผลการแจ้งเตือนแบบพุช การติดตามตำแหน่งทางภูมิศาสตร์ การอัปเดตวิดเจ็ต แต่ละแพลตฟอร์มมีข้อจำกัดของตัวเอง สำหรับการทำงานเบื้องหลัง: iOS เข้มงวดกว่า (เวลาเบื้องหลัง 10–30 นาที) Android ผ่อนปรนกว่า แต่ได้เข้มงวดกฎตั้งแต่เวอร์ชัน 9

สถาปัตยกรรมของงานเบื้องหลังสร้างขึ้นบนสามระดับ: (1) งานทันที — ดำเนินการทันที (Foreground Service); (2) งานที่เลื่อนออกไป — ดำเนินการภายใต้เงื่อนไขที่เหมาะสม (WorkManager, BGTaskScheduler); (3) งานเป็นระยะ — ทำซ้ำตามช่วงที่กำหนด การเลือกระดับที่ถูกต้องกำหนดว่างานจะเสร็จทันเวลาหรือไม่ และจะนำไปสู่การปฏิเสธแอปจากร้านค้าหรือไม่

ทั้งสองแพลตฟอร์ม Google/Apple แนะนำอย่างยิ่งให้ใช้ API แบบประกาศแทนการจัดการเธรดโดยตรงในเบื้องหลัง WorkManager บน Android และ BGTaskScheduler บน iOS ช่วยให้ระบบกระจายงานเบื้องหลังระหว่างแอปได้อย่างเหมาะสม จัดกลุ่มงานเพื่อประหยัดพลังงาน ที่ IT Sectr เรามักเริ่มออกแบบสถาปัตยกรรมเบื้องหลังด้วยการวิเคราะห์ข้อกำหนดด้านความถี่และความเร่งด่วนของการอัปเดต

งานเบื้องหลังบน iOS (Background Fetch, BGTaskScheduler)

iOS มีกลไกหลายอย่างสำหรับการทำงานเบื้องหลัง Background Fetch — การอัปเดตเนื้อหาเป็นระยะตามช่วงเวลาที่ระบบกำหนด (ไม่ใช่นักพัฒนา) แอปได้รับหน้าต่างประมาณ 30 วินาทีเพื่อดาวน์โหลดข้อมูลใหม่ Background Fetch เปิดใช้งานผ่าน Capabilities → Background Modes → Background Fetch และนำไปใช้ใน AppDelegate: application(_:performFetchWithCompletionHandler:)

BGTaskScheduler คือ API ที่ทันสมัยสำหรับ iOS 13+ ซึ่งแทนที่ Background Fetch นักพัฒนาลงทะเบียนงานด้วยตัวระบุ และระบบจะเรียกใช้เมื่อเงื่อนไขเหมาะสม BGAppRefreshTask — สำหรับการอัปเดตเนื้อหาสั้นๆ; BGProcessingTask — สำหรับงานที่ใช้เวลานาน (ล้างแคช, ซิงค์ฐานข้อมูล) งานจะถูกลงทะเบียนเมื่อเริ่มแอป และระบบจะจัดตารางการทำงานโดยพิจารณาจากสถานะแบตเตอรี่ เครือข่าย และกิจกรรมของผู้ใช้

Background Modes — รายการโหมดที่อนุญาตให้ทำงานเบื้องหลังสำหรับสถานการณ์เฉพาะ: Audio (เล่นเบื้องหลัง), Location (ติดตาม GPS), VoIP (โทรผ่าน PushKit), BLE (เชื่อมต่ออุปกรณ์ Bluetooth), Processing (งานยาวผ่าน BGTaskScheduler) แต่ละโหมดต้องการการชี้แจงเหตุผลระหว่างการตรวจสอบ App Store การใช้โหมดโดยไม่มีความจำเป็นจริงเป็นสาเหตุทั่วไปของการปฏิเสธแอป

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

งานเบื้องหลังบน Android (WorkManager, JobScheduler, Foreground Service)

Android มีชุด API ที่หลากหลายที่สุดสำหรับงานเบื้องหลัง แต่ตั้งแต่เวอร์ชัน 8.0 (API 26) กฎก็เข้มงวดมากขึ้น WorkManager เป็นโซลูชันที่ Google แนะนำสำหรับงานเบื้องหลังทุกประเภท WorkManager รับประกันการทำงานแม้หลังจากรีสตาร์ทอุปกรณ์ (ผ่าน BootReceiver) และรองรับเชนงาน LiveData/Flow ที่สังเกตได้ และความเข้ากันได้ย้อนหลังจนถึง API 14

WorkManager ใช้ Worker — คลาสพื้นฐานที่มีเมธอด doWork() Constraints กำหนดเงื่อนไขการทำงาน: NetworkType.CONNECTED, BatteryNotLow, StorageNotLow PeriodicWorkRequest — สำหรับงานเป็นระยะที่มีช่วงเวลาขั้นต่ำ 15 นาที WorkManager ปรับตัวโดยอัตโนมัติกับ Doze Mode และ App Standby จัดกลุ่มงานเป็นหน้าต่างบำรุงรักษา ตัวอย่าง Worker อย่างง่าย:

class SyncWorker(
    context: Context,
    params: WorkerParameters
) : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {
        return try {
            val repository =
                Injection.provideRepository(applicationContext)
            repository.syncData()
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

// Запланировать задачу
val constraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .build()

val syncRequest = OneTimeWorkRequestBuilder<SyncWorker>()
    .setConstraints(constraints)
    .build()

WorkManager.getInstance(context)
    .enqueue(syncRequest)

JobScheduler — API ที่เก่ากว่า (Android 5+, API 21) จัดตารางงานตามเงื่อนไขที่ระบุ (เครือข่าย, การชาร์จ, ไม่ใช้งาน) ข้อจำกัด: ไม่รองรับการรีสตาร์ทอุปกรณ์ (ต้องใช้ BootReceiver) และไม่มีสถานะที่สังเกตได้ JobScheduler เหมาะสำหรับงานง่ายๆ ในโปรเจ็กต์เดิม; สำหรับโปรเจ็กต์ใหม่ ให้ใช้ WorkManager

Foreground Service — บริการที่ผู้ใช้เห็นผ่านการแจ้งเตือนถาวร (ongoing notification) ใช้สำหรับ: เล่นเพลง, ติดตาม GPS, ดาวน์โหลดไฟล์ใหญ่ Foreground Service มีลำดับความสำคัญสูง — ระบบจะไม่ฆ่ามันเมื่อหน่วยความจำต่ำ ตั้งแต่ Android 13 ต้องได้รับอนุญาต FOREGROUND_SERVICE_SPECIAL_USE สำหรับบางประเภท ทางเลือกคือ WorkManager กับ ForegroundServiceOption (งานยาว)

AlarmManager — สำหรับงานที่ต้องทำงานในเวลาที่แน่นอน (ปลุก, เตือนความจำ) AlarmManager สามารถปลุกอุปกรณ์จาก Doze Mode (setAlarmClock) ไม่แนะนำสำหรับการซิงค์ปกติเนื่องจากการใช้พลังงานสูง สำหรับงานเป็นระยะ ให้ใช้ WorkManager และ AlarmManager เฉพาะเมื่อเวลาแน่นอนมีความสำคัญ

Doze Mode และ App Standby

Doze Mode คือโหมดประหยัดพลังงานใน Android ที่ส่งผลต่อการทำงานของงานเบื้องหลัง เปิดตัวใน Android 6.0 (API 23) เมื่ออุปกรณ์ไม่ได้ชาร์จ หน้าจอปิด และอุปกรณ์อยู่นิ่ง Doze Mode จะบล็อกคำขอเครือข่าย เลื่อน JobScheduler และ WakeLock เป็นระยะ Doze จะเปิดหน้าต่างบำรุงรักษา — ช่วงเวลาสั้นๆ ที่แอปสามารถทำงานที่เลื่อนออกไปได้ ตั้งแต่ Android 7.0 (API 24) Doze จะทำงานเมื่อหน้าจอปิด ไม่ใช่แค่เมื่ออยู่นิ่งสนิท

App Standby — โหมดที่แอปที่ไม่ได้ใช้ถูกนำไปสู่สถานะสแตนด์บาย หากแอปไม่มีการแจ้งเตือนที่ใช้งานอยู่และไม่ได้เปิดเป็นเวลาหลายวัน แอปจะถูกวางใน Standby Bucket: แอคทีฟ (active), working, frequent, rare ยิ่งใช้แอปน้อย ข้อจำกัดยิ่งเข้มงวด: คำขอเครือข่ายถูกเลื่อน การซิงค์ถูกบล็อก JobScheduler ไม่ทำงาน

WakeLock — กลไกที่ทำให้อุปกรณ์ตื่นอยู่ (ป้องกันไม่ให้หลับ) ใช้เพื่อทำงานสำคัญให้เสร็จ ต้องปล่อย WakeLock (release) หลังจากงานเสร็จ มิฉะนั้นแบตเตอรี่จะหมดภายในไม่กี่ชั่วโมง WakeLock ไม่ทำงานใน Doze Mode — ระบบจะไม่สนใจ การทำงานกับ WakeLock บน Android 8+ ต้องได้รับอนุญาต WAKE_LOCK และการจัดการวงจรชีวิตที่ถูกต้อง

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

เคล็ดลับปฏิบัติ

เมื่อออกแบบงานเบื้องหลัง ให้ปฏิบัติตามเคล็ดลับเหล่านี้ 1. ใช้ WorkManager เสมอสำหรับโปรเจ็กต์ Android ใหม่ มันแก้ปัญหาความเข้ากันได้ Doze Mode และการรีสตาร์ทอุปกรณ์ 2. บน iOS เลือก BGTaskScheduler มากกว่า Background Fetch สำหรับ iOS 13+ 3. ใช้ Foreground Service เฉพาะเมื่องานต้องการการแจ้งเตือนที่มองเห็นได้จริง 4. อย่าใช้ WakeLock ในทางที่ผิด — มันทำให้แบตเตอรี่หมดและอาจนำไปสู่การปฏิเสธแอป 5. ทดสอบงานเบื้องหลังใน Doze Mode: adb shell dumpsys deviceidle force-idle 6. ตรวจสอบความสำเร็จของงานผ่านการบันทึกและวิเคราะห์เสมอ 7. จำข้อจำกัด: iOS ให้เวลาประมาณ 30 วินาทีสำหรับ Background Fetch และประมาณสองสามนาทีสำหรับ BGProcessingTask Android WorkManager ไม่รับประกันเวลาทำงานที่แน่นอน