START_STICKY và START_NOT_STICKY

Sự khác biệt giữa START_STICKYvà START_NOT_STICKYtrong khi thực hiện các dịch vụ trong Android là gì? Bất cứ ai có thể chỉ ra một số ví dụ tiêu chuẩn ..?

Cả hai mã chỉ có liên quan khi điện thoại hết bộ nhớ và giết dịch vụ trước khi hoàn thành thực thi. START_STICKYyêu cầu HĐH tạo lại dịch vụ sau khi nó có đủ bộ nhớ và gọi onStartCommand()lại với mục đích không. START_NOT_STICKYnói với hệ điều hành không bận tâm tái tạo dịch vụ một lần nữa. Ngoài ra còn có một mã thứ ba START_REDELIVER_INTENTyêu cầu HĐH tạo lại dịch vụ và phân phối lại cùng một mục đích onStartCommand().

Bài viết này của Dianne Hackborn đã giải thích nền tảng của điều này tốt hơn rất nhiều so với tài liệu chính thức.

Nguồn: http://android-developers.blogspot.com.au/2010/02/service-api-changes-starting-with.html

Phần quan trọng ở đây là một mã kết quả mới được hàm trả về, cho hệ thống biết nó nên làm gì với dịch vụ nếu quá trình của nó bị hủy trong khi nó đang chạy:

START_STICKY về cơ bản giống như hành vi trước đó, nơi dịch vụ được "bắt đầu" và sau đó sẽ được hệ thống khởi động lại. Sự khác biệt duy nhất so với các phiên bản trước của nền tảng là nếu nó được khởi động lại vì quá trình của nó bị hủy, onStartCommand () sẽ được gọi trong phiên bản tiếp theo của dịch vụ với Intent null thay vì không được gọi. Các dịch vụ sử dụng chế độ này phải luôn kiểm tra trường hợp này và xử lý thích hợp.

START_NOT_STICKY nói rằng, sau khi trở về từ onStartCreated (), nếu quá trình bị hủy mà không có lệnh khởi động còn lại để phân phối, thì dịch vụ sẽ bị dừng thay vì khởi động lại. Điều này có ý nghĩa hơn nhiều đối với các dịch vụ được dự định chỉ chạy trong khi thực hiện các lệnh được gửi cho chúng. Ví dụ: một dịch vụ có thể được bắt đầu cứ sau 15 phút từ báo thức đến thăm dò một số trạng thái mạng. Nếu nó bị giết trong khi thực hiện công việc đó, tốt nhất là cứ để nó dừng lại và bắt đầu vào lần báo thức tiếp theo.

BẮT ĐẦU tại điểm mà hệ thống bỏ cuộc). Điều này hữu ích cho các dịch vụ đang nhận lệnh công việc phải làm và muốn đảm bảo rằng cuối cùng chúng sẽ hoàn thành công việc cho mỗi lệnh được gửi.

KISS trả lời

Sự khác biệt:

START_STICKY

hệ thống sẽ cố gắng tạo lại dịch vụ của bạn sau khi nó bị giết

START_NOT_STICKY

hệ thống sẽ không cố gắng tạo lại dịch vụ của bạn sau khi nó bị giết

Ví dụ tiêu chuẩn:

@Override
public int onStartCommand(Intent intent, int flags, int startId) {
    return START_STICKY;
}

Các tài liệu cho START_STICKYvà START_NOT_STICKYkhá đơn giản.

BẮT ĐẦU:

Nếu quy trình của dịch vụ này bị hủy trong khi nó bắt đầu (sau khi trở về onStartCommand(Intent, int, int)), sau đó để nó ở trạng thái bắt đầu nhưng không giữ lại ý định đã giao này. Sau đó, hệ thống sẽ cố gắng tạo lại dịch vụ. Vì nó ở trạng thái bắt đầu , nó sẽ đảm bảo gọi onStartCommand(Intent, int, int) sau khi tạo phiên bản dịch vụ mới, nếu không có bất kỳ lệnh bắt đầu đang chờ xử lý nào được gửi đến dịch vụ, nó sẽ được gọi với một đối tượng có mục đích null, vì vậy bạn phải cẩn thận kiểm tra điều này.

Chế độ này có ý nghĩa đối với những thứ sẽ được khởi động và dừng rõ ràng để chạy trong khoảng thời gian tùy ý, chẳng hạn như một dịch vụ thực hiện phát lại nhạc nền.

Ví dụ: Mẫu dịch vụ địa phương

START_NOT_STICKY:

Nếu quy trình của dịch vụ này bị hủy trong khi nó bắt đầu (sau khi trở về onStartCommand(Intent, int, int))và không có ý định bắt đầu mới nào để cung cấp cho nó, thì hãy đưa dịch vụ ra khỏi trạng thái bắt đầu và không tạo lại cho đến khi có cuộc gọi rõ ràng trong tương lai Context.startService(Intent). sẽ không nhận được onStartCommand(Intent, int, int)cuộc gọi với nullÝ định vì nó sẽ không được bắt đầu lại nếu không có Ý định chờ xử lý để phân phối.

Chế độ này có ý nghĩa đối với những thứ muốn thực hiện một số công việc do được bắt đầu, nhưng có thể dừng lại khi chịu áp lực bộ nhớ và sẽ tự khởi động lại sau để thực hiện nhiều công việc hơn. Một ví dụ về dịch vụ như vậy sẽ là một cuộc thăm dò dữ liệu từ máy chủ: nó có thể lên lịch báo động để thăm dò ý kiến ​​mỗi Nphút bằng cách báo thức bắt đầu dịch vụ của mình. Khi nó onStartCommand(Intent, int, int)được gọi từ báo thức, nó sẽ lập lịch báo thức mới trong N phút sau và tạo ra một luồng để thực hiện kết nối mạng. Nếu quy trình của nó bị hủy trong khi thực hiện kiểm tra đó, dịch vụ sẽ không được khởi động lại cho đến khi báo thức kêu.

Ví dụ: ServiceStartArgument.java