Google 官方推出應用開發架構指南
簡評：雖然說 Android 的架構選擇一直都很自由，MVP、MVC、MVVM 各有擁躉。但 Google 最近還是推出了一份關于應用架構的實踐指南，并給出了相當詳盡的步驟和一些指導建議。希望大家都能看一看，學習一下，打造更加優秀易用的 APP，也為 Android 生態的改善做一點貢獻。: )
最近，官方推出了一份關于應用架構的最佳實踐指南。這里就給大家簡要介紹一下：
首先，Android 開發者肯定都知道 Android 中有四大組件，這些組件都有各自的生命周期并且在一定程度上是不受你控制的。在任何時候，Android 操作系統都可能根據用戶的行為或資源緊張等原因回收掉這些組件。
這也就引出了 第一條準則 ：「不要在應用程序組件中保存任何應用數據或狀態，并且組件間也不應該相互依賴」。
最常見的錯誤就是在 Activity 或 Fragment 中寫了與 UI 和交互無關的代碼。盡可能減少對它們的依賴，這能避免大量生命周期導致的問題，以提供更好的用戶體驗。
第二條準則：「通過 model 驅動應用 UI，并盡可能的持久化」。
這樣做主要有兩個原因：
- 如果系統回收了你的應用資源或其他什么意外情況，不會導致用戶丟失數據。
- Model 就應該是負責處理應用程序數據的組件。獨立于視圖和應用程序組件，保持了視圖代碼的簡單，也讓你的應用邏輯更容易管理。并且，將應用數據置于 model 類中，也更有利于測試。
官方推薦的 App 架構
在這里，官方演示了通過使用最新推出的 Architecture Components 來構建一個應用。
想象一下，您正在打算開發一個顯示用戶個人信息的界面，用戶數據通過 REST API 從后端獲取。
首先，我們需要創建三個文件：
- user_profile.xml：定義界面。
- UserProfileViewModel.java：數據類。
- 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);
}
}
注意其中的 ViewModel 和 LifecycleFragment 都是 Android 新引入的，可以參考 官方說明 進行集成。
現在，我們完成了這三個模塊，該如何將它們聯系起來呢？也就是當 ViewModel 中的用戶字段被設置時，我們需要一種方法來通知 UI。這就是 LiveData 的用武之地了。
引用
LiveData 是一個可被觀察的數據持有者（用到了觀察者模式）。其能夠允許 Activity, Fragment 等應用程序組件對其進行觀察，并且不會在它們之間創建強依賴。LiveData 還能夠自動響應各組件的聲明周期事件，防止內存泄漏，從而使應用程序不會消耗更多的內存。
注意： LiveData 和 RxJava 或 Agera 的區別主要在于 LiveData 自動幫助處理了生命周期事件，避免了內存泄漏。
所以，現在我們來修改一下 UserProfileViewModel：
public class UserProfileViewModel extends ViewModel {
...
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
});
}
獲取數據
現在，我們聯系了 ViewModel 和 Fragment，但 ViewModel 又怎么來獲取到數據呢？
在這個示例中，我們假定后端提供了 REST API，因此我們選用 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 直接來獲取數據，這里我們將工作轉交給一個新的 Repository 模塊。
引用
Repository 模塊負責數據處理，為應用的其他部分提供干凈可靠的 API。你可以將其考慮為不同數據源（Web，緩存或數據庫）與應用之間的中間層。
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;
}
}
管理組件間的依賴關系
根據上面的代碼，我們可以看到 UserRepository 中有一個 Webservice 的實例，不要直接在 UserRepository 中 new 一個 Webservice。這很容易導致代碼的重復與復雜化，比如 UserRepository 很可能不是唯一用到 Webservice 的類，如果每個用到的類都新建一個 Webservice，這顯示會導致資源的浪費。
這里，我們推薦使用 Dagger 2 來管理這些依賴關系。
現在，讓我們來把 ViewModel 和 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;
}
}
緩存數據
在實際項目中，Repository 往往不會只有一個數據源。因此，我們這里在其中再加入緩存：
@Singleton // informs Dagger that this class should be constructed once
public class UserRepository {
private Webservice webservice;
// simple in memory cache, details omitted for brevity
private UserCache userCache;
public LiveData<User> getUser(String userId) {
LiveData<User> cached = userCache.get(userId);
if (cached != null) {
return cached;
}
final MutableLiveData<User> data = new MutableLiveData<>();
userCache.put(userId, data);
// this is still suboptimal but better than before.
// a complete implementation must also handle the error cases.
webservice.getUser(userId).enqueue(new Callback<User>() {
@Override
public void onResponse(Call<User> call, Response<User> response) {
data.setValue(response.body());
}
});
return data;
}
}
持久化數據
現在當用戶旋轉屏幕或暫時離開應用再回來時，數據是直接可見的，因為是直接從緩存中獲取的數據。但要是用戶長時間關閉應用，并且 Android 還徹底殺死了進程呢？
我們目前的實現中，會再次從網絡中獲取數據。這可不是一個好的用戶體驗。這時就需要數據持久化了。繼續引入一個新組件 Room 。
引用
Room 能幫助我們方便的實現本地數據持久化，抽象出了很多常用的數據庫操作，并且在編譯時會驗證每個查詢，從而損壞的 SQL 查詢只會導致編譯時錯誤，而不是運行時崩潰。還能和上面介紹的 LiveData 完美合作，并幫開發者處理了很多線程問題。
現在，讓我們來看看怎么使用 Room 吧。: )
首先，在 User 類上面加上 @Entity，將 User 聲明為你數據庫中的一張表。
@Entity
class User {
@PrimaryKey
private int id;
private String name;
private String lastName;
// getters and setters for fields
}
再創建數據庫類并繼承 RoomDatabase：
@Database(entities = {User.class}, version = 1)
public abstract class MyDatabase extends RoomDatabase {
}
注意 MyDatabase 是一個抽象類，Room 會自動添加實現的。
現在我們需要一種方法來將用戶數據插入到數據庫：
@Dao
public interface UserDao {
@Insert(onConflict = REPLACE)
void save(User user);
@Query("SELECT * FROM user WHERE id = :userId")
LiveData<User> load(String userId);
}
再在數據庫類中加入 DAO：
@Database(entities = {User.class}, version = 1)
public abstract class MyDatabase extends RoomDatabase {
public abstract UserDao userDao();
}
注意上面的 load 方法返回的是 LiveData，Room 會知道什么時候數據庫發生了變化并自動通知所有的觀察者。這也就是 LiveData 和 Room 搭配的妙用。
現在繼續修改 UserRepository：
@Singleton
public class UserRepository {
private final Webservice webservice;
private final UserDao userDao;
private final Executor executor;
@Inject
public UserRepository(Webservice webservice, UserDao userDao, Executor executor) {
this.webservice = webservice;
this.userDao = userDao;
this.executor = executor;
}
public LiveData<User> getUser(String userId) {
refreshUser(userId);
// return a LiveData directly from the database.
return userDao.load(userId);
}
private void refreshUser(final String userId) {
executor.execute(() -> {
// running in a background thread
// check if user was fetched recently
boolean userExists = userDao.hasUser(FRESH_TIMEOUT);
if (!userExists) {
// refresh the data
Response response = webservice.getUser(userId).execute();
// TODO check for error etc.
// Update the database.The LiveData will automatically refresh so
// we don't need to do anything else here besides updating the database
userDao.save(response.body());
}
});
}
}
可以看到，即使我們更改了 UserRepository 中的數據源，我們也完全不需要修改 ViewModel 和 Fragment，這就是抽象的好處。同時還非常適合測試，我們可以在測試 UserProfileViewModel 時提供測試用的 UserRepository。
引用
下面部分的內容在原文中是作為附錄，但我個人覺得也很重要，所以擅自挪上來，一起為大家介紹了。: )
在上面的例子中，有心的大家可能發現了我們沒有處理網絡錯誤和正在加載狀態。但在實際開發中其實是很重要的。這里，我們就實現一個工具類來根據不同的網絡狀況選擇不同的數據源。
首先，實現一個 Resource 類：
//a generic class that describes a data with a status
public class Resource<T> {
@NonNull public final Status status;
@Nullable public final T data;
@Nullable public final String message;
private Resource(@NonNull Status status, @Nullable T data, @Nullable String message) {
this.status = status;
this.data = data;
this.message = message;
}
public static <T> Resource<T> success(@NonNull T data) {
return new Resource<>(SUCCESS, data, null);
}
public static <T> Resource<T> error(String msg, @Nullable T data) {
return new Resource<>(ERROR, data, msg);
}
public static <T> Resource<T> loading(@Nullable T data) {
return new Resource<>(LOADING, data, null);
}
}
因為，從網絡加載數據和從磁盤加載是很相似的，所以再新建一個 NetworkBoundResource 類，方便多處復用。下面是 NetworkBoundResource 的決策樹：
API 設計：
// ResultType: Type for the Resource data
// RequestType: Type for the API response
public abstract class NetworkBoundResource<ResultType, RequestType> {
// Called to save the result of the API response into the database
@WorkerThread
protected abstract void saveCallResult(@NonNull RequestType item);
// Called with the data in the database to decide whether it should be
// fetched from the network.
@MainThread
protected abstract boolean shouldFetch(@Nullable ResultType data);
// Called to get the cached data from the database
@NonNull @MainThread
protected abstract LiveData<ResultType> loadFromDb();
// Called to create the API call.
@NonNull @MainThread
protected abstract LiveData<ApiResponse<RequestType>> createCall();
// Called when the fetch fails. The child class may want to reset components
// like rate limiter.
@MainThread
protected void onFetchFailed() {
}
// returns a LiveData that represents the resource
public final LiveData<Resource<ResultType>> getAsLiveData() {
return result;
}
}
注意上面使用了 ApiResponse 作為網絡請求， ApiResponse 是對于 Retrofit2.Call 的簡單包裝，用于將其響應轉換為 LiveData。
下面是具體的實現：
public abstract class NetworkBoundResource<ResultType, RequestType> {
private final MediatorLiveData<Resource<ResultType>> result = new MediatorLiveData<>();
@MainThread
NetworkBoundResource() {
result.setValue(Resource.loading(null));
LiveData<ResultType> dbSource = loadFromDb();
result.addSource(dbSource, data -> {
result.removeSource(dbSource);
if (shouldFetch(data)) {
fetchFromNetwork(dbSource);
} else {
result.addSource(dbSource,
newData -> result.setValue(Resource.success(newData)));
}
});
}
private void fetchFromNetwork(final LiveData<ResultType> dbSource) {
LiveData<ApiResponse<RequestType>> apiResponse = createCall();
// we re-attach dbSource as a new source,
// it will dispatch its latest value quickly
result.addSource(dbSource,
newData -> result.setValue(Resource.loading(newData)));
result.addSource(apiResponse, response -> {
result.removeSource(apiResponse);
result.removeSource(dbSource);
//noinspection ConstantConditions
if (response.isSuccessful()) {
saveResultAndReInit(response);
} else {
onFetchFailed();
result.addSource(dbSource,
newData -> result.setValue(
Resource.error(response.errorMessage, newData)));
}
});
}
@MainThread
private void saveResultAndReInit(ApiResponse<RequestType> response) {
new AsyncTask<Void, Void, Void>() {
@Override
protected Void doInBackground(Void... voids) {
saveCallResult(response.body);
return null;
}
@Override
protected void onPostExecute(Void aVoid) {
// we specially request a new live data,
// otherwise we will get immediately last cached value,
// which may not be updated with latest results received from network.
result.addSource(loadFromDb(),
newData -> result.setValue(Resource.success(newData)));
}
}.execute();
}
}
現在，我們就能使用 NetworkBoundResource 來根據不同的情況獲取數據了：
class UserRepository {
Webservice webservice;
UserDao userDao;
public LiveData<Resource<User>> loadUser(final String userId) {
return new NetworkBoundResource<User,User>() {
@Override
protected void saveCallResult(@NonNull User item) {
userDao.insert(item);
}
@Override
protected boolean shouldFetch(@Nullable User data) {
return rateLimiter.canFetch(userId) && (data == null || !isFresh(data));
}
@NonNull @Override
protected LiveData<User> loadFromDb() {
return userDao.load(userId);
}
@NonNull @Override
protected LiveData<ApiResponse<User>> createCall() {
return webservice.getUser(userId);
}
}.getAsLiveData();
}
}
到這里，我們的代碼就全部完成了。最后的架構看起來就像這樣：
最后的最后，給出一些指導原則
下面的原則雖然不是強制性的，但根據我們的經驗遵循它們能使您的代碼更健壯、可測試和可維護的。
- 所有您在 manifest 中定義的組件 - activity, service, broadcast receiver… 都不是數據源。因為每個組件的生命周期都相當短，并取決于當前用戶與設備的交互和系統的運行狀況。簡單來說，這些組件都不應當作為應用的數據源。
- 在您應用的各個模塊之間建立明確的責任邊界。比如，不要將與數據緩存無關的代碼放在同一個類中。
- 每個模塊盡可能少的暴露內部實現。從過去的經驗來看，千萬不要為了一時的方便而直接將大量的內部實現暴露出去。這會讓你在以后承擔很重的技術債務（很難更換新技術）。
- 在您定義模塊間交互時，請考慮如何使每個模塊盡量隔離，通過設計良好的 API 來進行交互。
- 您應用的核心應該是能讓它脫穎而出的某些東西。不要浪費時間重復造輪子或一次次編寫同樣的模板代碼。相反，應當集中精力在使您的應用獨一無二，而將一些重復的工作交給這里介紹的 Android Architecture Components 或其他優秀的庫。
- 盡可能持久化數據，以便您的應用在脫機模式下依然可用。雖然您可能享受著快捷的網絡，但您的用戶可能不會。
引用
另外，Kotlin 版本的多個官方 Sample 也公布啦，感興趣的同學趕緊去看看吧： Android Kotlin Samples