Hướng dẫn về cấu trúc ứng dụng | Android Developers

Trải nghiệm người dùng trong ứng dụng di động

Một ứng dụng Android thường thì chứa nhiều thành phần ứng dụng ( component ), gồm có hoạt động giải trí ( activity ), mảnh ( fragment ), dịch vụ ( service ), nhà cung ứng nội dung ( content provider ) và broadcast receiver. Bạn khai báo hầu hết những thành phần ứng dụng này trong tệp kê khai ứng dụng. Sau đó, Hệ điều hành Android sẽ sử dụng tệp này để quyết định hành động cách tích hợp ứng dụng của bạn vào thưởng thức người dùng tổng thể và toàn diện của thiết bị. Vì một ứng dụng Android thường thì hoàn toàn có thể chứa nhiều thành phần và người dùng thường tương tác với nhiều ứng dụng trong một khoảng chừng thời hạn ngắn, những ứng dụng cần phải kiểm soát và điều chỉnh cho tương thích với nhiều loại tiến trình việc làm và thao tác do người dùng thực thi .

Xin lưu ý rằng thiết bị di động cũng bị hạn chế về tài nguyên. Do đó, bất cứ lúc nào, hệ điều hành cũng có thể xoá một số quy trình ứng dụng để tạo không gian cho các quy trình mới.

Do những điều kiện kèm theo của môi trường tự nhiên này, bạn hoàn toàn có thể chạy những thành phần ứng dụng một cách riêng không liên quan gì đến nhau và không theo thứ tự, đồng thời hệ điều hành hoặc người dùng hoàn toàn có thể huỷ bỏ những thành phần đó bất kể khi nào. Vì những sự kiện này không thuộc quyền trấn áp của bạn nên bạn không nên tàng trữ hoặc ghi nhớ bất kỳ dữ liệu hoặc trạng thái ứng dụng nào trong những thành phần ứng dụng và những thành phần ứng dụng không được phụ thuộc vào lẫn nhau .

Nguyên tắc cấu trúc phổ biến

Nếu không nên sử dụng những thành phần ứng dụng để tàng trữ tài liệu và trạng thái của ứng dụng, vậy bạn nên phong cách thiết kế ứng dụng như thế nào ?
Khi những ứng dụng Android tăng trưởng về kích cỡ, quan trọng là bạn phải xác lập một cấu trúc được cho phép ứng dụng lan rộng ra quy mô, tăng tính can đảm và mạnh mẽ của ứng dụng và làm cho ứng dụng thuận tiện kiểm thử hơn .
Cấu trúc ứng dụng xác lập ranh giới giữa những phần của ứng dụng và nghĩa vụ và trách nhiệm từng phần nên có. Để phân phối những nhu yếu được đề cập ở trên, bạn nên phong cách thiết kế cấu trúc ứng dụng theo một vài nguyên tắc đơn cử .

Tách biệt các mối lo ngại

Nguyên tắc quan trọng nhất cần tuân thủ là tách biệt
các mối lo ngại.
Có một lỗi thường gặp là viết tất cả mã trong
Activity hoặc
Fragment. Các lớp dựa trên giao diện người dùng này chỉ
nên chứa logic xử lý các tương tác với giao diện người dùng và hệ điều hành. Bằng cách giữ
các lớp này tinh gọn nhất có thể, bạn có thể tránh nhiều vấn đề liên quan đến vòng đời của thành phần và cải thiện khả năng kiểm thử của các lớp này.

Xin lưu ý rằng bạn không sở hữu cách triển khai Activity và Fragment;
thay vào đó, đây chỉ là các lớp keo đại diện cho hợp đồng giữa
hệ điều hành Android và ứng dụng. Hệ điều hành có thể phá huỷ chúng bất kỳ lúc nào dựa trên mức độ tương tác
của người dùng hoặc do các điều kiện hệ thống như thiếu bộ nhớ. Để mang lại
trải nghiệm người dùng vừa ý và trải nghiệm bảo trì ứng dụng dễ quản lý hơn,
tốt nhất là bạn nên giảm thiểu phần phụ thuộc vào những trải nghiệm đó.

Điều khiển giao diện người dùng qua các mô hình dữ liệu

Một nguyên tắc quan trọng khác là bạn nên điều khiển và tinh chỉnh giao diện người dùng qua những quy mô tài liệu, tốt nhất là những quy mô liên tục. Mô hình tài liệu đại diện thay mặt cho tài liệu của một ứng dụng. Chúng độc lập với những thành phần giao diện người dùng và những thành phần khác trong ứng dụng. Có nghĩa là những tệp đó không gắn liền với vòng đời thành phần ứng dụng và giao diện người dùng, nhưng vẫn bị huỷ khi hệ điều hành quyết định hành động xoá quy trình tiến độ này của ứng dụng khỏi bộ nhớ .
Các quy mô liên tục rất tương thích vì những nguyên do sau đây :

• Người dùng sẽ không bị mất tài liệu nếu hệ điều hành Android huỷ bỏ ứng dụng của bạn để giải phóng tài nguyên .
• Ứng dụng liên tục hoạt động giải trí trong những trường hợp khi liên kết mạng không không thay đổi hoặc không hoạt động giải trí .

Nếu cấu trúc ứng dụng dựa trên những lớp quy mô tài liệu, bạn sẽ giúp ứng dụng trở nên dễ kiểm thử và can đảm và mạnh mẽ hơn .

Một nguồn dữ liệu đáng tin cậy duy nhất

Khi xác lập một loại tài liệu mới trong ứng dụng, bạn nên chỉ định một Nguồn đúng chuẩn duy nhất ( SSOT ) cho nó. SSOT là chủ sở hữu của tài liệu đó, và chỉ SSOT mới hoàn toàn có thể sửa đổi hoặc biến hóa tài liệu đó. Để đạt được điều này, SSOT hiển thị tài liệu bằng cách sử dụng một loại không hề đổi khác, và để hoàn toàn có thể sửa đổi tài liệu, SSOT sẽ hiển thị những hàm hoặc nhận những sự kiện mà loại khác hoàn toàn có thể gọi .
Mẫu này mang lại khá nhiều quyền lợi :

• Nó tập trung tất cả các thay đổi đối với một loại dữ liệu cụ thể ở cùng một nơi.
• Nó cũng bảo vệ dữ liệu để các loại khác không thể can thiệp vào.
• Nó giúp cho các thay đổi đối với dữ liệu dễ dàng theo dõi hơn. Từ đó dễ phát hiện lỗi hơn.

Trong một ứng dụng ưu tiên ngoại tuyến, nguồn đáng an toàn và đáng tin cậy cho tài liệu ứng dụng thường là cơ sở tài liệu. Trong một số ít trường hợp khác, nguồn đáng đáng tin cậy hoàn toàn có thể là ViewModel, hoặc thậm chí còn là giao diện người dùng .

Luồng dữ liệu một chiều

Nguyên tắc về nguồn đáng tin duy nhất thường dùng trong hướng dẫn của chúng tôi với mẫu Luồng dữ liệu một chiều (UDF). Trong UDF, trạng thái chỉ chạy theo một hướng. Các sự kiện sửa đổi luồng dữ liệu theo hướng ngược lại.

Trong Android, trạng thái hoặc tài liệu thường chuyển từ những kiểu hệ phân cấp có khoanh vùng phạm vi cao hơn sang khoanh vùng phạm vi thấp hơn. Các sự kiện thường được kích hoạt từ loại có khoanh vùng phạm vi thấp hơn cho đến khi chúng đạt đến SSOT cho loại tài liệu tương ứng. Chẳng hạn như tài liệu ứng dụng thường truyền từ nguồn tài liệu tới giao diện người dùng. Các sự kiện của người dùng, ví dụ điển hình như những lượt nhấn nút chuyển từ giao diện người dùng đến SSOT, nơi tài liệu ứng dụng được sửa đổi và hiển thị theo kiểu không bao giờ thay đổi .
Mẫu này bảo vệ tính đồng nhất của tài liệu tốt hơn, ít xảy ra lỗi hơn, thuận tiện hơn khi gỡ lỗi và mang lại mọi quyền lợi của mẫu SSOT .

Cấu trúc ứng dụng được đề xuất

Phần này trình diễn cách cấu trúc ứng dụng của bạn theo những giải pháp hay nhất được yêu cầu .
Lưu ý:Chúng tôi hoàn toàn có thể vận dụng những mục yêu cầu và chiêu thức hay nhất có trong trang này cho nhiều dạng ứng dụng để được cho phép lan rộng ra quy mô, cải tổ chất lượng và năng lực hiển thị can đảm và mạnh mẽ, đồng thời giúp việc kiểm thử thuận tiện hơn. Tuy nhiên, bạn nên coi những nguyên tắc này là hướng dẫn và kiểm soát và điều chỉnh cho tương thích với nhu yếu của mình nếu cần .
Hãy xem xét những nguyên tắc cấu trúc thông dụng đã đề cập trong phần trước, mỗi ứng dụng phải có tối thiểu hai lớp :

• Lớp giao diện người dùng hiển thị dữ liệu ứng dụng trên màn hình.
• Lớp dữ liệu chứa logic nghiệp vụ của ứng dụng và hiển thị dữ liệu ứng dụng.

Bạn hoàn toàn có thể thêm một lớp bổ trợ có tên là lớp miền ( domain layer ) để đơn giản hoá và sử dụng lại những lượt tương tác giữa giao diện người dùng và những lớp tài liệu .

Hình 1. Sơ đồ về một cấu trúc ứng dụng thông thường.

Lưu ý:Các mũi tên trong sơ đồ trong hướng dẫn này biểu lộ những phần phụ thuộc giữa những lớp. Ví dụ : lớp miền phụ thuộc vào vào những lớp tài liệu .

Lớp giao diện người dùng

Vai trò của lớp giao diện người dùng ( hoặc lớp bản trình diễn ) là hiển thị tài liệu ứng dụng trên màn hình hiển thị. Bất cứ khi nào tài liệu đổi khác, do sự tương tác của người dùng ( ví dụ điển hình như nhấn một nút ) hoặc nguồn vào bên ngoài ( ví dụ điển hình như phản hồi mạng ), giao diện người dùng sẽ update để phản ánh những đổi khác đó .
Lớp giao diện người dùng gồm hai nội dung :

• Các thành phần trên giao diện người dùng hiển thị dữ liệu trên màn hình. Bạn tạo các phần tử này bằng cách sử dụng các hàm View (Thành phần hiển thị) hoặc Jetpack Compose.
• Các chủ thể trạng thái (chẳng hạn như các lớp ViewModel) chứa dữ liệu, hiển thị thông tin đó tới giao diện người dùng và xử lý logic.

Hình 2. Vai trò của lớp giao diện người dùng trong cấu trúc ứng dụng.

Để tìm hiểu và khám phá thêm về lớp này, hãy xem trang lớp giao diện người dùng .

Lớp dữ liệu

Lớp tài liệu của ứng dụng chứa logic nhiệm vụ. Logic nhiệm vụ là yếu tố tạo ra giá trị cho ứng dụng — logic này được tạo ra từ những quy tắc xác lập cách ứng dụng tạo, tàng trữ và đổi khác tài liệu .

Lớp dữ liệu được tạo thành từ các kho lưu trữ, mỗi kho dữ liệu có thể chứa từ 0 đến nhiều nguồn dữ liệu. Bạn nên tạo một lớp kho lưu trữ cho từng loại dữ liệu
khác nhau mà bạn xử lý trong ứng dụng. Ví dụ: bạn có thể tạo một lớp MoviesRepository
cho dữ liệu liên quan đến phim hoặc một lớp PaymentsRepository cho dữ liệu
liên quan đến các khoản thanh toán.

Hình 3. Vai trò của lớp dữ liệu trong cấu trúc ứng dụng.

Các lớp kho lưu trữ chịu trách nhiệm về:

• Hiển thị dữ liệu cho phần còn lại của ứng dụng.
• Tập trung các thay đổi vào dữ liệu.
• Giải quyết xung đột giữa nhiều nguồn dữ liệu.
• Tóm tắt các nguồn dữ liệu từ phần còn lại của ứng dụng.
• Chứa logic nghiệp vụ.

Mỗi lớp nguồn tài liệu nên có nghĩa vụ và trách nhiệm thao tác với chỉ một nguồn tài liệu duy nhất, hoàn toàn có thể là một tệp, nguồn mạng hoặc cơ sở tài liệu cục bộ. Các lớp nguồn tài liệu là cầu nối giữa ứng dụng và mạng lưới hệ thống để thao tác dữ liệu .
Để tìm hiểu và khám phá thêm về lớp này, hãy xem trang về lớp tài liệu .

Lớp miền

Lớp miền là lớp không bắt buộc nằm giữa giao diện người dùng và những lớp tài liệu .
Lớp miền chịu nghĩa vụ và trách nhiệm về việc tổng hợp những logic nhiệm vụ phức tạp, hoặc logic nhiệm vụ đơn thuần được sử dụng lại trong nhiều ViewModel. Lớp này là không bắt buộc vì không phải ứng dụng nào cũng có những nhu yếu này. Bạn chỉ nên sử dụng thuộc tính này khi cần, ví dụ : để giải quyết và xử lý độ phức tạp hoặc yêu thích năng lực tái sử dụng .

Hình 4. Vai trò của lớp miền trong cấu trúc ứng dụng.

Các lớp này thường được gọi là trường hợp sử dụng (use case) hoặctrình tương tác (interactor). Mỗi trường hợp sử dụng phải có trách nhiệm đối với một chức năng. Ví dụ: ứng dụng có thể có một lớp GetTimeZoneUseCase nếu nhiều ViewModel dựa vào múi giờ
để hiển thị thông báo thích hợp trên màn hình.

Để khám phá thêm về lớp này, hãy xem trang về lớp miền .

Quản lý các phần phụ thuộc giữa các thành phần

Các lớp trong ứng dụng nhờ vào vào những lớp khác để hoàn toàn có thể hoạt động giải trí đúng cách. Bạn hoàn toàn có thể sử dụng một trong những mẫu phong cách thiết kế sau để tích lũy những phần phụ thuộc của một lớp đơn cử :

• Chèn phần phụ thuộc (DI): Chèn phần phụ thuộc cho phép các lớp xác định các phần phụ thuộc mà không cần tạo chúng Trong thời gian chạy, một lớp khác chịu trách nhiệm cung cấp các phần phụ thuộc này.
• Công cụ định vị dịch vụ:
  Mẫu bộ định vị dịch vụ cung cấp một sổ đăng ký mà các lớp có thể lấy
  phần phụ thuộc thay vì tạo các phần phụ thuộc đó.

Các mẫu này được cho phép bạn lan rộng ra mã vì chúng phân phối những mẫu rõ ràng để quản trị những phần phụ thuộc mà không cần sao chép mã hoặc thêm độ phức tạp. Hơn nữa, những mẫu này được cho phép bạn nhanh gọn quy đổi giữa tiến hành bản chính thức và kiểm thử .

Bạn nên làm theo các mẫu chèn phụ thuộc và sử dụng thư viện Hilt trong các ứng dụng Android. Hilt
tự động tạo các đối tượng bằng cách qua cây phụ thuộc, cung cấp
đảm bảo thời gian biên dịch các phần phụ thuộc và tạo vùng chứa phần phụ thuộc cho
các lớp khung Android.

Các phương pháp chung hay nhất

Lập trình là một trường phát minh sáng tạo và việc tạo ứng dụng Android cũng không phải là ngoại lệ. Có nhiều cách để xử lý một yếu tố ; bạn hoàn toàn có thể tiếp xúc tài liệu giữa nhiều hoạt động giải trí hoặc mảnh, truy xuất tài liệu từ xa và duy trì tài liệu đó cục bộ cho chính sách ngoại tuyến hoặc giải quyết và xử lý bất kể trường hợp phổ cập nào khác mà những ứng dụng không thông thường gặp phải .
Mặc dù những yêu cầu sau đây là không bắt buộc, nhưng trong hầu hết trường hợp, việc làm theo những đề xuất kiến nghị này giúp cơ sở mã của bạn can đảm và mạnh mẽ hơn, hoàn toàn có thể kiểm thử và duy trì được trong thời hạn dài :

Không lưu trữ dữ liệu trong các thành phần của ứng dụng.

Tránh chỉ định những điểm truy vấn của ứng dụng – ví dụ điển hình như những hoạt động giải trí, dịch vụ và trình thu phát sóng – dưới dạng nguồn tài liệu. Thay vào đó, những mã này chỉ nên phối hợp với những thành phần khác để truy xuất tập hợp con tài liệu có tương quan đến điểm truy vấn đó. Mỗi thành phần ứng dụng thường khá thời gian ngắn, tuỳ thuộc vào mức độ tương tác của người dùng với thiết bị cũng như thực trạng toàn diện và tổng thể của mạng lưới hệ thống hiện tại .

Giảm phần phụ thuộc trên lớp Android.

Các thành phần ứng dụng chỉ nên là các lớp dựa vào API SDK
khung Android, chẳng hạn như Context hoặc
Toast. Việc tách các lớp khác trong ứng dụng
khỏi các lớp đó sẽ giúp khả năng kiểm thử và giảm
mối liên kết
trong ứng dụng của bạn.

Xác định ranh giới trách nhiệm rõ ràng giữa các mô-đun khác nhau trong
ứng dụng.

Ví dụ : đừng phân tán mã tải tài liệu từ mạng trên nhiều lớp hoặc gói trong cơ sở mã. Tương tự như vậy, không xác lập nhiều nghĩa vụ và trách nhiệm không tương quan — ví dụ điển hình như việc lưu dữ liệu vào bộ nhớ đệm và link tài liệu — trong cùng một lớp. Việc làm theo cấu trúc ứng dụng đề xuất kiến nghị sẽ giúp bạn làm được điều này .

Hiển thị càng ít càng tốt từ mỗi mô-đun.

Ví dụ : không nên tạo một lối tắt để hiển thị thông tin cụ thể về hoạt động giải trí tiến hành nội bộ từ một mô-đun. Bạn hoàn toàn có thể tiết kiệm ngân sách và chi phí một chút ít thời hạn trong thời gian ngắn, nhưng sau đó có năng lực bạn sẽ phải chịu những khoản nợ kỹ thuật nhiều lần khi cơ sở mã của bạn tăng trưởng .

Tập trung vào cốt lõi độc đáo của ứng dụng để ứng dụng trở nên nổi bật so với các ứng dụng khác.

Đừng mất công thay đổi bằng cách viết lại mã nguyên mẫu nhiều lần. Thay vào đó, hãy tập trung chuyên sâu thời hạn và sức lực lao động vào những điều khiến ứng dụng của bạn trở nên độc lạ, đồng thời để những thư viện Jetpack và những thư viện yêu cầu khác giải quyết và xử lý mã nguyên mẫu lặp lại .

Cân nhắc cách tách biệt từng phần trong ứng dụng với trạng thái kiểm thử.

Ví dụ : khi có một API xác lập rõ để tìm nạp tài liệu từ mạng, bạn hoàn toàn có thể thuận tiện kiểm tra mô-đun duy trì tài liệu đó trong cơ sở tài liệu trên thiết bị. Thay vào đó, nếu bạn phối hợp logic từ hai mô-đun này ở cùng một nơi hoặc phân phối mã mạng của bạn trên hàng loạt cơ sở mã, việc thử nghiệm hiệu suất cao sẽ trở nên khó khăn vất vả hơn nhiều – nếu không muốn nói là không hề .

Các loại dữ liệu chịu trách nhiệm về chính sách đồng thời chúng.

Nếu một loại tài liệu đang triển khai việc làm chặn lâu dài hơn, thì nó phải chịu nghĩa vụ và trách nhiệm vận động và di chuyển phần giám sát đó sang luồng tương thích. Loại đơn cử đó biết kiểu thống kê giám sát mà nó đang thực thi và được thực thi trong luồng nào. Các loại phải bảo đảm an toàn cho luồng chính ( main-safe ), nghĩa là bảo đảm an toàn khi gọi từ luồng chính mà không bị chặn .

Duy trì càng nhiều dữ liệu mới và phù hợp càng tốt.

Nhờ đó, người dùng có thể sử dụng chức năng của ứng dụng ngay cả khi thiết bị của họ đang ở
chế độ ngoại tuyến. Hãy nhớ là không phải tất cả người dùng đều thích sự kết nối liên tục, tốc độ cao và ngay cả khi họ thích, họ vẫn có thể nhận được kết nối kém ở những nơi đông đúc.

Lợi ích của Cấu trúc

Việc tiến hành một Cấu trúc tốt trong ứng dụng mang lại rất nhiều quyền lợi cho nhóm dự án Bất Động Sản và nhóm kỹ thuật :

• Cải thiện khả năng bảo trì, chất lượng và tính mạnh mẽ của ứng dụng nói chung.
• Cho phép ứng dụng mở rộng quy mô. Nhiều người và nhiều nhóm hơn có thể đóng góp cho cùng một cơ sở mã với ít xung đột mã.
• Điều này hữu ích cho việc tích hợp. Khi Cấu trúc mang lại sự nhất quán cho dự án của bạn, các thành viên mới trong nhóm có thể nhanh chóng nắm bắt thông tin và hiệu quả hơn trong khoảng thời gian ngắn hơn.
• Việc thử nghiệm sẽ dễ dàng hơn. Một cấu trúc tốt khuyến khích các kiểu đơn giản, thường dễ kiểm thử hơn.
• Bạn có thể điều tra lỗi một cách có phương pháp bằng các quy trình được xác định rõ.

Ngoài ra, việc góp vốn đầu tư vào Cấu trúc cũng tác động ảnh hưởng trực tiếp đến người dùng. Người dùng được hưởng lợi từ một ứng dụng không thay đổi hơn và nhiều tính năng hơn do nhóm kỹ thuật thao tác hiệu suất cao hơn. Tuy nhiên, Cấu trúc cũng cần có một khoản góp vốn đầu tư trước. Để giúp bạn hiểu rõ về điều này, hãy xem những nghiên cứu và điều tra nổi bật bên dưới qua san sẻ của những công ty khác về câu truyện thành công xuất sắc của họ khi chiếm hữu một cấu trúc ứng dụng tối ưu .

Mẫu

Các mẫu sau đây của Google biểu lộ cấu trúc ứng dụng tốt. Hãy mày mò những ứng dụng đó để xem hướng dẫn này trong thực tiễn :

Source: https://vh2.com.vn
Category : Ứng Dụng