本文链接：https://blog.csdn.net/m0_65322636/article/details/122628240

“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。

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

/w/1240)

最后，技术（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 的东西混杂在一起。