Android Architecture Components
開發者經常面臨的問題
Android應用由四大組件構成，各組件可以被獨立且無序的調起，用戶會在各個App之間來回切換。組件啟動后，生命周期會受用戶的操作和系統影響，不完全受開發者控制。而由于設備內存問題，進程隨時可能被系統強殺，所以不要將數據和狀態直接存儲在組件中，也不要讓組件互相依賴。
問題實例
-
內存泄漏：在Activity中發起網絡請求，在網絡請求返回之前退出Activity， 那么Activity就被泄漏了。
-
崩潰：Activity destroy后，還被其他類操作，從而引發崩潰，例如Glide圖片庫；
-
Activity類臃腫：數據，邏輯，控件代碼都堆積在Activity中，導致Activity臃腫，不易維護和測試。
-
Fragment通信困難：開發中經常會遇到Activity中含有多個Fragment的情況， 并且Fragment之間需要通信。通常會利用Activity轉發Fragment之間的通信，而且Fragment之間還需要依賴對方的生命周期和通信細節。
-
數據易銷毀：如果將內存中的數據保存在Activity中，由于Activity很容易被銷毀重建（配置改變，內存不夠），那么數據也就很容易被銷毀。
通用的框架原則
-
關注點分離：不要在Activity/Fragment中添加非UI控制、非系統接口調用的代碼。盡量讓他們保持精煉，以免引起生命周期相關的問題。這些類是系統創建和管理的，并不完全受開發者控制。
-
模型驅動UI：應該用數據模型驅動UI展示，最好是持久模型，因為當系統強殺進程或者網絡不穩定時，持久模型能讓程序繼續工作。模型獨立于組件之外，不會受到生命周期的影響。
應用框架組件
Android官方在17年IO大會上發布了一套框架組件，幫助開發者開發優質的App.
LifeCycle
將Activity/Fragment的生命周期剝離到其他類中，減少組件類中的代碼。
LifeCycle用兩個枚舉類追蹤組件的狀態。
- Event：從Framework層分發的，匹配Activity和Fragment中的生命周期方法回調。
- State：當前組件的狀態。
使用方式
public class LearnLifeCycleObserver implements LifecycleObserver {@OnLifecycleEvent(Lifecycle.Event.ON_CREATE)public void onCreate() {}@OnLifecycleEvent(Lifecycle.Event.ON_STOP)public void onStop() {} }public class LearnLifeCycleActivity extends AppCompatActivity {@Overrideprotected void onCreate(@Nullable Bundle savedInstanceState) {super.onCreate(savedInstanceState);getLifecycle().addObserver(new LearnLifeCycleObserver());} }實踐
-
將UI和數據分離，UI層不需要持有數據。
-
構建數據驅動UI的應用，UI控制器負責根據數據更新UI以及將用戶的操作反饋給數據層。
-
將數據邏輯放在ViewModel中，將數據拉取邏輯放在數據倉庫(Data Repository)中.
-
使用MVP模式，引入Presenter, 讓程序更加容易被測試。
LiveData
一個自帶觀察者模式的數據封裝類，不同的是LiveData有生命周期，會利用LifeCycle自動監聽與它綁定的組件的生命周期。當數據發生改變時，Activity或者Fragment要處于活動狀態，觀察者才會接收到數據改變的回調，此時界面就可以安全的進行渲染，而不會出現Activity銷毀后還更改界面的情況。
優點
- 不會造成泄漏內存。
- 不會由于操作銷毀的Activity而發生崩潰。
- 不需要手動處理生命周期。
- 數據總能實時更新。
- 數據不會受configuration更改的影響。
- 易于共享數據。
使用
final MutableLiveData<String> userNameLiveData = new MutableLiveData<>();userNameLiveData.observe(this, new Observer<String>() {@Overridepublic void onChanged(@Nullable String s) {//Activity的lifecycle state處于STARTED或RESUMED時才會回調mUserNameTV.setText(s);} });mUserNameSetBtn.setOnClickListener(new View.OnClickListener(){@Overridepublic void onClick(View v) {//更新LiveData的數據，以嘗試觸發觀察者的通知userNameLiveData.setValue("jayden");} });兩個擴展類
MutableLiveData
開放了setValue和postValue方法，用于主動改變LiveData的值，并通知觀察者。
MediatorLiveData
可以同時觀察多個LiveData, 當被觀察的LiveData發生改變時，可以對LiveData的數據進行加工后再通知MediatorLiveData.
轉換LiveData
Transformations#map
利用MediatorLiveData將LiveData的數據加工后再通知給觀察者。
LiveData<User> userLiveData = ...; LiveData<String> userName = Transformations.map(userLiveData, user -> {user.name + " " + user.lastName });Transformations#switchMap
和map方法類似，而且也是用MediatorLiveData實現。但是switchMap方法的第二個形參接口的返回值是LiveData. 如下代碼塊中的例子，當userId發生改變后，getUser(id)返回另一個LiveData: liveData1, user的觀察者開始觀察liveData1的變化。
舉個例子：id為1的用戶切換成id為2的用戶后，getUser(id)方法返回的LiveData就是id為2的用戶的用戶信息，以后如果id為2的用戶信息發生改變，user的觀察者就會接收到通知。
private LiveData<User> getUser(String id) {...; }LiveData<String> userId = ...; LiveData<User> user = Transformations.switchMap(userId, id -> getUser(id) );ViewModel
用來存儲和管理和UI相關的有生命周期的數據。當Configuration改變，例如屏幕旋轉，語言切換時，ViewModel中的數據不會被銷毀，是一個不會被濫用的單例。
創建ViewModel
利用LiveData持有數據
public class MyViewModel extends ViewModel {private MutableLiveData<List<User>> mObservableUsers;public MyViewModel(){mObservableUsers = new MutableLiveData<List<Users>>();}public LiveData<List<User>> getUsers() {return mObservableUsers;}private void loadUsers() {// 異步加載數據后通知到users中。...mObservableUsers.setValue(users)} }在Activity中監聽數據改變
public class MyActivity extends AppCompatActivity {public void onCreate(Bundle savedInstanceState) {MyViewModel model = ViewModelProviders.of(this).get(MyViewModel.class);//監聽LiveDatamodel.getUsers().observe(this, users -> {// update UI});} }如果由于屏幕旋轉或語言切換導致Activity重建，ViewModelProviders.of(this).get(MyViewModel.class);獲取的ViewModel還是Activity首次創建時所構建的，只有當Activity銷毀后，ViewModel才會被清除。
ViewModel的生命周期
在多個Fragment中共享數據
public class SharedViewModel extends ViewModel {private final MutableLiveData<Item> selected = new MutableLiveData<Item>();public void select(Item item) {selected.setValue(item);}public LiveData<Item> getSelected() {return selected;} }public class MasterFragment extends Fragment {private SharedViewModel model;public void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);model = ViewModelProviders.of(getActivity()).get(SharedViewModel.class);itemSelector.setOnClickListener(item -> {model.select(item);});} }public class DetailFragment extends Fragment {public void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);SharedViewModel model = ViewModelProviders.of(getActivity()).get(SharedViewModel.class);model.getSelected().observe(this, { item ->// Update the UI.});} }兩個Fragment拿到的ViewModel對象是同一個。
這種方式的優點：
- Activity不需要了解Fragment之間的通信，完全松耦合。
- 兩個Fragment都不需要依賴對方的生命周期和通信細節，即使一個Fragment被銷毀，也不會影響另一個Fragment.
最終的框架
推薦的框架原則
-
在Manifest文件中定義的程序入口：Activities, Services, BroadcastReceiver等，都不能作為數據的來源。
-
明確定義各模塊的職責。
-
盡可能少地暴露每個模塊的信息。
-
定義模塊間的交互時，考慮如何讓他們易于測試。
-
將數據持久化，讓程序在離線時更加可用。
-
數據存儲庫應該指定一個數據源作為單一的數據來源。
推薦閱讀
- 官網
- 官方Sample
總結
以上是生活随笔為你收集整理的Android Architecture Components的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： ODF光纤配线架
- 下一篇： Git Rebase vs Merge,