Hình 10-52.

Ở đây, trình quản lý hoạt động, ở phía bên

trái, đã tạo một phiên bản ActivityRecord nội bộ trong
quy trình của nó để theo dõi hoạt động

Nếu bây giờ người dùng chuyển khỏi ứng dụng email
(không thoát khỏi ứng dụng) và khởi chạy ứng dụng máy
ảnh để chụp ảnh, chúng ta sẽ ở trạng thái như trong Hình
10-53.

Nếu ứng dụng máy ảnh yêu cầu nhiều RAM, hệ thống có
thể loại bỏ quy trình email để giải phóng RAM, như
trong Hình 10-54. Bản ghi hoạt động của quy trình email
vẫn được lưu trữ an toàn trong quy trình máy chủ hệ
thống. Quy trình máy chủ hệ thống lưu trữ tất cả các dịch
vụ hệ thống cốt lõi của Android, nên nó phải luôn chạy
và trạng thái được lưu ở đó sẽ tồn tại miễn là cần thiết.

Thực hiện tùy chọn chia sẻ đó trong khi ở trạng thái hoạt
động như trong Hình 10-54 sẽ dẫn đến trạng thái mới
trong Hình 10-55.

Hình 10-56 cho thấy trạng thái mới của hệ thống sau khi
đưa tác vụ email trở lại nền trước. MailMainActivity trở
thành hoạt động nền trước, nhưng không có trường hợp
nào hoạt động này đang chạy trong quy trình của ứng
dụng.
---------------------------------------------------------------------
----------------
Một dịch vụ có hai bản sắc riêng biệt:
Nó có thể là một hoạt động nền chạy dài độc lập.
Nó có thể đóng vai trò là điểm kết nối cho các ứng dụng
khác hoặc hệ thống để thực hiện tương tác phong phú với
ứng dụng

Hình 10-57 Trình quản lý hoạt động đã tạo một

ServiceRecord để theo dõi dịch vụ, Trong khi ở trạng
thái này, dịch vụ hoàn toàn hoạt động và tự do làm
những gì nó muốn.

Hình 10-58. Giao diện để kiểm soát khoảng thời gian

đồng bộ của dịch vụ đồng bộ.

10-59:
Quá trình ràng buộc ứng dụng khách với dịch vụ trên
Android sẽ diễn ra như sau:

1Ứng dụng khách yêu cầu ràng buộc với dịch vụ thông
qua trình quản lý hoạt động.
2Nếu dịch vụ chưa được tạo, trình quản lý hoạt động sẽ
tạo nó trong quy trình của ứng dụng dịch vụ.
3Dịch vụ trả về một đối tượng IBinder cho giao diện của
nó thông qua trình quản lý hoạt động và IBinder này
được giữ trong ServiceRecord của dịch vụ.
4Trình quản lý hoạt động trả về IBinder của dịch vụ cho
ứng dụng khách.
5Ứng dụng khách có thể sử dụng IBinder của dịch vụ để
gọi các phương thức trên giao diện của nó để tương tác
với dịch vụ.
---------------------------------------------------------
Người nhận là người nhận các sự kiện (thường là bên
ngoài) xảy ra,
Hình 10-60 minh họa cách trình quản lý hoạt động xử lý
chương trình phát sóng như sau:

1Chương trình phát sóng yêu cầu trình quản lý gói cung
cấp danh sách tất cả người nhận quan tâm đến sự kiện.
2Danh sách này được đặt trong Bản ghi phát sóng đại
diện cho chương trình phát sóng đó.
3Trình quản lý hoạt động tiếp tục từng bước trong danh
sách, yêu cầu mỗi quy trình của ứng dụng được liên kết
tạo và thực thi lớp người nhận thích hợp.

Hình 10-61 minh họa cách hệ thống xử lý ví dụ truy vấn

của chúng ta như sau:

1Ứng dụng gọi ContentResolver.query để bắt đầu thao

tác truy vấn.
2Quyền URI được cấp cho trình quản lý hoạt động để nó
tìm thấy nhà cung cấp nội dung phù hợp thông qua trình
quản lý gói.
3Nếu nhà cung cấp nội dung chưa chạy, nó sẽ được tạo.
4Sau khi được tạo, nhà cung cấp nội dung trả lại IBinder
triển khai giao diện IContentProvider của hệ thống cho
trình quản lý hoạt động.
5IBinder của nhà cung cấp nội dung được trả lại cho
ContentResolver.
6Giờ đây, trình phân giải nội dung có thể hoàn thành
thao tác truy vấn ban đầu bằng cách gọi phương thức
thích hợp trên giao diện AIDL và trả về kết quả Con trỏ.

Hình 10-62 minh họa các giá trị UID phổ biến trên
Android như sau:
1UID dưới 10000 là các chỉ định cố định trong hệ thống
cho phần cứng chuyên dụng hoặc các triển khai cụ thể
khác.
2Phạm vi UID 10000-19999 là các UID được gán động
cho các ứng dụng khi chúng được cài đặt trên hệ thống.
3Phạm vi UID bắt đầu từ 100000 được sử dụng để triển
khai mô hình nhiều người dùng truyền thống cho
Android.

Hình 10-63 minh họa cách ứng dụng email của chúng ta
có thể sử dụng quyền để truy cập ảnh trong ứng dụng
máy ảnh như sau:

1Ứng dụng máy ảnh đã liên kết quyền ĐỌC HÌNH ẢNH
với ảnh của nó, nói rằng bất kỳ ứng dụng nào có quyền
đó đều có thể truy cập dữ liệu ảnh của nó.
2Ứng dụng email tuyên bố trong tệp kê khai rằng nó yêu
cầu quyền ĐỌC HÌNH ẢNH.
3Ứng dụng email có thể truy cập URI do máy ảnh sở
hữu, chẳng hạn như content://pics/1.
4Khi nhận được yêu cầu cho URI này, nhà cung cấp nội
dung của ứng dụng máy ảnh sẽ hỏi người quản lý gói
xem người gọi có giữ quyền cần thiết hay không.
5Nếu đúng như vậy, cuộc gọi thành công và dữ liệu thích
hợp được trả về ứng dụng.

Hình 10-64 minh họa việc xảy ra khi một ứng dụng
không có quyền cần thiết cho một hoạt động mà nó đang
thực hiện như sau:

1Ứng dụng trình duyệt đang cố gắng truy cập trực tiếp
vào ảnh của người dùng, nhưng quyền duy nhất mà nó
nắm giữ là quyền đối với các hoạt động mạng qua
Internet.
2Khi trình duyệt yêu cầu truy cập trực tiếp vào ảnh,
PicturesProvider được trình quản lý gói thông báo rằng
quy trình gọi không có quyền ĐỌC HÌNH ẢNH cần
thiết.
3Kết quả là ném một SecurityException trở lại cho trình
duyệt.

Hình 10-65 minh họa việc sử dụng URI trong ví dụ gửi

email như sau:

1Ứng dụng máy ảnh đã tạo một nhiệm vụ có ý định chia

sẻ một trong những hình ảnh của nó, content://pics/1.
2Khi khởi động ứng dụng soạn email, thao tác này còn
thêm một mục vào danh sách “URI được cấp”, lưu ý rằng
ComposeActivity mới hiện có quyền truy cập vào URI
này.
3Khi ComposeActivity tìm cách mở và đọc dữ liệu từ
URI, nó đã được cung cấp.
4PicturesProvider của ứng dụng máy ảnh sở hữu dữ liệu
đằng sau URI có thể hỏi trình quản lý hoạt động xem ứng
dụng email đang gọi có quyền truy cập vào dữ liệu hay
không.
5Nếu có quyền truy cập, ảnh được trả về và có thể được
sử dụng trong email.

Hình 10-66 minh họa luồng mới này. Nó gần giống với
Hình 10-65, điểm khác biệt duy nhất là cách sắp xếp hoạt
động của hai ứng dụng, với ứng dụng email bắt đầu hoạt
động chọn ảnh thích hợp trong ứng dụng máy ảnh. Khi
một hình ảnh được chọn, URI của nó được trả về ứng
dụng email và tại thời điểm này, hoạt động cấp URI của
chúng tôi được trình quản lý hoạt động nắm bắt

Quy trình bắt đầu một hoạt động mới trong một quy trình
mới được thể hiện trong Hình 10-67 như sau:
1Một quy trình hiện có gọi trình quản lý hoạt động để mô
tả hoạt động mới mà nó muốn bắt đầu.
2Trình quản lý hoạt động yêu cầu trình quản lý gói giải
quyết ý định thành phần rõ ràng.
3Trình quản lý hoạt động xác định UID của ứng dụng và
yêu cầu hợp tử cung cấp UID thích hợp cho quy trình
mới.
4Hợp tử tạo ra một quy trình mới là bản sao của chính
nó, xóa các đặc quyền và đặt UID của nó một cách thích
hợp cho ứng dụng, rồi kết thúc quá trình khởi tạo.
5Quy trình mới gọi lại trình quản lý hoạt động để hỏi
"Tôi phải làm gì bây giờ?"
6Trình quản lý hoạt động trả về thông tin đầy đủ về ứng
dụng mà nó đang khởi động.
7Quy trình mới tải mã cho ứng dụng đang chạy.
8Trình quản lý hoạt động gửi tới quy trình mới mọi hoạt
động đang chờ xử lý.
9Tiến trình mới nhận lệnh để bắt đầu một thao tác, khởi
tạo lớp Java thích hợp và thực thi nó.

Hình 10-68 hiển thị các danh mục chính, với danh mục
quan trọng nhất ở vị trí đầu tiên. Cột cuối cùng hiển thị
một giá trị oom adj điển hình được gán cho các quy trình
thuộc loại này.

Hình 10-69 minh họa một trạng thái điển hình của các
quy trình với phụ thuộc giữa chúng, ví dụ là ứng dụng
email phụ thuộc vào ứng dụng máy ảnh để tải tệp đính
kèm.

Nếu trạng thái của Hình 10-69 thay đổi để ứng dụng
email tải xong tệp đính kèm và không còn sử dụng trình
cung cấp nội dung camera nữa, thì trạng thái quá trình sẽ
thay đổi như Hình 10-70. Ứng dụng máy ảnh không còn
cần thiết và đã bị loại bỏ khỏi tầm quan trọng của nền
trước, được lưu trong bộ nhớ cache. Việc lưu máy ảnh
vào bộ nhớ cache cũng đẩy ứng dụng bản đồ cũ xuống
một bậc trong danh sách LRU được lưu trong bộ nhớ
cache.