上次分享也吐槽了Android之于单元测试的困难重重,原因也就不多说了详见Android 进行单元测试难在哪。Flux是前端的一个基于数据流的框架,做到层于层之间很好的分离。基于这个思想在Android做了验证,很好的支持了单元测试。
每一个应用都应该有一个架构
之前写代码的时候很少考虑架构这一块,一切都是围着需求去做。实现这个业务需要几个API、几张表、几个activity。然后吭哧吭哧就做了。其实一直觉得这样的开发很好,快速有效嘛。后来随着项目越来越大,发现有点不对事儿。代码难看不说,模块相互牵扯难以阅读调试,单元测试更是无法去写。
在网上找了一些重构的资料补补短,发现应用分两种,设计出来和生长出来的。请对比下图理解。

很难说魔都这个城市是合理的或者美的是吧。
前端开发框架Flux
这好像是最近比较火的前端开发框架,也是facebook搞出来的一套东西。然后看到有人将这套东西移植到Android用的还挺好。于是了解了一下!

其实Flux架构的核心在于数据,就是一个数据的流动解决方案。看上去挺简单的,正好消息中心面临改版,月饼节那两天在家就合计着在项目上将这一套架构实现了。
移植到消息中心
1、Flux是基于通知的。它先把一条数据的生命周期定义成不同的层。层于层之间通过Action解耦。所以首先我要引人EventBus。
1 2 3 4 5 6 7 8 9 10
| dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) compile 'de.greenrobot:eventbus:2.4.0'
testCompile "junit:junit:4.12" testCompile "org.assertj:assertj-core:1.7.0" testCompile('org.robolectric:robolectric:3.0-rc2') }
|
2、 定义Action。传递事件和内容的媒介。我们这样定义
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 class Action {
private final String type;
private final Object data;
public Action(String type, Object data) { this.type = type; this.data = data; }
public String getType() { return type; }
public Object getData() { return data; }
@Override public String toString() { return "Action{" + "type='" + type + '\'' + ", data=" + data + '}'; } }
|
3、定义Dispatcher 做任务分发
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
| public class Dispatcher {
private static Dispatcher instance; private final EventBus mEventBus;
protected Dispatcher(){ this.mEventBus = new EventBus(); }
public static Dispatcher getInstance(){ if (instance == null){ instance = new Dispatcher(); }
return instance; }
public void despatcher(String type,Object data){ mEventBus.post(new Action(type,data)); } public void emitChange(Store.StoreChangeEvent o){ mEventBus.post(o); }
public void error(String errorMessage){ mEventBus.post(new ErrorEvent(errorMessage)); }
public void register(Object subscriber){ mEventBus.register(subscriber); }
public void unregister(Object subscriber){ mEventBus.unregister(subscriber); } }
|
4、定义Store 做状态保持以及业务逻辑
1 2 3 4 5 6 7 8 9 10 11
| public class StoreMessageList extends Store{
public StoreMessageList(Dispatcher dispatcher) { super(dispatcher); }
public void onEvent(Action action){ } }
|
可测的Android代码
我的理解就是将业务逻辑完全的独立出来。一条数据从WebApi获取到之后,经过存储、读取、业务处理、展示。这是一个完整的生命周期。而这个过程中只有业务处理是复杂多变的,也只有这个过程才是有必要做单元测试的。 而这个架构正好做到了按照数据的生命周期分层,层于层之间通过EventBus解耦。是的store这个模块非常易于测试。
当然Flux的简单,易理解,易实现也是特点之一。以上都是个人的一切浅见,大家有时间也看看,有什么不同的见解多多交流。