Android 项目开发整体架构设计与演进

在传统的写法中，一般在 Activity/Fragment 中缓存 page、totalPage、pageSize 去进行分页请求，根据请求结果刷新数据并判断是否还有更多；每一个分页接口都要写一遍，假如把这段逻辑放到 DataManager 会怎么样？我是这么写的：

// 定义回调接口
public interface ActionCallback<T> {
    void onSuccess(T data);
    void onFailure(String message, Throwable e);
}

// 分页加载 DataManager 实现
public class PageLoadDataManager extends BaseDataManager {
    private static final int PAGE_COUNT = 20;
    private List<Data> mDataList = new ArrayList<>();
    private int currentPage = 0;
    private int totalPage = 0;

    public PageLoadDataManager() {
        // init something......
    }

    public void loadData(final boolean refresh, ActionListener<Boolean> listener) {
        if (refresh) {
            currentPage = 0;
        }
        currentPage++;
        RequestParams params = new RequestParams();
        params.put("page", currentPage);
        Request request = new Request(url, params);
        request.request(new RequestCallback() {
            @Override
            public void onSuccess(JSONObject data) {
                if (refresh) {
                    mDataList.clear();
                }
                totalPage = response.optInt("total_page");
                // 返回数据添加到 mDataList ......
                if (listener != null) {
                    boolean hasMore = currentPage <= totalPage;
                    listener.onSuccess(hasMore);
                }
            }

            @Override
            public void onFailure(String message, Throwable e) {
                if (listener != null) {
                    listener.onFailure(message, e);
                }
            }
        });
    }

    public List<Data> getDataList() {
        return mDataList;
    }
}

Activity/Fragment 初始化 DataManager 之后，只需要将数据源绑定到 Adapter，loadData 设置的回调告诉上层还有没有更多数据，UI 层调用 adapter.notifyDataSetChanged()；至于数据从哪来，分页逻辑，根本不需要 UI 层管理。UI 层只需要通过 loadData(refresh)，告诉 DataManager 是否需要重新加载分页，与下拉刷新的逻辑完美契合。

当然，在此基础上实现数据库缓存读写，也毫无压力。DataManager 也很容易实现对某一数据的多个接口的统一管理，通过单例模式或者其他管理方法，将数据配发给多个页面。

• 优点：大幅减轻 Activity/Fragment 的压力，实现数据统一管理，DataManager 层成为了一个 UI 无关的 AppSDK 层。
• 缺点：需要添加嵌套回调，这个问题在引入 RxJava 之后被完美处理。

其实到了这一步，已经能满足大多数几万行代码规模中小 App 的框架需求了，而且分层架构统一处理数据以及代码复用度高的特点，使得项目中按照框架思路实现业务成为最快速可靠的开发方法。

一个优秀的框架，很重要的特性就是方便业务开发而不是给开发找麻烦，比如在分层设计过后，就算开发时间再紧张，依托分层框架依然是最快最保险的开发方法。假如某个接口直接在 UI 中写了，就意味着数据管理层提供的一切便利都无法直接使用，而且假如其他 UI 用到这个接口，还得再复制粘贴一遍改来改去。相反，依托框架，网络调用只实现一遍，上层即可重复使用这一业务接口（比较典型的：关注、收藏等）。

即便如此，项目规模进一步往上之后，DataManager、Activity/Fragment 的压力仍然会增大，更高的测试需求，要求进一步分离 Activity/Fragment 的代码。这时候就可以看看 MVP 和 MVVM 了。

3. MVP 架构

MVC 的 C 是即持有具体 Model，又持有具体 View，所以 C 很臃肿，分层架构就算抽出了 DataManager，实质上仍然是一个 MVC 架构，而 MVP 和 MVVM 则是 C 持有具体 View 这个问题做了点文章，其中MVP 就是将大量的 View <-> Model 交互剥离出来交由 Presenter，Presenter 持有抽象的 View。

Presenter 听起来很吊，主导者啊，但是没有 Activity 和 Fragment 的资源啊，我要怎么才能让它主导？需要获取系统的一些信息（需要 Context）的时候怎么办？不持有 Context 难道再开接口吗？写这么多接口，接口实现，Presenter，多写了几百行代码 n 个类，就为了把 1~200 行代码从 Activity 移出去？还是放弃吧……后来 Google 出了 TODO-MVP，但是发现跟上面那种 Demo 写法一样很麻烦，我也没有实际运用。后来反编译了某个大型 App，发现其正好是 MVP 架构，于是仔细看了一下代码，就如同我最开始的想法，一个 IXXView 有多少功能就写多少接口。再看看 Presenter 的实现，我忽然就明白我为什么会感觉不实用了.

任何想要构建一个其他什么东西取代 Activity/Fragment 地位的尝试都是自找麻烦

MVP 正是一个典型。

既然 MVP 把 Activity/Fragment 抽象为 View，那么就意味着当它作为一个抽象 View 去使用的时候，生命周期、Context 这些极其重要的资源 Presenter 是看不到的，但是这些东西是不可能不使用的。为了能让 Presenter 使用到这些，Presenter 就必须持有 Context，绑定 Activity、Fragment 的生命周期，就算如此，在一些需要确定使用 Activity、Fragment 的场合，仍需要使用强制转型。

正因为 Presenter 这个'主导'，导致 Presenter 和 Activity/Fragment 高度绑定，Presenter 和 IXXView，没有什么复用性。

4. MVVM 架构

MVVM 相比于 MVP，最重要的一个概念就是'数据绑定'，Presenter 还持有抽象的 View，ViewModel 连这个都不需要，View 通过 ViewModel 订阅其所需的数据源，ViewModel 向 View 提供改变数据的接口，当 View 的操作引起数据改变或者数据源发生改变时，ViewModel 通过订阅告知 View，View 进行视图更新。 这就是 MVVM 吸引人的地方，ViewModel 只提供数据订阅和数据接口，做到了与 UI 分离，ViewModel 体量比 Presenter 小，复用性要比 Presenter 强太多，而且基于分层架构可以做到小幅修改就能实现。唯一的痛点在于：如何实现数据绑定？

之前提到的 data-binding，并不是那么如意，而这次 Google I/O 2017 放出的 android-architecture-components 则很好的解决了这个问题。

ViewModel 组件规范了 ViewModel 的所处地位，生命周期，生成方式，以及一个 Activity 下多个 Fragment 共享 ViewModel 数据的问题。 LiveData 组件则提供了在 Java 层面 View 订阅 ViewModel 数据源的实现方案，很轻量。

4.1 ViewModel 的使用

ViewModel 的设计初衷是为了在配置更改（如屏幕旋转）期间保存数据。它通过继承 androidx.lifecycle.ViewModel 类来实现。

public class MyViewModel extends ViewModel {
    private MutableLiveData<String> mText;

    public LiveData<String> getText() {
        if (mText == null) {
            mText = new MutableLiveData<>();
        }
        return mText;
    }

    public void doSomething() {
        mText.setValue("New Value");
    }
}

4.2 LiveData 的优势

LiveData 是一种可观察的数据持有类，它具有生命周期感知能力，能够确保界面状态正确更新。当 LifecycleOwner 处于活跃状态时，LiveData 才会通知观察者更新。

public class MainActivity extends AppCompatActivity {
    private MyViewModel model;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        model = new ViewModelProvider(this).get(MyViewModel.class);

        model.getText().observe(this, new Observer<String>() {
            @Override
            public void onChanged(@Nullable String s) {
                textView.setText(s);
            }
        });
    }
}

ViewModel 的引入能够很好应对 Activity 销毁重建时大规模数据的恢复问题，以及多个界面依赖一个接口返回数据的场景，在这两个组件的规范下实现 MVVM 架构会十分容易，而且十分有意义。

5. 架构选型建议

在实际项目中，选择哪种架构取决于项目的规模、团队的技术栈以及维护成本。

1. 小型项目：MVC 或简单的分层架构即可满足需求，避免过度设计。
2. 中型项目：推荐分层架构 + MVP 或 MVVM，提高代码复用性和可测试性。
3. 大型项目：强烈推荐使用 MVVM + Clean Architecture，配合 Jetpack 组件库，确保代码的清晰度和可维护性。

无论选择哪种架构，核心原则都是解耦。将 UI 逻辑、业务逻辑和数据存储分离，才能让项目随着业务发展而保持健康。

结语

在技术领域内，没有任何一门课程可以让你学完后一劳永逸，只有不断提升才能不被时代淘汰。选择合适的架构模式，结合具体的业务场景，才是王道。