Android:四大架构的优缺点,你真的了解吗?

前言

你准备好了吗?本次列车开往 “重构” 之巅,时速 900km/s。风太大听不见,但我就是可以很简单很直的,给你讲述事物本质和解决方案!⚡

项目常用架构比对

以下,对常见的 MVC、MVP、Clean、AAC 架构做个比对。

首先,一张表格展示各架构的类冗余情况:

需求是,写三个页面,ListFragment、DetailFragment、PreviewFragment,每个页面至少用到 3个 Note 业务、3个 User 业务。问:上述架构分别需编写多少类?

架构 涉及类 类总数
MVC Fragment:3个,Controller:3个,Model:2个 8个
MVP Fragment:3个,Presenter:3个,Model:3个,Contract:1个 10个
Clean Fragment:3个,ViewModel:3个,Usecase:18个,Model:3个 27个
AAC Fragment:3个,ViewModel:3个,Model:3个 9个

MVC 架构的缺陷

  • View、Controller、Model 相互依赖,造成代码耦合。
  • 难以分工,难以将 View、Controller、Model 分给不同的人写。
  • 难以维护,没有中间件接口做缓冲,难以替换底层的实现。
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
public class NoteListFragment extends BaseFragment {

...

public void refreshList() {
new Thread(new Runnable() {
@Override
public void run() {

//view 中直接依赖 model。那么 view 须等 model 编写好才能开工。

mNoteList = mDataManager.getNoteList();
mHandler.sendMessage(REFRESH_LIST, mNoteList);
}
}).start();
}

private Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
switch (msg) {
case REFRESH_LIST:
mAdapter.setList(mNoteList);
mAdapter.notifyDataSetChanged();
break;
default:
}
}
};

...
}

MVP 架构的特点与局限

  • MVP 架构的特点是 面向接口编程。在 View、Presenter、Model 之间分别用 中间件接口 做衔接,当有新的底层实现时,能够无缝替换。
  • 此外,MVP 的 View 和 Model 并不相互依赖,因此可以说是对 View 和 Model 做了代码解耦。
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
public class NoteListContract {

interface INoteListView {

void showDialog(String msg);

void showTip(String tip);

void refreshList(List<NoteBean> beans);
}

interface INoteListPresenter {

void requestNotes(String type);

void updateNotes(NoteBean... beans);

void deleteNotes(NoteBean... beans);
}

interface INoteListModel {

List<NoteBean> getNoteList();

int updateNote(NoteBean bean);

int deleteNote(NoteBean bean);
}
}

但 MVP 架构有其局限性。按我的理解,MVP 设计的初衷是,“让天下没有难替换的 View 和 Model” 。该初衷背后所基于的假设是,“上层逻辑稳定,但底层实现更替频繁” 。在这个假设的引导下,Presenter 除了承担业务逻辑的责任,还越界接管了 UI逻辑,这使得 UI 和 业务发生了耦合

如此,一旦 UI 需求变化,UI 和 业务的编写者都会受到牵连,占据 2 份甚至更多工时。

且由于 UI 编写者的“权力上缴”,使得在 UI 编写完成后 无法独立完成单元测试。(因为此处缺少了 UI 逻辑 —— 总不能为了测试,而背着 Presenter 自己另外写一波吧。所以除了那种“上层逻辑稳定”的组件,无论从哪个角度来看,用 MVP 来架构项目,都是不合适的)

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
public class NoteListPresenter implements NoteListContract.INoteListPresenter {

private NoteListContract.INoteListModel mDataManager;
private NoteListContract.INoteListView mView;

@Override
public void requestNotes(String type) {
Observable.create(new ObservableOnSubscribe<List<NoteBean>>() {
@Override
public void subscribe(ObservableEmitter<List<NoteBean>> e) throws Exception {
List<NoteBean> noteBeans = mDataManager.getNoteList();
e.onNext(noteBeans);
}
}).subscribeOn(Schedulers.io()).observeOn(AndroidSchedulers.mainThread())
.subscribe(new Consumer<List<NoteBean>>() {
@Override
public void accept(List<NoteBean> beans) throws Exception {

//presenter 直接干预了 UI 在拿到数据后做什么,使得职责上没有发生解耦。

//正常来说,解耦意味着,presenter 的职能边界仅限返回结果数据,
//由 UI 来依据响应码处理 UI 逻辑。

mView.refreshList(beans);
}
});
}

...
}

Clean 架构的特点和不足

mvp_flow.png

为解决 Presenter 职能边界不明确 的问题,在 Clean 架构中,业务逻辑的职能被转移到领域层,由 Usecase 专职管理。Presenter 则弱化为 ViewModel ,作为代理数据请求,和衔接数据回调的缓冲区。

Clean 架构的特点是 单向依赖、数据驱动编程View -> ViewModel -> Usecase -> Model

View 对 ViewModel 的单向依赖,是通过 DataBinding 特性实现的。ViewModel 只负责代理数据请求,在 Usecase 处理完业务返回结果数据时,结果数据被赋值给可观察的 DataBinding 数据,而 View 则依据数据的变化而变化。

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
public class NoteListViewModel {

private ObservableList<NoteBean> mListObservable = new ObservableArrayList<>();

private void requestNotes(String type) {
if (null == mRequestNotesUsecase) {
mRequestNotesUsecase = new ProveListInitUseCase();
}

mUseCaseHandler.execute(mRequestNotesUsecase, new RequestNotesUsecase.RequestValues(type),
new UseCase.UseCaseCallback<RequestNotesUsecase.ResponseValue>() {
@Override
public void onSuccess(RequestNotesUsecase.ResponseValue response) {

//viewModel 的可观察数据发生变化后,databinding 会自动更新 UI 展示。

mListObservable.clear();
mListObservable.addAll(response.getNotes());
}

@Override
public void onError() {

}
});
}

...
}

但 Clean 架构也有不足:粒度太细 。一个 UseCase 受限于请求参数,因而只能处理一类请求。View 请求的数据包含几种类型,就至少需要准备几个 UseCase 。UseCase 是依据当前 View 对数据的需求量身定制的,因此 UseCase 的复用率极低,项目会因而急剧的增加类和重复代码

too_much_usecase.png

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
public class RequestNotesUseCase extends UseCase<RequestNotesUseCase.RequestValues, RequestNotesUseCase.ResponseValue> {

private DataManager mDataManager;

@Override
protected void executeUseCase(final RequestValues values) {
List<NoteBean> noteBeans = mDataManager.getNotes();
...
getUseCaseCallback().onSuccess(new RequestNotesUseCase.ResponseValue(noteBeans));
}

//每新建一个 UseCase 类,都需要手动为其配置 请求参数列表 和 响应参数列表。

public static final class RequestValues implements UseCase.RequestValues {
private String type;

public String getType() {
return type;
}

public void setType(String type) {
this.type = type;
}
}

public static final class ResponseValue implements UseCase.ResponseValue {

public List<NoteBean> mBeans;

public ResponseValue(List<NoteBean> beans) {
mBeans = beans;
}
}
}

AAC 架构的特点

AAC 也是数据驱动编程。只不过它不依赖于 MVVM 特性,而是直接在 View 中写个观察者回调,以接收结果数据并处理 UI 逻辑。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class NoteListFragment extends BaseFragment {

@Override
public void onActivityCreated(@Nullable Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
viewModel.getNote().observe(this, new Observer<NoteBean>() {
@Override
public void onChanged(@Nullable NoteBean bean) {
//update UI
}
});
}

...
}

你完全可以将其理解为 B/S 架构:由 Web 前端向 Web 后端发送了数据请求,后端在处理完毕后响应结果数据给前端,前端再依据需求处理 UI 逻辑。等于说, AAC 将业务完全压到了 “数据仓库层”

某“解耦分离”架构的由来及特点

公司项目的第三轮重构采用的是 Clean 架构,而我在业余时间又设计了一款“实现 UI 和业务分离”的某架构,于是向主管申请了 1 周时间,利用“某架构”将 60 个类的核心模块重构了一遍。(不要慌,该架构已开源,文末链接给出)。

该架构属于“消息驱动编程”,即借助“总线”来转发数据的请求和响应,实现 UI 和 业务的分离。

viabus_flow_cn.png

不同于以往的架构,该架构明确界定了什么是 UI,什么是业务。

UI 的作用是视觉交互,UI 的职责范围仅限于请求数据和处理 UI 逻辑 。业务的作用是供应数据,业务的职责范围仅限于接收请求、处理数据、返回结果数据

你看,就像前后端分离一样,UI 和业务,可以分别交由不同的人分工合作:

1.独立自主。 谁先完成了,就可以先独立的单元测试一把。

2.可持续发展。 由于相互独立,人们可以在各自的领域里深耕。比如写业务的人:

viabus_flow_line.png

第一轮,他可以简单的写写业务,目标是把数据给到位。

第二轮,他可以考虑改进业务逻辑、改进算法和数据结构,不仅将数据给到位,还优化了性能。

第三轮,他可以考虑安全性,将业务逻辑全部写进 C 层,这样反编译后除了 findViewById,啥 if else 也看不见,更别说篡改和破解了。

你看,解耦分离后,要想迭代和发展,就是这么轻松畅快。这要是放到代码耦合的项目中,是怎么也不敢想。

总结

综上,本文介绍了 4 个架构以及它们的优缺点。在实际项目开发中,可根据项目规模的大小、项目上层逻辑的稳定程度,来选择最合适的架构。

看完这篇文章,如你觉得有所收获和启发,请不吝点赞,你的点赞就是对我最大的支持!

更多访问

1分钟掌握 ViaBus 架构的使用
VIABUS - 年轻人的第一款架构
Android:你还在等那个,手把手带你重构的人出现吗?

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×