Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Android SDK
Code

Giới thiệu về Các thành phần kiến trúc của Android

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called Android Architecture Components.
Android Architecture Components: Lifecycle and LiveModel

Vietnamese (Tiếng Việt) translation by Andrea Ho (you can also view the original English article)

Android ra mắt toàn thế giới vào năm 2005, và trong suốt 12 năm hiện hữu, nền tảng này đã gặt hái được những thành công ấn tượng, trở thành hệ điều hành di động được cài đặt nhiều nhất. Suốt khoảng thời gian đó, 14 phiên bản khác nhau của hệ điều hành đã được xuất bản, với Android luôn luôn trở nên vững vàng hơn. Tuy nhiên, một lình vực quan trong của nền tảng tiếp tục bị phớt lờ: một hình mẫu kiến trúc tiêu chuẩn, có thể đảm đương những điểm đặc trưng của nền tảng và đủ đơn giản các nhà phát triển bậc trung hiểu và thích nghi.

Xem nào, thà trễ còn hơn không có. Sau cùng Google I/O, đội ngũ Android đã quyết định xem xét vấn đề này và hồi đáp cho phản hồi của các nhà phát triển trên toàn thế giới, chính thức thông báo một khuyến nghị cho một kiến trúc ứng dụng Anroid và cung cấp những block đang xây dựng để triển khai nó: các Architecture Component mới. Và tốt hơn nữa, họ đã cố gắng thực hiện điều này mà không làm ảnh hưởng đến phần mở của hệ thống mà chúng ta đều biết đến và yêu thích.

Architecture Components

Trong bài hướng dẫn này, chúng ta sẽ khám phá kiến trúc được chuẩn hoá được đội ngũ Google I/O đề xuất và xem xét các thành phần chính của Architecture Components mới: Lifecycle, ViewModel, LifeData, và Room. Chúng ta sẽ không chú ý quá nhiều đến mã lệnh, thay vào đó sẽ tập trung vào khái niệm và logic đằng sau những chủ đề này. Chúng ta cũng sẽ xem qua một vài mẩu mã lệnh đơn giản, tất cả chúng được viết bằng Kotlin, một ngôn ngữ tuyệt vời chính thức được Android hỗ trợ.

1. Android đã thiếu điều gì?

Nếu bạn chỉ mới bắt đầu hành trình trở thành một nhà phát triển, có khả năng bạn không biết đến điều tôi đang nói đến. Sau tất cả, kiến trúc ứng dụng có thể là một đề tài khó hiểu. Nhưng tin tôi đi, bạn sẽ biết được sự quan trong của nó sớm thôi! Khi một ứng dụng tăng trưởng và trở nên phức tạp hơn, kiến trúc của nó sẽ trở nên càng quan trọng hơn. Nó có thể biến công việc của bạn thành một thú vui hoặc là một địa ngục trần gian.

Kiến trúc ứng dụng

Đại thể, một kiến trúc ứng dụng là một kế hoạch thích hợp cần được thực hiện trước khi quá trình phát triển bắt đầu. Kế hoạch này cung cấp một bản đồ cho việc làm sao các component khác nhau của ứng dụng nên được tổ chức và gắn kết với nhau rao sao. Nó đại diện cho bản hướng dẫn cần phải tuân theo theo suốt quá trình phát triển và thúc ép một vài sự hy sinh (thường liên quan đến nhiêu class và boilerplate), sau cùng nó sẽ giúp bạn cấu trúc một ứng dụng được xây dựng tốt và có thể được kiểm tra, mở rộng và bảo trì.

Kiến trúc phần mền ứng dụng là quá trình định nghĩa một giải pháp đã được cấu trúc, điều đó đáp ứng tất các yêu cầu về kỹ thuật và vận hành, trong khi tối ưu những đặc tính chất lượng thông thường như là hiệu năng, bảo mật an ninh, và khả năng quản lý. Nó ảnh hưởng đến một loạt những quyết định dựa trên nhóm lớn các nhân tố, và mỗi thứ trong số đó các quyết định đó có thể có những va chạm đáng cân nhắc về chất lượng, hiệu năng, khả năng duy trù, và thành tượa tởng quan của ứng dụng.
— Kiến trúc phần mềm và Hướng Dẫn Thiết Kế của Microsoft

Kiến trúc tốt cần nhiều yếu tố để cân nhắc, đặc biệt là các hạn chế và đặc tính của hệ thống. Có rất nhiều giải pháp kiến trúc khác nhau ngoài kia, tất cả chúng có ưu và khuyết điểm. Tuy nhiên những khái niệm chủ chốt đều giống nhau.

Những sai lầm cũ

Trước khi Google I/O gần nhất, hệ thống Android đã không khuyến khích bất kỳ Architecture đặc thù nào cho việc phát triển ứng dụng. Điều đó có nghĩa là bạn hoàn toàn tự do để thích nghi với bất kể mô hình nào: MVP, MVC, MVPP hoặc thậm chí không có mô hình nào cả. Hơn thế nữa, Android framework thậm chí đã không cung cấp những giải pháp cơ sở cho các vấn đề phát sinh bởi chính hệ thống của nó, cụ thể nhất là vòng đời của component.

Great news at the Google IO 2017

Vì thế nếu bạn muốn thông qua một mô hình Model View Presenter vào ứng dụng của bạn, bạn cần cho ra một giải pháp của bạn từ đầu, viết rất nhiều mã lệnh boilerplate, hoặc chọn một thư viện không được hỗ trợ chính thức. Và sự thiếu vắng những tiêu chuẩn tạo ra rất nhiều ứng dụng tồi tệ, với các nền tảng mã lệnh khó bảo trì và kiểm tra.

Như tôi đã nói, tình huống này đã được bình phẩm rất nhiều năm. Thực tế, gần đây tôi đã viết về vấn đề này và cách để tìm ra nó trong loạt bài viết Làm sao để tích hợp mô hình Model View Presenter. Nhưng điều quan trọng nhất là sau 12 năm dài, đội ngũ Android cuối cùng đã quyết định lắng nghe lời than phiền của chúng ta và giúp chúng ta về vấn đề này.

2. Android Architecture (kiến trúc Android)

Hướng dẫn mới về Android Architecture định nghĩa vài yếu tố chủ đạo mà một ứng dụng Android tốt nên sở hữu và cũng đề xuất một hướng đi an toàn cho nhà phát triển để tạo ra một ứng dụng tốt. Tuy nhiên, hướng dẫn rõ ràng chỉ định rằng hướng đi đã được trình bày là không bắt buộc, và quyết định sau cùng là của cá nhân bạn; bạn là người nên quyết định loại hình kiến trúc nào để tích hợp.

Dựa theo hướng dẫn, một ứng dụng Android tốt nên mang đến một sự tách biệt rõ ràng của các vấn đề và dẫn dắt UI từ một model. Bất kỳ mã lệnh mà không xử lý một UI hoặc tương tác với hệ điều hành không nên có trong một Activity hoặc Fragment, bởi vì giữ cho chúng luôn rõ ràng ở mức cao nhất có thể sẽ giúp bạn tránh những vấn đề có liên quan đến lifecyle. Sau cùng, một hệ thống có thể huỷ hoại Activities hoặc Fragments bất kỳ lúc nào. Dữ liệu cũng nên được đảm trách bởi các model, chúng được tách biệt với UI, và cũng tránh khỏi các vấn đề cửa lifecycle.

Kiến trúc khuyến nghị mới

Kiến trúc mà Android đang khuyến khích không dễ dãng được đặt tên giữa những mô hình chuẩn mực mà chúng ta biết. Nó giống như hình mẫu Model View Controller, như nó rất gần với kiến trúc của hệ thống mà rất khó để đặt tên cho mỗi thành phần với cách sử dụng các quy ước trước đây từng biết. Điều này không liên quan, khi điều quan trong nhất là nó dựa trên các Android Component mới để tạo ra một sự tách biệt của các vấn đề, với khả năng kiếm tra và bảo trì xuất sắc. Và hơn thế nữa, rất dễ dàng để triển khai.

Để hiểu được điều mà nhóm Androi đang đề xuất, chúng ta phải biết tất cả các thành phần của Architecture Component, chúng là những điều sẽ đảm đương những nhiệm vụ nặng nề cho chúng ta. Có 4 component, mỗi cái có vai trò đặc trưng: Room, ViewModel, LiveData, và Lifecycle. Tất cả những phần đó có nhiệm vụ riêng, và chúng làm việc cùng nhau để tạo ra một kiến trúc vững chắc. Hãy xem xét một giản đồ của kiến trúc đề xuất để hiểu nó rõ hơn.

Android Architecture

Như bạn có thể thấy, chúng ta có ba thành phần chính, mỗi cái có nhiệm vụ riêng.

  1. ActivityFragment đại diện cho layer View, nó không xử lý business logic và những hoạt động phức tạp. Nó chỉ cấu hình các view, xử lý tương tác người dùng, và quan trọng nhất, là quan sát và thể hiện các thành phần LiveData nhận được từ ViewModel.
  2. ViewModel tự động quan sát trạng thái Lifecycle của view, duy trì sự ổn định trong suốt các thay đổi cấu hình và các sự kiện Android lifecycle khác. Nó cũng được yêu cầu bởi view để lấy data từ Repository, được cung cấp như LiveData observables được. Rất quan trọng để hiểu rằng ViewModel không bao giờ tham chiếu đến View một cách trực tiếp và các cập nhật trên data luôn thực hiện bởi LiveData.
  3. Repository không phải là một Android component. Nó là một class đơn giản, không có triển khai đặc biệt nào, có trách nhiệm lấy data từ tất cả các nguồn có thể, từ một cơ sở dũ liệu đến các dịch vụ web. Nó xử lý tất cả data này, nói chung là chuyển đổi thành LiveData có thể quan sát được và làm cho chúng sẵn sàng sử dụng cho ViewModel.
  4. Cơ sở dữ liệu Room là một thư viện SQLite mapping, nó đơn giản hoá quá trình xử lý một cơ sở dữ liệu. Nó tự động viết rất nhiều boilerplate, kiểm tra lỗi lúc biên dịch, và đỉnh nhất là có thể trực tiếp trả về các câu truy vấn với LiveData observables được.

Tôi chắc rằng bạn đã chú ý rằng chúng tôi nói khá nhiều về observables. Mô hình Observer là một trong những nền móng của thành phần LiveData và đối tượng Lifecycle. Mô hình này cho phép một đối tượng báo hiệu một danh sách của các observers (kẻ quan sát) về bất kỳ thay đổi của trạng thái hoặc data. Cho nên khi một Activity quan sát một LiveData, nó sẽ nhận thông tin cập nhật khi data đó trải qua bất kể chỉnh sửa nào.

Một khuyến nghị khác của Android là củng cố các kiến trúc của nó sử dụng một hệ thống Dependency Injection, như Dagger 2 của Google hoặc sử dụng mô hình Service Locator Pattern (cái này đơn giản hơn DI, nhưng không có nhiều lợi điểm). Chúng tôi sẽ không đề cập DI hoặc Service Locator trong bài viết này, nhưng Envato Tuts+ có vài bài hướng dẫn xuất sắc về những chủ đề này. Tuy nhiên, có vài nét đặc thù của việc dùng Dagger 2 và Android Components sẽ được giải thích trong phần hai của loạt bài viết này.

3. Architecture Components (thành phần kiến trúc)

Chúng ta phải đào sâu vào các khía cạnh của các component mới để có thể thực sự hiểu và thích nghi mô hình kiến trúc này. Tuy nhiên, chúng tôi sẽ không đi quá chi tiết trong bài hướng dẫn này. Bởi vì sự phức tạp của mỗi thành phần, trong bài viết này, chúng ta chỉ nói về những ý tưởng chung đằng sau mỗi thành phần và xem xét những mã lệnh đơn giản. Chúng ta sẽ cố gắng đề cập vừa đủ cơ bản để đại biểu cho những component và giúp bạn bắt đầu. Nhưng đừng lo, bởi vì những bài viết kế tiếp trong loạt bài sẽ đào sâu và bao phủ toàn bộ những điểm đặc trưng của các Architecture Component.

Lifecycle-Aware Components (Các thành phần báo động cho Lifecycle)

Hầu hết những component của ứng dụng có vòng đời (lifecycle) gắn liền với chúng, được quản lý trực tiếp bởi hệ thống của chính nó. Mãi đến gần đây, điều đó mới phụ thuộc vào nhà phát triển, họ giám sát trạng thái của các component và hành động tương ứng với chúng, khởi tạo và kết thúc các công việc ở thời điểm thích hợp. Tuy nhiên, rất dễ gây bối rối và sinh ra lỗi liên quan đến kiểu vận hành này. Nhưng gói android.arch.lifecycle đã thay đổi tất cả.

Bây giờ, Activities và Fragments có một đối tượng (object) Lifecycle gắn liền, chúng có thể được quan sát bởi các class LifecycleObserver, như một ViewModel hoặc bất kỳ đối tượng nào triển khai interface này. Điều này có nghĩa là observer (đối tượng quan sát) sẽ nhận cập nhật về thay đổi trạng thái của đối tượng mà nó đang quan sát, giống như một Activity bị dừng lại hoặc khi nào nó đang bắt đầu. Nó cũng có thể kiểm tra trạng thái hiện giờ của đối tượng được quan sát. Cho nên nó dễ hơn rất nhiều khi đảm nhận những vận hành mà phải cân nhắc các vòng đời (lifecycle) của framework.

LifecycleObserver reacts to LifecycleEvents

Từ giờ, để tạo một Activity hoặc Fragment cho phù hợp với tiêu chuẩn mới, bạn phải mở rộng một LifeCycleActivity hoặc LifeCycleFragment. Tuy nhiên, có thể rằng không cần thiết luôn luôn như vậy, khi đội ngũ Android đang cố gắng tích hợp hoàn toàn những công cụ mới này với những framework của nó.

LifecycleObserver nhận các sự kiện Lifecyle và có thể phản ứng lại thông qua annotation (phần chú thích). Không cần override phương thức.

LiveData Component

LiveData Component là một data holder, nó chứa một giá trị có thể quan sát được. Observer này cung cấp một Lifecycle trong suốt sự khởi tạo LiveData, LiveData sẽ xử lý dựa theo trạng thái của Lifecycle. Nếu trạng thái Lifecycle của observer là STARTED hoặc RESUMED, observer sẽ hoạt động, nếu không phải, nó sẽ không hoạt động.

LiveData biết khi data được thay đổi và nếu observer đang hoạt động và nên nhận một cập nhật. Một đặc tính thú vị khác nữa của LiveData là nó có thể gỡ bỏ observer nếu nó ở trạng thái Lifecycle.State.DESTROYED, tránh làm rò rỉ bộ nhớ khi được quan sát bởi Activities và Fragments.

LiveData value updating process

Một LiveData phải triển khai các phương thức onActiveonlnactive.

Để quan sát một LiveData component, bạn phải gọi observer(LifecycleOwner, Observer).

ViewModel Component

Một trong số những class quan trọng nhất của Architecture Component là ViewModel, nó được thiết kế để giữ data có liên quan đến UI, duy trì sự đồng nhất trong suốt các thay đổi cấu hình như các lần xoay chiều màn hình. ViewModel có thể giao tiếp với Repository, lấy LiveData từ nó và khiến nó sẵn sàng được tuần tự quan sát bởi view. ViewModel cũng sẽ không cần tạo những call mới đến Repository sau các thay đổi cấu hình, nó tối ưu mã lệnh rất nhiều.

ViewModel is tight to UI Lifecycle

Để tạo một view model, thừa kế từ lớp ViewModel.

Để truy cập vào một view, bạn có thể gọi ViewProviders.of(Activity|Fragment).get(ViewModel::class). Phương thức factory này sẽ trả về một giá trị mới của ViewModel hoặc lấy một giá trị đã được lưu lại, khi phù hợp.

Room Component

Android đã hỗ trợ SQLite từ lúc bắt đầu; tuy nhiên, để cho nó làm việc, luôn cần viết rất nhiều boilerplate. SQLite cũng không lưu POJOs (các đối tượng plain-old Java), và không kiểm tra các câu truy vấn khi biên dịch. Room xuất hiện để giải quyết những vấn đề này! Nó là một thư viện SQLite mapping, có thể tiếp tục giữ JAVA POJOs, chuyển đổi trực tiếp những câu truy vấn thành các object, kiểm tra lỗi lúc biên dịch, và cho ra những observables LiveData từ kết quả truy vấn. Room là một thư viện Object Relational Mapping với vài tinh năng bổ sung Android hay ho khác.

Đến thời điểm này, bạn có thể làm đa phần những gì Room có thể sử dụng những thư viện Android ORM khác. Tuy nhiên, không cái nào trong số đó được chính thức hỗ trợ, quan trong nhất, họ không thể cho ra các kết quả LifeData. Thư viện Room phù hợp hoàn hảo như một layer vững chãi trên đề xuất Android Architecture.

Để tạo một cơ sở dữ liệu Room, bạn sẽ cần một @Entity để hiện diện, nó có thể là một JAVA POJO bất kỳ, một interface @Dao để tạo những câu truy vấn và các vận hành input/output, và một abstract class @Database kế thừa RoomDatabase.

Bổ sung thêm các Architect Component cho dự án của bạn.

Từ giờ, để sử dụng các Architect Component, bạn sẽ cần bổ sung thêm trước nhất repo Google vào file build.gradle của bạn. Để có thêm thông tin, hãy đọc hướng dẫn chính thức.

Tổng kết

Bạn cũng có thể thấy, kiến trúc chuẩn hoá đề xuất từ Android tác động đến nhiều khái niệm, Đừng mong đợi sẽ hiểu rõ chủ đề này vội. Sau tất cả, chúng ta gần như chỉ giới thiệu chủ đề. Nhưng bạn dĩ nhiên có đủ kiến thức từ bây giờ để hiểu logic đằng sau kiến trúc và các vai trò của các Architecture Component khác nhau.

Chúng ta đã nói hầu hết những chủ đề có liên quan đến kiến trúc Android được đề xuất và các component của nó; tuy nhiên, chi tiết về cách triển khai component và các phần bổ sung khác; như lớp Repository và hệ thống Dagger 2 không thể được đề cập trong phần đầu tiên này. Chúng ta sẽ khám phá những chủ đề đó trong những bài viết tiếp theo!

Hẹn sớm gặp lại bạn!

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.