Các ứng dụng thường xuyên cần làm nhiều việc cùng một lúc. API Android cung cấp nhiều cách để bạn thực hiện việc này. Việc chọn đúng tuỳ chọn là rất quan trọng; một tuỳ chọn có thể phù hợp với một tình huống nhưng lại không phù hợp với một tình huống khác. Việc chọn sai API có thể làm giảm hiệu suất hoặc hiệu quả sử dụng tài nguyên của ứng dụng, từ đó làm tiêu hao pin và làm giảm hiệu suất tổng thể của thiết bị của người dùng. Trong một số trường hợp, việc chọn sai phương pháp có thể khiến ứng dụng của bạn không được liệt kê trong Cửa hàng Play.
Tài liệu này giải thích các lựa chọn mà bạn có thể sử dụng và giúp bạn chọn lựa chọn phù hợp với trường hợp của mình.
Thuật ngữ
Một số thuật ngữ quan trọng liên quan đến tác vụ trong nền có thể được sử dụng theo nhiều cách trái ngược nhau. Vì vậy, điều quan trọng là bạn phải xác định các điều khoản của chúng tôi.
Nếu một ứng dụng đang chạy ở chế độ nền, thì hệ thống sẽ áp dụng một số hạn chế đối với ứng dụng đó. (Ví dụ: trong hầu hết các trường hợp, ứng dụng chạy ở chế độ nền không thể chạy các dịch vụ trên nền trước.)
Trong tài liệu này, chúng tôi sẽ sử dụng thuật ngữ "tác vụ" để chỉ một thao tác mà ứng dụng đang thực hiện bên ngoài quy trình công việc chính. Để đảm bảo sự thống nhất trong việc hiểu biết, chúng tôi đã chia các loại tác vụ này thành 3 danh mục chính: công việc không đồng bộ, API lên lịch tác vụ và dịch vụ trên nền trước.
Chọn lựa chọn phù hợp
Trong hầu hết các trường hợp, bạn có thể tìm ra API phù hợp để sử dụng cho tác vụ của mình bằng cách xác định danh mục (công việc không đồng bộ, API lập lịch biểu tác vụ hoặc dịch vụ trên nền trước) mà tác vụ đó thuộc về.
Nếu vẫn không chắc chắn, bạn có thể sử dụng biểu đồ quy trình mà chúng tôi cung cấp để đưa ra quyết định chính xác hơn. Mỗi tuỳ chọn này sẽ được mô tả chi tiết hơn ở phần sau của tài liệu này.
Có hai trường hợp chính cần xem xét đối với các tác vụ trong nền:
- Tác vụ do người dùng khởi tạo trong khi ứng dụng hiển thị
- Tác vụ được bắt đầu để phản hồi một sự kiện, nội bộ hoặc bên ngoài
Hai tình huống này có cây quyết định riêng.
Công việc không đồng bộ
Trong nhiều trường hợp, ứng dụng chỉ cần thực hiện các thao tác đồng thời khi đang chạy ở nền trước. Ví dụ: một ứng dụng có thể cần thực hiện một phép tính tốn nhiều thời gian. Nếu thực hiện phép tính trên luồng giao diện người dùng, người dùng sẽ không thể tương tác với ứng dụng cho đến khi phép tính kết thúc; điều này có thể dẫn đến lỗi ANR. Trong trường hợp như vậy, ứng dụng nên sử dụng tuỳ chọn công việc không đồng bộ.
Các tuỳ chọn công việc không đồng bộ phổ biến bao gồm coroutine Kotlin và luồng Java; bạn có thể tìm thêm thông tin trong tài liệu về công việc không đồng bộ. Điều quan trọng cần lưu ý là không giống như các API tác vụ trong nền, công việc không đồng bộ không được đảm bảo sẽ hoàn tất nếu ứng dụng ngừng ở một giai đoạn vòng đời hợp lệ (ví dụ: nếu ứng dụng rời khỏi nền trước).
API lên lịch tác vụ
API lên lịch tác vụ là một lựa chọn linh hoạt hơn khi bạn cần thực hiện các tác vụ cần tiếp tục ngay cả khi người dùng rời khỏi ứng dụng. Trong hầu hết các trường hợp, lựa chọn tốt nhất để chạy các tác vụ trong nền là sử dụng WorkManager, mặc dù trong một số trường hợp, bạn có thể sử dụng API nền tảng JobScheduler
.
WorkManager là một thư viện mạnh mẽ cho phép bạn thiết lập các công việc đơn giản hoặc phức tạp theo nhu cầu. Bạn có thể sử dụng WorkManager để lên lịch chạy các tác vụ vào thời điểm cụ thể hoặc chỉ định điều kiện khi tác vụ sẽ chạy. Bạn thậm chí có thể thiết lập chuỗi tác vụ để mỗi tác vụ chạy theo lượt, chuyển kết quả của tác vụ đó đến tác vụ tiếp theo. Để hiểu rõ tất cả các tuỳ chọn có sẵn, hãy đọc danh sách tính năng WorkManager.
Sau đây là một số trường hợp phổ biến nhất đối với tác vụ trong nền:
- Định kỳ tìm nạp dữ liệu từ máy chủ
- Tìm nạp dữ liệu cảm biến (ví dụ: dữ liệu bộ đếm bước)
- Nhận dữ liệu vị trí định kỳ (bạn phải được cấp quyền
ACCESS_BACKGROUND_LOCATION
trên Android 10 trở lên) - Tải nội dung lên dựa trên điều kiện kích hoạt nội dung, chẳng hạn như ảnh do máy ảnh tạo
Dịch vụ trên nền trước
Dịch vụ trên nền trước cung cấp một cách hiệu quả để chạy các tác vụ ngay lập tức mà không bị gián đoạn. Tuy nhiên, các dịch vụ trên nền trước có thể gây ra tải nặng cho thiết bị và đôi khi ảnh hưởng đến quyền riêng tư và bảo mật. Vì những lý do này, hệ thống đặt ra nhiều hạn chế về cách thức và thời điểm ứng dụng có thể sử dụng dịch vụ trên nền trước. Ví dụ: dịch vụ trên nền trước phải được người dùng chú ý và trong hầu hết trường hợp, ứng dụng không thể chạy dịch vụ trên nền trước khi ứng dụng đang chạy ở chế độ nền. Để biết thêm thông tin, hãy xem tài liệu về dịch vụ trên nền trước.
Có hai phương thức để tạo dịch vụ trên nền trước. Bạn có thể khai báo Service
của riêng mình và chỉ định rằng dịch vụ đó là dịch vụ trên nền trước bằng cách gọi Service.startForeground()
. Ngoài ra, bạn có thể sử dụng WorkManager để tạo dịch vụ trên nền trước, như đã thảo luận trong phần hỗ trợ cho worker chạy trong thời gian dài.
Tuy nhiên, điều quan trọng cần biết là dịch vụ trên nền trước do WorkManager tạo phải tuân thủ tất cả các quy định hạn chế giống như mọi dịch vụ trên nền trước khác.
WorkManager chỉ cung cấp một số API tiện lợi để giúp bạn dễ dàng tạo dịch vụ trên nền trước.
API thay thế
Hệ thống cung cấp các API thay thế được thiết kế để hoạt động hiệu quả hơn cho các trường hợp sử dụng cụ thể hơn. Nếu có API thay thế cho trường hợp sử dụng của bạn, bạn nên sử dụng API đó thay vì dịch vụ trên nền trước vì API đó sẽ giúp ứng dụng của bạn hoạt động hiệu quả hơn. Tài liệu về các loại dịch vụ trên nền trước sẽ lưu ý khi có một API thay thế phù hợp để sử dụng thay vì một loại dịch vụ trên nền trước cụ thể.
Sau đây là một số trường hợp phổ biến nhất để sử dụng API thay thế:
- Sử dụng lệnh chuyển dữ liệu do người dùng yêu cầu để tải xuống hoặc tải lên các tệp có dung lượng lớn, thay vì tạo dịch vụ trên nền trước để đồng bộ hoá dữ liệu
- Sử dụng trình quản lý thiết bị đồng hành để ghép nối Bluetooth và chuyển dữ liệu, thay vì sử dụng dịch vụ trên nền trước của thiết bị đã kết nối
- Sử dụng chế độ hình trong hình để phát video, thay vì tạo dịch vụ phát nội dung đa phương tiện trên nền trước
Việc cần làm do người dùng khởi tạo
Nếu một ứng dụng cần thực hiện các tác vụ trong nền và thao tác do người dùng khởi tạo trong khi ứng dụng hiển thị, hãy trả lời các câu hỏi sau để tìm phương pháp phù hợp.
Tác vụ có cần tiếp tục chạy trong khi ứng dụng đang chạy ở chế độ nền không?
Nếu tác vụ không cần tiếp tục chạy trong khi ứng dụng ở chế độ nền, bạn nên sử dụng công việc không đồng bộ. Có một số tuỳ chọn để thực hiện công việc không đồng bộ. Điều quan trọng cần hiểu là tất cả các tuỳ chọn này đều ngừng hoạt động nếu ứng dụng chuyển sang chế độ nền. (Các hoạt động này cũng sẽ dừng nếu ứng dụng bị tắt.) Ví dụ: một ứng dụng mạng xã hội có thể muốn làm mới nguồn cấp dữ liệu nội dung, nhưng không cần phải hoàn tất thao tác nếu người dùng rời khỏi màn hình.
Người dùng có bị trải nghiệm tệ nếu tác vụ bị trì hoãn hoặc bị gián đoạn không?
Điều quan trọng là bạn phải cân nhắc xem trải nghiệm người dùng có bị ảnh hưởng nếu một tác vụ bị hoãn hoặc huỷ hay không. Ví dụ: nếu một ứng dụng cần cập nhật tài sản, người dùng có thể không nhận thấy thao tác này diễn ra ngay lập tức hay vào lúc nửa đêm khi thiết bị đang sạc. Trong trường hợp như vậy, bạn nên sử dụng các tuỳ chọn công việc trong nền.
Đó có phải là một việc cần làm ngắn và quan trọng không?
Nếu không thể trì hoãn và tác vụ sẽ hoàn tất nhanh chóng, bạn có thể sử dụng dịch vụ trên nền trước với loại shortService
. Các dịch vụ này dễ tạo hơn so với các dịch vụ trên nền trước khác và không yêu cầu nhiều quyền. Tuy nhiên, các dịch vụ ngắn phải hoàn tất trong vòng ba phút.
Có API thay thế nào chỉ dành cho mục đích này không?
Nếu người dùng không thấy tác vụ, thì giải pháp chính xác có thể là sử dụng dịch vụ trên nền trước. Các dịch vụ này chạy liên tục sau khi khởi động, vì vậy, đây là lựa chọn phù hợp khi việc gián đoạn tác vụ sẽ gây ra trải nghiệm người dùng không tốt. Ví dụ: một ứng dụng theo dõi bài tập thể dục có thể sử dụng cảm biến vị trí để cho phép người dùng ghi lại tuyến đường chạy bộ của họ trên bản đồ. Bạn không nên làm việc này với tuỳ chọn công việc ở chế độ nền, vì nếu tác vụ bị tạm dừng, tính năng theo dõi sẽ ngay lập tức dừng. Trong trường hợp như vậy, dịch vụ trên nền trước là phù hợp nhất.
Tuy nhiên, vì các dịch vụ trên nền trước có thể sử dụng nhiều tài nguyên thiết bị, nên hệ thống đặt ra nhiều quy định hạn chế về thời điểm và cách sử dụng các dịch vụ này. Trong nhiều trường hợp, thay vì sử dụng dịch vụ trên nền trước, bạn có thể sử dụng một API thay thế để xử lý công việc cho bạn mà ít gặp sự cố hơn. Ví dụ: nếu ứng dụng của bạn cần thực hiện một hành động khi người dùng đến một vị trí nhất định, thì lựa chọn tốt nhất là sử dụng API khoanh vùng địa lý thay vì theo dõi vị trí của người dùng bằng dịch vụ trên nền trước.
Việc cần làm để phản hồi một sự kiện
Đôi khi, ứng dụng cần thực hiện công việc ở chế độ nền để phản hồi một điều kiện kích hoạt, chẳng hạn như:
- Thông báo truyền tin
- Thông báo qua Giải pháp gửi thông báo qua đám mây của Firebase (FCM)
- Chuông báo do ứng dụng đặt
Đây có thể là một trình kích hoạt bên ngoài (chẳng hạn như thông báo FCM) hoặc có thể là phản hồi đối với chuông báo do chính ứng dụng đặt. Ví dụ: một trò chơi có thể nhận được thông báo FCM yêu cầu cập nhật một số thành phần.
Nếu bạn có thể chắc chắn rằng tác vụ sẽ hoàn tất trong vài giây, hãy sử dụng công việc không đồng bộ để thực hiện tác vụ. Hệ thống sẽ cho phép ứng dụng của bạn vài giây để thực hiện bất kỳ tác vụ nào như vậy, ngay cả khi ứng dụng của bạn đang chạy ở chế độ nền.
Nếu tác vụ mất nhiều thời gian hơn vài giây, bạn nên bắt đầu một dịch vụ trên nền trước để xử lý tác vụ đó. Trên thực tế, ngay cả khi ứng dụng của bạn đang chạy ở chế độ nền, ứng dụng đó vẫn có thể được phép bắt đầu một dịch vụ trên nền trước nếu người dùng kích hoạt tác vụ và tác vụ đó thuộc một trong các trường hợp miễn trừ được phê duyệt khỏi các quy định hạn chế về việc bắt đầu ở chế độ nền. Ví dụ: nếu một ứng dụng nhận được thông báo FCM có mức độ ưu tiên cao, thì ứng dụng đó được phép khởi động một dịch vụ trên nền trước ngay cả khi ứng dụng đang chạy ở chế độ nền.
Nếu tác vụ mất nhiều thời gian hơn vài giây, hãy sử dụng API lập lịch biểu tác vụ.