App開發架構指南（谷歌官方文檔譯文）
這篇文章面向的是已經掌握app開發基本知識，想知道如何開發健壯app的讀者。
注：本指南假設讀者對 Android Framework 已經很熟悉。如果你還是app開發的新手，請查看 Getting Started 系列教程，該教程涵蓋了本指南的預備知識。
app開發者面臨的常見問題
跟傳統的桌面應用開發不同，Android app的架構要復雜得多。一個典型的Android app是由多個app組件構成的，包括activity,Fragment,service,content provider以及broadcast receiver。而傳統的桌面應用往往在一個龐大的單一的進程中就完成了。
大多數的app組件都聲明在app manifest中，Android OS用它來決定如何將你的app與設備整合形成統一的用戶體驗。雖然就如剛說的，桌面app只運行一個進程，但是一個優秀的Android app卻需要更加靈活，因為用戶操作在不同app之間，不斷的切換流程和任務。
比如，當你要在自己最喜歡的社交網絡app中分享一張照片的時候，你可以想象一下會發生什么。app觸發一個camera intent，然后Android OS啟動一個camera app來處理這一動作。此時用戶已經離開了社交網絡的app，但是用戶的操作體驗卻是無縫對接的。而 camera app反過來也可能觸發另一個intent，比如啟動一個文件選擇器，這可能會再次打開另一個app。***用戶回到社交網絡app并分享照片。在這期間的任意時刻用戶都可被電話打斷，打完電話之后繼續回來分享照片。
在Android中，這種app并行操作的行為是很常見的，因此你的app必須正確處理這些流程。還要記住移動設備的資源是有限的，因此任何時候操作系統都有可能殺死某些app，為新運行的app騰出空間。
總的來說就是，你的app組件可能是單獨啟動并且是無序的，而且在任何時候都有可能被系統或者用戶銷毀。因為app組件生命的短暫性以及生命周期的不可控制性，任何數據都不應該把存放在app組件中，同時app組件之間也不應該相互依賴。
通用的架構準則
如果app組件不能存放數據和狀態，那么app還是可架構的嗎?
最重要的一個原則就是盡量在app中做到separation of concerns(關注點分離)。常見的錯誤就是把所有代碼都寫在Activity或者Fragment中。任何跟UI和系統交互無關的事情都不應該放在這些類當中。盡可能讓它們保持簡單輕量可以避免很多生命周期方面的問題。別忘了能并不擁有這些類，它們只是連接app和操作系統的橋梁。根據用戶的操作和其它因素，比如低內存，Android OS可能在任何時候銷毀它們。為了提供可靠的用戶體驗，***把對它們的依賴最小化。
第二個很重要的準則是用。之所以要持久化是基于兩個原因：如果OS銷毀app釋放資源，用戶數據不會丟失;當網絡很差或者斷網的時候app可以繼續工作。Model是負責app數據處理的組件。它們不依賴于View或者app 組件(Activity，Fragment等)，因此它們不會受那些組件的生命周期的影響。保持UI代碼的簡單，于業務邏輯分離可以讓它更易管理。
app架構推薦
在這一小節中，我們將通過一個用例演示如何使用Architecture Component構建一個app。
注：沒有一種適合所有場景的app編寫方式。也就是說，這里推薦的架構適合作為大多數用戶案例的開端。但是如果你已經有了一種好的架構，沒有必要再去修改。
假設我們在創建一個顯示用戶簡介的UI。用戶信息取自我們自己的私有的后端REST API。
創建用戶界面
UI由UserProfileFragment.java以及相應的布局文件user_profile_layout.xml組成。
要驅動UI，我們的data model需要持有兩個數據元素。
User ID: 用戶的身份識別。***使用fragment argument來傳遞這個數據。如果OS殺死了你的進程，這個數據可以被保存下來，所以app再次啟動的時候id仍是可用的。
User object: 一個持有用戶信息數據的POJO對象。
我們將創建一個繼承ViewModel類的UserProfileViewModel來保存這一信息。
一個ViewModel為特定的UI組件提供數據，比如fragment 或者 activity，并負責和數據處理的業務邏輯部分通信，比如調用其它組件加載數據或者轉發用戶的修改。ViewModel并不知道View的存在，也不會被configuration change影響。
現在我們有了三個文件。
user_profile.xml: 定義頁面的UI
UserProfileViewModel.java: 為UI準備數據的類
UserProfileFragment.java: 顯示ViewModel中的數據與響應用戶交互的控制器
下面我們開始實現(為簡單起見，省略了布局文件)：
- public class UserProfileViewModel extends ViewModel {
- private String userId;
- private User user;
- public void init(String userId) {
- this.userId = userId;
- }
- public User getUser() {
- return user;
- }
- }
- public class UserProfileFragment extends LifecycleFragment {
- private static final String UID_KEY = "uid";
- private UserProfileViewModel viewModel;
- @Override
- public void onActivityCreated(@Nullable Bundle savedInstanceState) {
- super.onActivityCreated(savedInstanceState);
- String userId = getArguments().getString(UID_KEY);
- viewModel = ViewModelProviders.of(this).get(UserProfileViewModel.class);
- viewModel.init(userId);
- }
- @Override
- public View onCreateView(LayoutInflater inflater,
- @Nullable ViewGroup container, @Nullable Bundle savedInstanceState) {
- return inflater.inflate(R.layout.user_profile, container, false);
- }
- }
注：上面的例子中繼承的是LifecycleFragment而不是Fragment類。等Architecture Component中的lifecycles API穩定之后，Android Support Library中的Fragment類也將實現LifecycleOwner。
現在我們有了這些代碼模塊，如何連接它們呢?畢竟當ViewModel的user成員設置之后，我們還需要把它顯示到界面上。這就要用到LiveData了。
LiveData是一個可觀察的數據持有者。 無需明確在它與app組件之間創建依賴就可以觀察LiveData對象的變化。LiveData還考慮了app組件(activities, fragments, services)的生命周期狀態，做了防止對象泄漏的事情。
注：如果你已經在使用RxJava或者Agera這樣的庫，你可以繼續使用它們，而不使用LiveData。但是使用它們的時候要確保正確的處理生命周期的問題，與之相關的LifecycleOwner stopped的時候數據流要停止，LifecycleOwner destroyed的時候數據流也要銷毀。你也可以使用android.arch.lifecycle:reactivestreams讓LiveData和其它的響應式數據流庫一起使用(比如, RxJava2)。
現在我們把UserProfileViewModel中的User成員替換成LiveData，這樣當數據發生變化的時候fragment就會接到通知。LiveData的妙處在于它是有生命周期意識的，當它不再被需要的時候會自動清理引用。
- public class UserProfileViewModel extends ViewModel {
- ...
- private User user;
- private LiveData<User> user;
- public LiveData<User> getUser() {
- return user;
- }
- }
現在我們修改UserProfileFragment，讓它觀察數據并更新UI。
- @Override
- public void onActivityCreated(@Nullable Bundle savedInstanceState) {
- super.onActivityCreated(savedInstanceState);
- viewModel.getUser().observe(this, user -> {
- // update UI
- });
- }
每當User數據更新的時候 onChanged 回調將被觸發，然后刷新UI。
如果你熟悉其它library的observable callback的用法，你會意識到我們不需要重寫fragment的onStop()方法停止對數據的觀察。因為LiveData是有生命周期意識的，也就是說除非fragment處于活動狀態，否則callback不會觸發。LiveData還可以在fragmentonDestroy()的時候自動移除observer。
對我們也沒有做任何特殊的操作來處理 configuration changes(比如旋轉屏幕)。ViewModel可以在configuration change的時候自動保存下來，一旦新的fragment進入生命周期，它將收到相同的ViewModel實例，并且攜帶當前數據的callback將立即被調用。這就是為什么ViewModel不應該直接引用任何View，它們游離在View的生命周期之外。參見ViewModel的生命周期。
獲取數據
現在我們把ViewModel和fragment聯系了起來，但是ViewModel該如何獲取數據呢?在我們的例子中，假設后端提供一個REST API，我們使用Retrofit從后端提取數據。你也可以使用任何其它的library來達到相同的目的。
下面是和后端交互的retrofit Webservice：
- public interface Webservice {
- /**
- * @GET declares an HTTP GET request
- * @Path("user") annotation on the userId parameter marks it as a
- * replacement for the {user} placeholder in the @GET path
- */
- @GET("/users/{user}")
- Call<User> getUser(@Path("user") String userId);
- }
ViewModel的一個簡單的實現方式是直接調用Webservice獲取數據，然后把它賦值給User對象。雖然這樣可行，但是隨著app的增大會變得難以維護。ViewModel的職責過多也違背了前面提到的關注點分離(separation of concerns)原則。另外，ViewModel的有效時間是和Activity和Fragment的生命周期綁定的，因此當它的生命周期結束便丟失所有數據是一種不好的用戶體驗。相反，我們的ViewModel將把這個工作代理給Repository模塊。
Repository模塊負責處理數據方面的操作。它們為app提供一個簡潔的API。它們知道從哪里得到數據以及數據更新的時候調用什么API。你可以把它們看成是不同數據源(persistent model, web service, cache, 等等)之間的媒介。
下面的UserRepository類使用了WebService來獲取用戶數據。
- public class UserRepository {
- private Webservice webservice;
- // ...
- public LiveData<User> getUser(int userId) {
- // This is not an optimal implementation, we'll fix it below
- final MutableLiveData<User> data = new MutableLiveData<>();
- webservice.getUser(userId).enqueue(new Callback<User>() {
- @Override
- public void onResponse(Call<User> call, Response<User> response) {
- // error case is left out for brevity
- data.setValue(response.body());
- }
- });
- return data;
- }
- }
雖然repository模塊看起來沒什么必要，但它其實演扮演著重要的角色;它把數據源從app中抽象出來。現在我們的ViewModel并不知道數據是由Webservice提供的，意味著有必要的話可以替換成其它的實現方式。
注：為簡單起見我們省略了網絡錯誤出現的情況。實現了暴露網絡錯誤和加載狀態的版本見下面的Addendum: exposing network status。
管理不同組件間的依賴：
前面的UserRepository類需要Webservice的實例才能完成它的工作。可以直接創建它就是了，但是為此我們還需要知道Webservice所依賴的東西才能構建它。這顯著的增減了代碼的復雜度和偶合度(比如，每個需要Webservice實例的類都需要知道如何用它的依賴去構建它)。另外，UserRepository很可能不是唯一需要Webservice的類。如果每個類都創建一個新的WebService，就變得很重了。
有兩種模式可以解決這個問題：
依賴注入: 依賴注入允許類在無需構造依賴的情況下定義自己的依賴對象。在運行時由另一個類來負責提供這些依賴。在Android app中我們推薦使用谷歌的Dagger 2來實現依賴注入。Dagger 2 通過遍歷依賴樹自動構建對象，并提供編譯時的依賴。
Service Locator：Service Locator 提供一個registry，類可以從這里得到它們的依賴而不是構建它們。相對依賴注入來說要簡單些，所以如果你對依賴注入不熟悉，可以使用 Service Locator 。
這些模式允許你擴展自己的代碼，因為它們提供了清晰的模式來管理依賴，而不是不斷的重復代碼。兩者均支持替換成mock依賴來測試，這也是使用它們主要優勢之一。
在這個例子中，我們將使用 Dagger 2 來管理依賴。
連接ViewModel和repository
現在我們修改UserProfileViewModel以使用repository。
- public class UserProfileViewModel extends ViewModel {
- private LiveData<User> user;
- private UserRepository userRepo;
- @Inject // UserRepository parameter is provided by Dagger 2
- public UserProfileViewModel(UserRepository userRepo) {
- this.userRepo = userRepo;
- }
- public void init(String userId) {
- if (this.user != null) {
- // ViewModel is created per Fragment so
- // we know the userId won't change
- return;
- }
- user = userRepo.getUser(userId);
- }
- public LiveData<User> getUser() {
- return this.user;
- }
- }
