Android 应用架构—— 那些因为年轻犯的错

本系列文章旨在概述我们搭建 Android 应用程序架构时可能会碰到的问题。我意识到，无论实现 Android app 架构的过程多么困难，结果证明这些一定是完成每一个卓越的应用的基础。

每种技术都有其自然的进化。或者更确切地说，它的社区经历了进化的过程。一个新的计算机语言或框架的早期采用者是爱好者，他们只是希望掌握技术，并尽快完成一些工作。通常，新社区规模小，在开发人员之间的知识传递潜力有限，也就是说，每个人都从自己的错误中学习，因为没有架构指南可用。

前言

早期 Android 们的痛点：谷歌是否关心?

你可以说，有很多资深的家伙在不同的技术上有很多的经验，但谁也没有时间提出标准。嗯，不一定。如果技术背后有一个强大的公司指望赚钱，他们的布道师会告诉你这个新语言多么酷，可以做很多事情，容易学习，可扩展，并且可以满足数以百万计的用户。

微软就经常用它的技术干这样的事情。另一方面，当谷歌收购了 Android， 我真的以为他们只是把它当作一个无关紧要的项目。如果你从 Android 诞生之时就进入 Android 的世界，你一定记得 Google 根本不在乎你的那种沮丧感。那些有额外的经验，能力和帮助社区的意愿的少数几个人现在是 Android 的超级明星或大神 —— 譬如 Jake Wharton。

“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 代码的时候。我们很早以前就意识到这点，可是缺乏拿出牛逼解决方案的经验。架构失败要花很多时间才能表现出来，又不可以在项目中途改变整个架构。也不可能有时间将旧项目重构成新的、酷的、(想成为)最佳的架构。因此，我们采取渐进的方法，慢慢地从一个项目到另一个项目搭建我们的架构，从我们的错误中学习。我们认为我们的架构应该满足几个目标，它们是检验我们的方法的标准。好的架构应该做到:

1. 满足众多利益相关者的需求
2. 支持关注点分离
3. 逃离现实世界(Android、DB、Internet...)
4. 使你的组件可测试

I.满足众多利益相关者

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

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

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

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

II.支持关注点分离

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

III.逃离真实世界(Android、DB、Internet...)

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

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

IV.使你的组件可测试

（编辑：开发网_开封站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!