细数Android开发者的艰辛历程：那些年我们都会犯的错-CSDN博客

本文链接：https://blog.csdn.net/2401_84008947/article/details/138686191

“When Google bought Android, I honestly think they treated it just as some other side project.”

可能你会说，你不必考虑太多架构和组织代码的事情，因为（Android）Framework 帮你做了。Android 强迫你把界面放到 Activity 中，可重用的界面放到 Fragment 中，后台服务放到 Service 中，并且用 Broadcast Receiver 和其它组件通信，这样可以使你的生活变得更美好，是这样吗？不是的。

首先，有一些很好的实践和原则确实很好，与技术（平台）无关。例如，单一职责原则，依赖倒置原则，面向接口编程，杀死全局状态，尝试消灭所有状态，等等。

Framework 很少强迫你遵循原则。恰恰相反，它们以最坏的方式侵犯这些最佳实践和原则。想想 Context 这个你到处使用的上帝对象（God object），各种单例管理者（singleton managers），拥有生命周期的 Fragment（那是怎样的噩梦呢），常常不能正确实现的 AsyncTask，它们吸着你 app 的血。

一个缺乏指导的刚入行的开发者很容易造出一个怪物而不是一个 app。把它想象成一个意大利面条般的怪物吧 —— 这是一个不错的怪物，但不是一个好的 app。

译者注：意大利面条般的怪物寓指一团乱麻的代码

最后，技术（technology）和 Framework 隐藏了 app 的用途。好的，这是一个 Android app，但是一个什么样的 Android app 呢？新闻阅读器？音乐播放器？语言学习程式？天气应用？也许是一个计划表。如果所有的东西都打包到由 Framework 提供的类，你就说不出（这是什么 app）。

正如 Robert Martin，也就是 Uncle Bob 说，“你的架构应该尖声喊出（scream）app 是做什么”，更技术一点说，业务逻辑应该清晰地分离，独立于 Framework。

Android 架构的四条黄金法

我希望已经说清楚了，你不应当依赖 Framework 来使你的代码整洁有序，尤其是在编写 Android 代码的时候。我们很早以前就意识到这点，可是缺乏拿出牛逼解决方案的经验。架构失败要花很多时间才能表现出来，又不可以在项目中途改变整个架构。也不可能有时间将旧项目重构成新的、酷的、（想成为）最佳的架构。因此，我们采取渐进的方法，慢慢地从一个项目到另一个项目搭建我们的架构，从我们的错误中学习。我们认为我们的架构应该满足几个目标，它们是检验我们的方法的标准。好的架构应该做到:

满足众多利益相关者的需求
支持关注点分离
逃离现实世界（Android、DB、Internet…）
使你的组件可测试

1.满足众多利益相关者

利益相关者（在这篇文章中）是任何对你的 app 开发感兴趣的人。除了开发，还有视觉设计师，交互设计师，项目经理，数据库管理员，测试等等。

当然，你不可能以某种方式组织你的代码，例如，交互设计师可以打开项目并立即了解所有内容，甚至可以进行一些修改。It’s a unicorn.

我的意思是，你可以以这样一种方式组织你的代码，那个和交互设计师对接的程序员只需要打理和交互相关的代码。因此，所有交互被分离到那些负责交互的 classes / modules / components / whatever （组件）中，当处理 app 的交互部分时，只需要打理那些组件。

译者注：如果暂时不能理解利益相关者，没关系的，看完本系列第三部分你就明白了

2.支持关注点分离

我刚刚所说的就是一个关注点分离的例子。我们支持这种特定的方法，因为它能很好地表达团队组织和项目阶段的配合，一般来说，你的架构也应该支持关注点分离。关注点分离或者单一职责原则是指，每一个组件应该只有一个变化的原因。

3.逃离真实世界（Android、DB、Internet…）

逃离真实世界这条规则，先前已经提及。我们曾说我们想要尖声喊出 app 真正是做什么的，就是那样。我们想要强调业务逻辑并且隐藏 Framework 的细节。这条规则应该更严格：不仅要隐藏 Framework 的细节，而且要隐藏所有与外部世界相关的细节。

所有的肮脏的 Android 的东西，如传感器、通知机制、屏幕细节、数据库访问、互联网访问等。

4.使你的组件可测试

你应该尽可能地对你的 app 进行单元测试，并且你的架构应该允许你这样做。如果你不能测试所有东西，你至少应该覆盖你的业务逻辑。与真实世界分离可以很方便地做到这点。如果你的业务逻辑清晰地和 app 其余部分隔离，是很容易测试的。

第一次迭代 —— 上帝 Activity

public final class UsersActivity extends ListActivity {

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
//…
new ListUsers().execute();
}

private final class ListUsers extends AsyncTask<Void, Void, Void> {

@Override
protected Void doInBackground(Void… voids) {
// final SQLiteOpenHelper sqLiteOpenHelper = …
// JsonObjectRequest jsObjRequest = new JsonObjectRequest
// (Request.Method.GET, url, null, new Response.Listener() {
// MySingleton.getInstance(this).addToRequestQueue(jsObjRequest);
// showData(user);
return null;
}
}
}

你可能在 “上古时代” 看到过这样的代码。如果没有，说明你很年轻。但是这一段代码哪里有问题呢？答案是哪里都有问题。

我们有一个 Activity 操作数据库，访问网络，解析数据，切换线程以及渲染数据。所有的利益相关者都在看这一个类，没有关注点是分离的，它是不可测试的，业务逻辑和 Android 的东西混杂在一起。

译者注：留意上图左边红色的标签。每个标签分别对应一条黄金法则，红色表示不满足。SRP 是指单一职责原则，即分离关注点。

第二次迭代 —— MVP

第一种方法显然是不能工作的。我们尝试过的第一件事情是 MVP，或者说 model-view-presenter。每个人都熟悉 MVP。它是最受欢迎的架构模式之一。看起来像这样：

这里，我们分离了实际上是 Android Fragment 的 View，我们拥有代表我们业务的（领域）模型，最后我们有协调一切的 Presenter。这肯定是更好的。关注点有了一些分离，利益相关者不再那么困惑，你也可以写一些单元测试了。尽管如此，由于 Presenter 直接操作数据库和所有一切，我们仍然和真实世界混杂在一起。Presenter 成了上帝对象。它处理模型，将数据发送到视图，它拥有业务逻辑（业务逻辑是那些齿轮 😃），它访问数据库和网络，获取传感器数据，等等。所以，是好了些，但可以更好。