最新消息:欢迎访问Android开发中文站!商务联系微信:loading_in

[译] Android 架构:Part 1 —— 那些年我们犯过的错

开发进阶 loading 738浏览 0评论

本系列文章旨在概述我们搭建 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.使你的组件可测试

你应该尽可能地对你的 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<JSONObject>() {
           // MySingleton.getInstance(this).addToRequestQueue(jsObjRequest);
           // showData(user);
           return null;
       }
   }
}
复制代码

你可能在 “上古时代” 看到过这样的代码。如果没有,说明你很年轻。这是怎么回事?一切!

 


 

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

 


 

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

第二次迭代 —— MVP

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

 


 

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

 


 

译者注:黄色的标签表示好了些

第三次迭代 —— MVP + managers

当政府不知道做什么的时候它会做什么?它成立一个代理机构。当开发不知道做什么的时候他们会做什么?他们引入一些 Manager。你不一定把它命名为 “*Manager” 。 这些类有很多名字:uitls、helpers、fooBarBuzz-ator、等等。因此我们引入 Manager。

 


 

说实话,这甚至有点凑效。业务逻辑包含在 Manager 中。利益相关者知道往哪看,关注点一定程度是分离的但可以做得更好,你可以编写更多的测试,但你依然直接触摸 Android ,所以你必须编写 Android 测试用例,并预先填写数据库来测试业务逻辑,一个字:不爽。是的,Manager 有变成巨兽的倾向,很快就变得难以维护。你可能争论说它不会变得更复杂,你可以通过更简单的架构来更快地提供代码,但通过这种方法依然会有很多 BUG,可维护性也会遭到破坏。

 


 

译者注:留意 Manager this 和 Manager that 之间的标签

总结

在本系列的第一部分,我们经历了搭建实际可用的 Android 架构的挑战。良好的 Android 架构应该满足众多利益相关者的需求,支持关注点分离,强调业务逻辑,隐藏 Framework 的细节,并使你所有的组件都可以测试。在系列的第二部分,我们将向你展示我们如何管理对我们有用的功能。在此之前,你是否有如何创建合适的 Android 工作流的建议?或者你遇到了什么问题?

作者:非非白
链接:https://juejin.im/post/5d294182518825331d14cbae
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

转载请注明:Android开发中文站 » [译] Android 架构:Part 1 —— 那些年我们犯过的错

您必须 登录 才能发表评论!