แอปจำนวนมากจำเป็นต้องโอนข้อมูลในเบื้องหลัง คู่มือนี้จะอธิบายตัวเลือกสำหรับการโอนข้อมูลในเบื้องหลังที่เชื่อถือได้ รวมถึงแสดงตัวอย่างวิธีใช้งาน
สถานการณ์การโอนข้อมูลในเบื้องหลังที่พบบ่อย
ส่วนนี้จะอธิบายสถานการณ์ทั่วไปบางกรณีที่แอปต้องโอนข้อมูลจากหรือไปยังอุปกรณ์ และช่วยคุณเลือกเครื่องมือที่เหมาะสมกับสถานการณ์
เมื่อเลือกระหว่าง API คุณควรพิจารณาคำถามต่อไปนี้
- การโอนเริ่มต้นโดยผู้ใช้หรือไม่
- มี API ที่มีอยู่ซึ่งจัดการการโอนนี้ไหม
- งานต้องทํางานทันทีไหม
ตัวเลือก | กรณีที่ควรใช้ | การกำหนดเวลา | ตัวอย่าง |
---|---|---|---|
สําหรับการกําหนดเวลางานที่มีระยะเวลาน้อยกว่า 10 นาทีซึ่งควรทํางานเมื่อแอปไม่แสดง |
เลื่อนได้: ปรับตามข้อจำกัดได้ ทันที: ใช้
|
ซิงค์ข้อมูลกับเซิร์ฟเวอร์เป็นระยะๆ การดาวน์โหลดหรืออัปโหลดสื่อขณะอยู่ในเครือข่ายที่เริ่มต้นจากเบื้องหลัง (ไม่ใช่โดยผู้ใช้) |
|
เมื่อผู้ใช้เรียกให้โอนข้อมูลและคุณต้องแจ้งความคืบหน้าของการโอนให้ผู้ใช้ทราบ |
เริ่มต้นโดยผู้ใช้ (เช่น การคลิกปุ่ม) - เริ่มทันที |
การอัปโหลดรูปภาพ การดาวน์โหลดไฟล์ |
|
สำหรับงานที่สำคัญและสั้นๆ หรือเมื่อ WorkManager ไม่พร้อมใช้งาน การแจ้งเตือนจะแจ้งให้ผู้ใช้ทราบความคืบหน้าของการโอน |
เริ่มทันที |
|
|
ใช้หากมีการดำเนินการนั้น ให้ประโยชน์ เช่น เพิ่มประสิทธิภาพและปรับปรุงการผสานรวมระบบ |
แล้วแต่กรณี |
การซิงค์ข้อมูลกับอุปกรณ์ที่เชื่อมต่อ |
หากสถานการณ์ของคุณไม่อยู่ในสถานการณ์ที่พบบ่อย โปรดดูส่วนต่อไปนี้เพื่อค้นหา API ที่เหมาะกับกรณีการใช้งานของคุณมากที่สุด ดูเหมือนว่า WorkManager น่าจะเหมาะ
ใช้ประเภทงานการโอนข้อมูลที่เริ่มต้นโดยผู้ใช้
หากแอปของคุณต้องโอนข้อมูลไปยังเซิร์ฟเวอร์ระยะไกล คุณอาจต้องใช้งานการโอนข้อมูลที่เริ่มต้นโดยผู้ใช้ ประเภทงานนี้เหมาะสำหรับกรณีต่อไปนี้
- ผู้ใช้เริ่มการโอนข้อมูล
- คุณต้องแจ้งความคืบหน้าในการโอนข้อมูลให้ผู้ใช้ทราบอยู่เสมอ
- การที่ระบบขัดจังหวะการโอนจะส่งผลเสียต่อประสบการณ์ของผู้ใช้
หากไม่เป็นไปตามเงื่อนไขใดๆ เหล่านี้ คุณควรใช้ WorkManagerแทน
เช่น แอปสื่ออาจอนุญาตให้ผู้ใช้ดาวน์โหลดอัลบั้มเพื่อเล่นในเครื่อง หากผู้ใช้ต้องการดาวน์โหลดเพลย์ลิสต์และเล่นทันที คุณอาจต้องใช้ประเภทงานการโอนข้อมูลที่เริ่มต้นโดยผู้ใช้ ในทางกลับกัน หากผู้ใช้ต้องการให้เพลย์ลิสต์ที่ดาวน์โหลดไว้อัปเดตเป็นระยะๆ ในเบื้องหลังโดยที่ผู้ใช้ไม่ต้องดำเนินการ WorkManager จะเป็นตัวเลือกที่ดีกว่า
ดูข้อมูลเพิ่มเติม รวมถึงวิธีสร้างและเรียกใช้งานการโอนข้อมูลที่เริ่มต้นโดยผู้ใช้ได้ที่เอกสารประกอบเกี่ยวกับงานการโอนข้อมูลที่เริ่มต้นโดยผู้ใช้
ใช้ WorkManager สำหรับการโอนข้อมูล
ในกรณีส่วนใหญ่ WorkManager เป็นตัวเลือกที่ดีที่สุดเมื่อคุณต้องการกำหนดเวลาการทำงาน โปรดทราบว่าคุณต้องออกแบบงานในลักษณะที่ระบบสามารถขัดจังหวะหรือเลื่อนงานได้ ดูข้อมูลเพิ่มเติมได้ที่เอกสารประกอบของ WorkManager
สิ่งที่ควรคำนึงถึงเมื่อใช้ WorkManager สำหรับการโอนข้อมูลในเบื้องหลังมีดังนี้
- หากต้องการเรียกใช้งานโดยเร็วที่สุด คุณสามารถกำหนดเวลาคำของานด่วน ตัวเลือกนี้จะมีประโยชน์อย่างยิ่งหากคุณกําลังกําหนดเวลาการทํางานเพื่อตอบสนองต่อการออกอากาศ การแจ้งเตือนที่ตรงเวลา หรือข้อความ FCM ที่มีลําดับความสําคัญสูง
- หากต้องการให้งานทํางานเป็นระยะๆ คุณสามารถกําหนดเวลางานเป็นระยะ คำของานเป็นระยะช่วยให้คุณระบุความถี่โดยประมาณที่งานจะทํางานได้ แต่ไม่รับประกันเวลาที่เจาะจง ซึ่งช่วยให้ระบบกำหนดเวลาคำของานจากแอปต่างๆ เพื่อปรับสมดุลดีมานด์ในอุปกรณ์ได้
- คุณควรกําหนดข้อจํากัดของงานเพื่อระบุสถานการณ์ที่เหมาะสมในการเรียกใช้งาน เช่น หากแอปจำเป็นต้องดาวน์โหลดทรัพยากรที่ไม่เร่งด่วน คุณอาจระบุให้งานทำงานขณะที่อุปกรณ์กำลังชาร์จและเชื่อมต่อกับเครือข่ายแบบไม่จำกัดปริมาณการใช้งาน จากนั้น WorkManager จะเรียกใช้งานในเวลาที่โหลดในระบบสมดุล
- WorkManager มีสิทธิ์ยกเลิกและลองทำงานอีกครั้งหากจำเป็น เช่น ผู้ใช้อาจปิดอุปกรณ์ขณะที่งานกำลังทำงานอยู่ จากนั้นระบบจะลองทำงานอีกครั้งเมื่ออุปกรณ์พร้อมใช้งานอีกครั้ง อย่าลืมออกแบบและทดสอบเวิร์กโฟลว์เพื่อให้แน่ใจว่าวงจรการยกเลิกและลองอีกครั้งทำงานได้อย่างถูกต้อง
- งานที่ทำงานอยู่นาน (บริการที่ทำงานอยู่เบื้องหน้า): WorkManager รองรับงานที่ใช้เวลานานกว่า 10 นาทีโดยการสร้างบริการที่ทำงานอยู่เบื้องหน้าสำหรับแอปของคุณ ซึ่งหมายความว่างานดังกล่าวจะขึ้นอยู่กับข้อจำกัดเดียวกันกับบริการและงานที่ทำงานอยู่เบื้องหน้า รวมถึงข้อจำกัดในการเปิดจากเบื้องหลังและขีดจำกัดการเรียกใช้ (ระบบจะกำหนดเวลาใหม่ให้กับงานที่ใช้เวลานานกว่า 10 นาที)
JobScheduler เป็นตัวเลือกอื่นในการตั้งเวลางานเบื้องหลัง ซึ่งแตกต่างจาก WorkManager ตรงที่คุณต้องทำการกําหนดค่าเพิ่มเติม แต่ข้อดีคือคุณจะมีสิทธิ์เข้าถึง API ที่ยังไม่มีให้บริการใน WorkManager เช่น setPrefetch
, setUserInitiated
และ getPendingJobReasons
ใช้ API ที่เฉพาะเจาะจง
ใช้ API ที่เฉพาะเจาะจง หากมี (เช่น ตัวจัดการอุปกรณ์ที่มาพร้อม) หากไม่มี ให้ใช้บริการที่ทำงานอยู่เบื้องหน้าconnectedDevice
พรอมต์ AI
ระบุ API สำหรับกรณีการใช้งานที่เฉพาะเจาะจง
ข้อความแจ้งนี้จะขอ API ที่เฉพาะเจาะจงสำหรับงานการโอนข้อมูล
I want to transfer data from an Android mobile device to [device_type]. Is there a specific API available?
ใช้ประเภทบริการที่ทำงานอยู่เบื้องหน้าเฉพาะเจาะจงมากขึ้น
หาก WorkManager และ JobScheduler ไม่เหมาะกับงานเบื้องหลังบางอย่าง คุณอาจต้องใช้บริการที่ทำงานอยู่เบื้องหน้า
เมื่อพิจารณาใช้บริการที่ทำงานอยู่เบื้องหน้า คุณควรพิจารณาว่ามี API ทางเลือกที่เหมาะกับ Use Case ของคุณมากกว่าหรือไม่
ใช้บริการที่ทำงานอยู่เบื้องหน้าแบบสั้น
หากแอปต้องทำงานที่สำคัญแต่สั้น shortService
บริการที่ทำงานอยู่เบื้องหน้า อาจเป็นสิ่งที่เหมาะที่สุด สถานการณ์ที่shortService
บริการที่ทำงานอยู่เบื้องหน้าอาจเหมาะสมมีดังนี้
- ผู้ใช้เริ่มดำเนินการ (เช่น การซิงค์ข้อมูลกับเซิร์ฟเวอร์) และคุณต้องการตรวจสอบว่าการดำเนินการเสร็จสมบูรณ์แม้ว่าผู้ใช้จะส่งแอปไปยังเบื้องหลังทันที
- บันทึกข้อมูลในหน่วยความจําไปยังพื้นที่เก็บข้อมูลถาวร
- การเข้ารหัสหรือถอดรหัสข้อมูล
ดูข้อมูลทั้งหมดได้ในเอกสารประกอบของ shortService
ใช้บริการที่ทำงานอยู่เบื้องหน้าของอุปกรณ์ที่เชื่อมต่อ
หากต้องการโอนข้อมูลไปยังอุปกรณ์เครื่องอื่นในเครื่อง คุณอาจต้องใช้connectedDevice
บริการที่ทำงานอยู่เบื้องหน้า สถานการณ์ทั่วไปที่อาจต้องดำเนินการมีดังนี้
- การสื่อสารกับอุปกรณ์เสริมบลูทูธ เช่น หูฟังหรือสมาร์ทวอทช์
- การโอนข้อมูลไปยังอุปกรณ์ที่เชื่อมต่อภายในด้วยการเชื่อมต่อ USB, NFC หรือการเชื่อมต่ออินเทอร์เน็ตภายใน
อย่างไรก็ตาม ในสถานการณ์เหล่านี้ คุณอาจใช้เครื่องมือจัดการอุปกรณ์เสริมเพื่อเชื่อมต่อกับอุปกรณ์แทนการใช้บริการที่ทำงานอยู่เบื้องหน้าได้ ดังที่ได้กล่าวไว้เสมอ หาก Use Case ของคุณมี API สําหรับวัตถุประสงค์พิเศษ ก็มักจะเป็นทางเลือกที่ดีกว่าการใช้บริการที่ทำงานอยู่เบื้องหน้า
ใช้บริการที่ทำงานอยู่เบื้องหน้าสำหรับการประมวลผลสื่อแบบใหม่
หากต้องประมวลผลข้อมูลสื่อ คุณสามารถใช้mediaProcessing
บริการที่ทำงานอยู่เบื้องหน้า บริการประเภทนี้พร้อมใช้งานหากแอปกำหนดเป้าหมายเป็น Android 15 ขึ้นไป ตัวอย่างเช่น ประเภทบริการนี้เหมาะสําหรับกรณีที่แอปต้องเปลี่ยนรูปแบบสื่อจากรูปแบบหนึ่งเป็นรูปแบบอื่นเพื่อเล่น ดูข้อมูลเพิ่มเติมได้ที่เอกสารประกอบเกี่ยวกับบริการที่ทำงานอยู่เบื้องหน้าสำหรับการประมวลผลสื่อ