電子發(fā)燒友App
? ? ? ?經(jīng)過一段時間收集了大量反饋意見后，我認為應(yīng)該來說說這個話題了。我會在這里給出我認為構(gòu)建現(xiàn)代移動應(yīng)用（Android）的好方法，這會是另一番體味。
開始之前，假設(shè)你已經(jīng)閱讀過我之前撰寫的文章“?Architecting Android…The clean way?”。如果還沒有閱讀過，為了更好地理解這篇文章，應(yīng)借此機會讀一讀：
架構(gòu)演變
演變意味著一個循序漸進的過程，由某些狀態(tài)改變到另一種不同的狀態(tài)，且新狀態(tài)通常更好或更復(fù)雜。
照這么一說，軟件是隨著時間發(fā)展和改變的，是架構(gòu)上的發(fā)展和改變。實際上，好的軟件設(shè)計必須能夠幫助我們發(fā)展和擴充解決方案，保持其健壯性，而不必每件事都重寫代碼（雖然在某些情況下重寫的方法更好，但是那是另一篇文章的話題，所以相信我，讓我們聚焦在前面所討論的話題上）。
在這篇文章中，我將講解我認為是必需的和重要的要點，為了保持基本代碼條理清晰，要記住下面這張圖片，我們開始吧！
響應(yīng)式方法：RxJava
因為已經(jīng)有很多這方面的文章，還有這方面做得很好、令人景仰的人，所以我不打算在這里討論RxJava的好處（我假設(shè)您已經(jīng)對它有所體驗了）。但是，我將指出在Android應(yīng)用程序開發(fā)方面的有趣之處，以及如何幫助我形成第一個清晰的架構(gòu)的方法。
首先，我選擇了一種響應(yīng)式的模式通過轉(zhuǎn)換usecase（在這個清晰的架構(gòu)命名規(guī)則中，其被稱為interactor）返回Observables，表示所有底層都遵循這一鏈條，也返回Observables 。
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
public abstract class UseCase {
private final ThreadExecutor threadExecutor;
private final PostExecutionThread postExecutionThread;
private Subscription subscription = Subscriptions.empty();
protected UseCase(ThreadExecutor threadExecutor,
PostExecutionThread postExecutionThread) {
this.threadExecutor = threadExecutor;
this.postExecutionThread = postExecutionThread;
}
protected abstract Observable buildUseCaseObservable();
public void execute(Subscriber UseCaseSubscriber) {
this.subscription = this.buildUseCaseObservable()
.subscribeOn(Schedulers.from(threadExecutor))
.observeOn(postExecutionThread.getScheduler())
.subscribe(UseCaseSubscriber);
}
public void unsubscribe() {
if (!subscription.isUnsubscribed()) {
subscription.unsubscribe();
}
}
}
正如你所看到的，所有用例繼承這個抽象類，并實現(xiàn)抽象方法buildUseCaseObservable()。該方法將建立一個Observables，它承擔(dān)了繁重的工作，還要返回所需的數(shù)據(jù)。
需要強調(diào)是，在execute()方法中，要確保Observables 是在獨立線程執(zhí)行，因此，要盡可能減輕阻止android主線程的程度。其結(jié)果就是會通過android主線程調(diào)度程序?qū)⒅骶€程壓入線程隊列的尾部（push back）。
到目前為止，我們的Observables啟動并且運行了。但是，正如你所知，必須要觀察它所發(fā)出的數(shù)據(jù)序列。要做到這一點，我改進了presenters（MVP模式表現(xiàn)層的一部分），把它變成了觀察者（Subscribers），它通過用例對發(fā)出的項目做出“react”，以便更新用戶界面。
觀察者是這樣的：
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
private final class UserListSubscriber extends DefaultSubscriber {
@Override public void onCompleted() {
UserListPresenter.this.hideViewLoading();
}
@Override public void onError(Throwable e) {
UserListPresenter.this.hideViewLoading();
UserListPresenter.this.showErrorMessage(new DefaultErrorBundle((Exception) e));
UserListPresenter.this.showViewRetry();
}
@Override public void onNext(List users) {
UserListPresenter.this.showUsersCollectionInView(users);
}
}
每個觀察者都是每個presenter的內(nèi)部類，并實現(xiàn)了一個Defaultsubscriber接口，創(chuàng)建了基本的默認錯誤處理。
將所有的片段放在一起后，通過下面的圖，你可以獲得完整的概念：
讓我們列舉一些擺脫基于RxJava方法的好處：
在觀察者（Subscribers）與被觀察者（Observables）之間去耦合：更加易于維護和測試。
簡化異步任務(wù)：如果要求多個異步執(zhí)行時，如果需要一個以上異步執(zhí)行的級別，Java的thread和future的操作和同步比較復(fù)雜，因此通過使用調(diào)度程序，我們可以很方便地（不需要額外工作）在后臺與主線程之間跳轉(zhuǎn)，特別是當(dāng)我們需要更新UI時。還可以避免“回調(diào)的坑”—— 它使我們代碼可讀性差，且難以跟進。
數(shù)據(jù)轉(zhuǎn)換/組成：在不影響客戶端情況下，我們能夠整合多個Observables，使解決方案更靈活。
錯誤處理：在任何Observables內(nèi)發(fā)生錯誤時，就向消費者發(fā)出信號。
從我的角度看有一點不足，甚至要為此需要付出代價，那些還不熟悉概念的開發(fā)人員還是要遵循學(xué)習(xí)曲線。但你從中得到了極有價值的東西。為了成功而reactive起來吧！
依賴注入：Dagger 2
關(guān)于依賴注入，因為我已經(jīng)寫了一篇完整的文章，我不想說太多。強烈建議你閱讀它，這樣我們就可以接著說下面的內(nèi)容了。
值得一提的是，通過實現(xiàn)一個像Dagger 2那樣的依賴注入框架我們能夠獲得：
組件重用，因為依賴的對象可以在外部注入和配置。
當(dāng)注入對象作為協(xié)作者（collaborators）時，由于對象的實例存在于在一個隔離和解耦地方，這樣在我們的代碼庫中，就不需要做很多的改變，就可以改變?nèi)魏螌ο蟮膶崿F(xiàn)。
依賴可以注入到一個組件：這些將這些模擬實現(xiàn)的依賴對象注入成為可能，這使得測試更容易。
Lambda表達式：Retrolambda
沒有人會抱怨在代碼中使用Java 8的lambada表達式，甚至在簡化并擺脫了很多樣板代碼以后，使用得更多，如你看到這段代碼：
Java
1
2
3
4
5
6
private final Action1 saveToCacheAction =
userEntity -> {
if (userEntity != null) {
CloudUserDataStore.this.userCache.put(userEntity);
}
};
然而，我百感交集，為什么呢？我們曾在@SoundCloud討論Retrolambada，主要是是否使用它，結(jié)果是：
1. 贊成的理由：
Lambda表達式和方法引用
“try-with-resources”語句
使用karma做開發(fā)
2. 反對的理由：
Java 8 API的意外使用
十分令人反感的第三方庫
要與Android一起使用的第三方插件Gradle
最后，我們認定它不能為我們解決任何問題：你的代碼看起來很好且具有可讀性，但這不是我們與之共存的東西，由于現(xiàn)在所有功能最強大的IDE都包含代碼折疊式選項，這就涵蓋這一需求了，至少是一個可接受的方式。
說實話，盡管我可能會在業(yè)余時間的項目中使用它，但在這里使用它的主要原因是嘗試和體驗Android中Lambda表達式。是否使用它由你自己決定。在這里我只是展示我的視野。當(dāng)然，對于這樣一項了不起的工作，這個庫的作者值得稱贊。
測試方法
在測試方面，與示例的第一個版本相關(guān)的部分變化不大：
表現(xiàn)層：用Espresso 2和Android Instrumentation測試框架測試UI。
領(lǐng)域?qū)樱篔Unit + Mockito —— 它是Java的標準模塊。
數(shù)據(jù)層：將測試組合換成了Robolectric 3 + JUnit + Mockito。這一層的測試曾經(jīng)存在于單獨的Android模塊。由于當(dāng)時（當(dāng)前示例程序的第一個版本）沒有內(nèi)置單元測試的支持，也沒有建立像robolectric那樣的框架，該框架比較復(fù)雜，需要一群黑客的幫忙才能讓其正常工作。
幸運的是，這都是過去的一部分，而現(xiàn)在所有都是即刻可用，這樣我可以把它們重新放到數(shù)據(jù)模塊內(nèi)，專門為其默認的測試路徑：src/test/java。
包的組織
我認為一個好的架構(gòu)關(guān)鍵因素之一是代碼/包的組織：程序員瀏覽源代碼遇到的第一件事情就是包結(jié)構(gòu)。一切從它流出，一切依賴于它。
我們能夠辨別出將應(yīng)用程序封裝進入包（package）的2個路徑：
按層分包：每一個包（package）中包含的項通常不是彼此密切相關(guān)的。這樣包的內(nèi)聚性低、模塊化程度低，包之間偶合度高。因此，編輯某個特性要編輯來自不同包的文件。另外，單次操作幾乎不可能刪除掉某個功能特性。
按特性分包：用包來體現(xiàn)特性集。把所有相關(guān)某一特性（且僅特性相關(guān)）的項放入一個包中。這樣包的內(nèi)聚性高，模塊化程度高，包之間偶合度低。緊密相關(guān)的項放在一起。它們沒有分散到整個應(yīng)用程序中。
我的建議是去掉按特性分包，會帶來的好處有以下主要幾點：
模塊化程度更高
代碼導(dǎo)航更容易
功能特性的作用域范圍最小化了
如果與功能特性團隊一起工作（就像我們在@SoundCloud的所作所為），也會是非常有趣的事情。代碼的所有權(quán)會更容易組織，也更容易被模塊化。在許多開發(fā)人員共用一個代碼庫的成長型組織當(dāng)中，這是一種成功。
如你所見，我的方法看起來就像按層分包：這里我可能會犯錯（例如，在“users”下組織一切），但在這種情況下我會原諒自己，因為這是個以學(xué)習(xí)為目的的例子，而且我想顯示的是清晰架構(gòu)方法的主要概念。領(lǐng)會其意，切勿盲目模仿:-)。
還需要做的事：組織構(gòu)建邏輯
我們都知道，房子是從地基上建立起來的。軟件開發(fā)也是這樣，我想說的是，從我的角度來看，構(gòu)建系統(tǒng)（及其組織）是軟件架構(gòu)的重要部分。
在Android平臺上，我們采用Gradle，它事實上是一種與平臺無關(guān)的構(gòu)建系統(tǒng)，功能非常強大。這里的想法是通過一些提示和技巧，讓你組織構(gòu)建應(yīng)用程序時能夠得到簡化。
在單獨的gradle構(gòu)建文件中按功能對內(nèi)容進行分組
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
def ciServer = 'TRAVIS'
def executingOnCI = "true".equals(System.getenv(ciServer))
// Since for CI we always do full clean builds, we don't want to pre-dex
// See http://tools.android.com/tech-docs/new-build-system/tips
subprojects {
project.plugins.whenPluginAdded { plugin ->
if ('com.android.build.gradle.AppPlugin'.equals(plugin.class.name) ||
'com.android.build.gradle.LibraryPlugin'.equals(plugin.class.name)) {
project.android.dexOptions.preDexLibraries = !executingOnCI
}
}
}
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
apply from: 'buildsystem/ci.gradle'
apply from: 'buildsystem/dependencies.gradle'
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:1.2.3'
classpath 'com.neenbedankt.gradle.plugins:android-apt:1.4'
}
}
allprojects {
ext {
...
}
}
...
因此，你可以用“apply from: ‘buildsystem/ci.gradle’”插入到任何Gradle建立的文件中進行配置。不要把所有都放置在一個build.gradle文件中，否則就是去創(chuàng)建一個怪物，這是教訓(xùn)。
創(chuàng)建依賴關(guān)系圖
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
...
ext {
//Libraries
daggerVersion = '2.0'
butterKnifeVersion = '7.0.1'
recyclerViewVersion = '21.0.3'
rxJavaVersion = '1.0.12'
//Testing
robolectricVersion = '3.0'
jUnitVersion = '4.12'
assertJVersion = '1.7.1'
mockitoVersion = '1.9.5'
dexmakerVersion = '1.0'
espressoVersion = '2.0'
testingSupportLibVersion = '0.1'
...
domainDependencies = [
daggerCompiler:???? "com.google.dagger:dagger-compiler:${daggerVersion}",
dagger:???????????? "com.google.dagger:dagger:${daggerVersion}",
javaxAnnotation:????"org.glassfish:javax.annotation:${javaxAnnotationVersion}",
rxJava:???????????? "io.reactivex:rxjava:${rxJavaVersion}",
]
domainTestDependencies = [
junit:??????????????"junit:junit:${jUnitVersion}",
mockito:????????????"org.mockito:mockito-core:${mockitoVersion}",
]
...
dataTestDependencies = [
junit:??????????????"junit:junit:${jUnitVersion}",
assertj:????????????"org.assertj:assertj-core:${assertJVersion}",
mockito:????????????"org.mockito:mockito-core:${mockitoVersion}",
robolectric:????????"org.robolectric:robolectric:${robolectricVersion}",
]
}
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
apply plugin: 'java'
sourceCompatibility = 1.7
targetCompatibility = 1.7
...
dependencies {
def domainDependencies = rootProject.ext.domainDependencies
def domainTestDependencies = rootProject.ext.domainTestDependencies
provided domainDependencies.daggerCompiler
provided domainDependencies.javaxAnnotation
compile domainDependencies.dagger
compile domainDependencies.rxJava
testCompile domainTestDependencies.junit
testCompile domainTestDependencies.mockito
}
如果想在項目的不同模塊間重用相同的組件版本，這很好；否則就要在不同的模塊間使用不同的版本的組件依賴。另外一點，你是在同一個地方控制依賴關(guān)系，像組件版本發(fā)生沖突這樣的事情一眼就能看出來。
結(jié)語
到目前為止講了那么多，一句話，要記住沒有靈丹妙藥。但好的軟件架構(gòu)會幫助代碼保持清晰和健壯，還可以保持代碼的可擴展性，易于維護。
我想指出一些事情。面對軟件存在的問題，要報以本應(yīng)當(dāng)解決的態(tài)度：
遵守SOLID原則
不要過度思考（不過度工程化）
務(wù)實
盡可能降低（Android）框架中模塊的依賴性
源代碼
Clean architecture github repository – master branch
Clean architecture github repository – releases
延伸閱讀
Architecting Android..the clean way
Tasting Dagger 2 on Android
The Mayans Lost Guide to RxJava on Android
It is about philosophy: Culture of a good programmer
RxJava wiki by Netflix
Framework bound by Uncle Bob
Gradle user guide
Package by feature, not layer
?
工商網(wǎng)監(jiān)
評論