[[192223]]

這篇文章面向的是已經(jīng)掌握app開發(fā)基本知識(shí)，想知道如何開發(fā)健壯a(bǔ)pp的讀者。

注：本指南假設(shè)讀者對(duì) Android Framework 已經(jīng)很熟悉。如果你還是app開發(fā)的新手，請(qǐng)查看 Getting Started 系列教程，該教程涵蓋了本指南的預(yù)備知識(shí)。

app開發(fā)者面臨的常見問題

跟傳統(tǒng)的桌面應(yīng)用開發(fā)不同，Android app的架構(gòu)要復(fù)雜得多。一個(gè)典型的Android app是由多個(gè)app組件構(gòu)成的，包括activity,Fragment,service,content provider以及broadcast receiver。而傳統(tǒng)的桌面應(yīng)用往往在一個(gè)龐大的單一的進(jìn)程中就完成了。

大多數(shù)的app組件都聲明在app manifest中，Android OS用它來決定如何將你的app與設(shè)備整合形成統(tǒng)一的用戶體驗(yàn)。雖然就如剛說的，桌面app只運(yùn)行一個(gè)進(jìn)程，但是一個(gè)優(yōu)秀的Android app卻需要更加靈活，因?yàn)橛脩舨僮髟诓煌琣pp之間，不斷的切換流程和任務(wù)。

比如，當(dāng)你要在自己最喜歡的社交網(wǎng)絡(luò)app中分享一張照片的時(shí)候，你可以想象一下會(huì)發(fā)生什么。app觸發(fā)一個(gè)camera intent，然后Android OS啟動(dòng)一個(gè)camera app來處理這一動(dòng)作。此時(shí)用戶已經(jīng)離開了社交網(wǎng)絡(luò)的app，但是用戶的操作體驗(yàn)卻是無縫對(duì)接的。而 camera app反過來也可能觸發(fā)另一個(gè)intent，比如啟動(dòng)一個(gè)文件選擇器，這可能會(huì)再次打開另一個(gè)app。***用戶回到社交網(wǎng)絡(luò)app并分享照片。在這期間的任意時(shí)刻用戶都可被電話打斷，打完電話之后繼續(xù)回來分享照片。

在Android中，這種app并行操作的行為是很常見的，因此你的app必須正確處理這些流程。還要記住移動(dòng)設(shè)備的資源是有限的，因此任何時(shí)候操作系統(tǒng)都有可能殺死某些app，為新運(yùn)行的app騰出空間。

總的來說就是，你的app組件可能是單獨(dú)啟動(dòng)并且是無序的，而且在任何時(shí)候都有可能被系統(tǒng)或者用戶銷毀。因?yàn)閍pp組件生命的短暫性以及生命周期的不可控制性，任何數(shù)據(jù)都不應(yīng)該把存放在app組件中，同時(shí)app組件之間也不應(yīng)該相互依賴。

通用的架構(gòu)準(zhǔn)則

如果app組件不能存放數(shù)據(jù)和狀態(tài)，那么app還是可架構(gòu)的嗎?

最重要的一個(gè)原則就是盡量在app中做到separation of concerns(關(guān)注點(diǎn)分離)。常見的錯(cuò)誤就是把所有代碼都寫在Activity或者Fragment中。任何跟UI和系統(tǒng)交互無關(guān)的事情都不應(yīng)該放在這些類當(dāng)中。盡可能讓它們保持簡(jiǎn)單輕量可以避免很多生命周期方面的問題。別忘了能并不擁有這些類，它們只是連接app和操作系統(tǒng)的橋梁。根據(jù)用戶的操作和其它因素，比如低內(nèi)存，Android OS可能在任何時(shí)候銷毀它們。為了提供可靠的用戶體驗(yàn)，***把對(duì)它們的依賴最小化。

第二個(gè)很重要的準(zhǔn)則是用。之所以要持久化是基于兩個(gè)原因：如果OS銷毀app釋放資源，用戶數(shù)據(jù)不會(huì)丟失;當(dāng)網(wǎng)絡(luò)很差或者斷網(wǎng)的時(shí)候app可以繼續(xù)工作。Model是負(fù)責(zé)app數(shù)據(jù)處理的組件。它們不依賴于View或者app 組件(Activity，F(xiàn)ragment等)，因此它們不會(huì)受那些組件的生命周期的影響。保持UI代碼的簡(jiǎn)單，于業(yè)務(wù)邏輯分離可以讓它更易管理。

app架構(gòu)推薦

在這一小節(jié)中，我們將通過一個(gè)用例演示如何使用Architecture Component構(gòu)建一個(gè)app。

注：沒有一種適合所有場(chǎng)景的app編寫方式。也就是說，這里推薦的架構(gòu)適合作為大多數(shù)用戶案例的開端。但是如果你已經(jīng)有了一種好的架構(gòu)，沒有必要再去修改。

假設(shè)我們?cè)趧?chuàng)建一個(gè)顯示用戶簡(jiǎn)介的UI。用戶信息取自我們自己的私有的后端REST API。

創(chuàng)建用戶界面

UI由UserProfileFragment.java以及相應(yīng)的布局文件user_profile_layout.xml組成。

要驅(qū)動(dòng)UI，我們的data model需要持有兩個(gè)數(shù)據(jù)元素。

User ID: 用戶的身份識(shí)別。***使用fragment argument來傳遞這個(gè)數(shù)據(jù)。如果OS殺死了你的進(jìn)程，這個(gè)數(shù)據(jù)可以被保存下來，所以app再次啟動(dòng)的時(shí)候id仍是可用的。

User object: 一個(gè)持有用戶信息數(shù)據(jù)的POJO對(duì)象。

我們將創(chuàng)建一個(gè)繼承ViewModel類的UserProfileViewModel來保存這一信息。

一個(gè)ViewModel為特定的UI組件提供數(shù)據(jù)，比如fragment 或者 activity，并負(fù)責(zé)和數(shù)據(jù)處理的業(yè)務(wù)邏輯部分通信，比如調(diào)用其它組件加載數(shù)據(jù)或者轉(zhuǎn)發(fā)用戶的修改。ViewModel并不知道View的存在，也不會(huì)被configuration change影響。

現(xiàn)在我們有了三個(gè)文件。

user_profile.xml: 定義頁面的UI

UserProfileViewModel.java: 為UI準(zhǔn)備數(shù)據(jù)的類

UserProfileFragment.java: 顯示ViewModel中的數(shù)據(jù)與響應(yīng)用戶交互的控制器

下面我們開始實(shí)現(xiàn)(為簡(jiǎn)單起見，省略了布局文件)： 

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穩(wěn)定之后，Android Support Library中的Fragment類也將實(shí)現(xiàn)LifecycleOwner。

現(xiàn)在我們有了這些代碼模塊，如何連接它們呢?畢竟當(dāng)ViewModel的user成員設(shè)置之后，我們還需要把它顯示到界面上。這就要用到LiveData了。

LiveData是一個(gè)可觀察的數(shù)據(jù)持有者。 無需明確在它與app組件之間創(chuàng)建依賴就可以觀察LiveData對(duì)象的變化。LiveData還考慮了app組件(activities, fragments, services)的生命周期狀態(tài)，做了防止對(duì)象泄漏的事情。

注：如果你已經(jīng)在使用RxJava或者Agera這樣的庫，你可以繼續(xù)使用它們，而不使用LiveData。但是使用它們的時(shí)候要確保正確的處理生命周期的問題，與之相關(guān)的LifecycleOwner stopped的時(shí)候數(shù)據(jù)流要停止，LifecycleOwner destroyed的時(shí)候數(shù)據(jù)流也要銷毀。你也可以使用android.arch.lifecycle:reactivestreams讓LiveData和其它的響應(yīng)式數(shù)據(jù)流庫一起使用(比如, RxJava2)。

現(xiàn)在我們把UserProfileViewModel中的User成員替換成LiveData，這樣當(dāng)數(shù)據(jù)發(fā)生變化的時(shí)候fragment就會(huì)接到通知。LiveData的妙處在于它是有生命周期意識(shí)的，當(dāng)它不再被需要的時(shí)候會(huì)自動(dòng)清理引用。

public class UserProfileViewModel extends ViewModel { 
 
    ... 
 
    private User user; 
 
    private LiveData<User> user; 
 
    public LiveData<User> getUser() { 
 
        return user; 
 
    } 
 
} 

現(xiàn)在我們修改UserProfileFragment，讓它觀察數(shù)據(jù)并更新UI。

@Override 
 
public void onActivityCreated(@Nullable Bundle savedInstanceState) { 
 
    super.onActivityCreated(savedInstanceState); 
 
    viewModel.getUser().observe(this, user -> { 
 
      // update UI 
 
    }); 
 
} 

每當(dāng)User數(shù)據(jù)更新的時(shí)候 onChanged 回調(diào)將被觸發(fā)，然后刷新UI。

如果你熟悉其它library的observable callback的用法，你會(huì)意識(shí)到我們不需要重寫fragment的onStop()方法停止對(duì)數(shù)據(jù)的觀察。因?yàn)長(zhǎng)iveData是有生命周期意識(shí)的，也就是說除非fragment處于活動(dòng)狀態(tài)，否則callback不會(huì)觸發(fā)。LiveData還可以在fragmentonDestroy()的時(shí)候自動(dòng)移除observer。

對(duì)我們也沒有做任何特殊的操作來處理 configuration changes(比如旋轉(zhuǎn)屏幕)。ViewModel可以在configuration change的時(shí)候自動(dòng)保存下來，一旦新的fragment進(jìn)入生命周期，它將收到相同的ViewModel實(shí)例，并且攜帶當(dāng)前數(shù)據(jù)的callback將立即被調(diào)用。這就是為什么ViewModel不應(yīng)該直接引用任何View，它們游離在View的生命周期之外。參見ViewModel的生命周期。

獲取數(shù)據(jù)

現(xiàn)在我們把ViewModel和fragment聯(lián)系了起來，但是ViewModel該如何獲取數(shù)據(jù)呢?在我們的例子中，假設(shè)后端提供一個(gè)REST API，我們使用Retrofit從后端提取數(shù)據(jù)。你也可以使用任何其它的library來達(dá)到相同的目的。

下面是和后端交互的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的一個(gè)簡(jiǎn)單的實(shí)現(xiàn)方式是直接調(diào)用Webservice獲取數(shù)據(jù)，然后把它賦值給User對(duì)象。雖然這樣可行，但是隨著app的增大會(huì)變得難以維護(hù)。ViewModel的職責(zé)過多也違背了前面提到的關(guān)注點(diǎn)分離(separation of concerns)原則。另外，ViewModel的有效時(shí)間是和Activity和Fragment的生命周期綁定的，因此當(dāng)它的生命周期結(jié)束便丟失所有數(shù)據(jù)是一種不好的用戶體驗(yàn)。相反，我們的ViewModel將把這個(gè)工作代理給Repository模塊。

Repository模塊負(fù)責(zé)處理數(shù)據(jù)方面的操作。它們?yōu)閍pp提供一個(gè)簡(jiǎn)潔的API。它們知道從哪里得到數(shù)據(jù)以及數(shù)據(jù)更新的時(shí)候調(diào)用什么API。你可以把它們看成是不同數(shù)據(jù)源(persistent model, web service, cache, 等等)之間的媒介。

下面的UserRepository類使用了WebService來獲取用戶數(shù)據(jù)。

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模塊看起來沒什么必要，但它其實(shí)演扮演著重要的角色;它把數(shù)據(jù)源從app中抽象出來?，F(xiàn)在我們的ViewModel并不知道數(shù)據(jù)是由Webservice提供的，意味著有必要的話可以替換成其它的實(shí)現(xiàn)方式。

注：為簡(jiǎn)單起見我們省略了網(wǎng)絡(luò)錯(cuò)誤出現(xiàn)的情況。實(shí)現(xiàn)了暴露網(wǎng)絡(luò)錯(cuò)誤和加載狀態(tài)的版本見下面的Addendum: exposing network status。

管理不同組件間的依賴：

前面的UserRepository類需要Webservice的實(shí)例才能完成它的工作。可以直接創(chuàng)建它就是了，但是為此我們還需要知道Webservice所依賴的東西才能構(gòu)建它。這顯著的增減了代碼的復(fù)雜度和偶合度(比如，每個(gè)需要Webservice實(shí)例的類都需要知道如何用它的依賴去構(gòu)建它)。另外，UserRepository很可能不是唯一需要Webservice的類。如果每個(gè)類都創(chuàng)建一個(gè)新的WebService，就變得很重了。

有兩種模式可以解決這個(gè)問題：

依賴注入: 依賴注入允許類在無需構(gòu)造依賴的情況下定義自己的依賴對(duì)象。在運(yùn)行時(shí)由另一個(gè)類來負(fù)責(zé)提供這些依賴。在Android app中我們推薦使用谷歌的Dagger 2來實(shí)現(xiàn)依賴注入。Dagger 2 通過遍歷依賴樹自動(dòng)構(gòu)建對(duì)象，并提供編譯時(shí)的依賴。

Service Locator：Service Locator 提供一個(gè)registry，類可以從這里得到它們的依賴而不是構(gòu)建它們。相對(duì)依賴注入來說要簡(jiǎn)單些，所以如果你對(duì)依賴注入不熟悉，可以使用 Service Locator 。

這些模式允許你擴(kuò)展自己的代碼，因?yàn)樗鼈兲峁┝饲逦哪Ｊ絹砉芾硪蕾?，而不是不斷的重?fù)代碼。兩者均支持替換成mock依賴來測(cè)試，這也是使用它們主要優(yōu)勢(shì)之一。

在這個(gè)例子中，我們將使用 Dagger 2 來管理依賴。

連接ViewModel和repository

現(xiàn)在我們修改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; 
 
    } 
 
}