一个缺乏指导的刚入行的开发者很容易造出一个怪物而不是一个 app。把它想象成一个意大利面条般的怪物吧 —— 这是一个不错的怪物,但不是一个好的 app。
译者注:意大利面条般的怪物寓指一团乱麻的代码
最后,技术(technology)和 Framework 隐藏了 app 的用途。好的,这是一个 Android app,但是一个什么样的 Android app 呢?新闻阅读器?音乐播放器? 语言学习程式?天气应用?也许是一个计划表。如果所有的东西都打包到由 Framework 提供的类,你就说不出(这是什么 app)。
正如 Robert Martin,也就是 Uncle Bob 说,“你的架构应该尖声喊出(scream)app 是做什么”,更技术一点说,业务逻辑应该清晰地分离,独立于 Framework。
Android 架构的四条黄金法则
我希望已经说清楚了,你不应当依赖 Framework 来使你的代码整洁有序,尤其是在编写 Android 代码的时候。我们很早以前就意识到这点,可是缺乏拿出牛逼解决方案的经验。架构失败要花很多时间才能表现出来,又不可以在项目中途改变整个架构。也不可能有时间将旧项目重构成新的、酷的、(想成为)最佳的架构。因此,我们采取渐进的方法,慢慢地从一个项目到另一个项目搭建我们的架构,从我们的错误中学习。我们认为我们的架构应该满足几个目标,它们是检验我们的方法的标准。好的架构应该做到:
-
满足众多利益相关者的需求
-
支持关注点分离
-
逃离现实世界(Android、DB、Internet…)
-
使你的组件可测试
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() {
// MySingleton.getInstance(this).addToRequestQueue(jsObjRequest);
// showData(user);
return null;
}
}
}
你可能在 “上古时代” 看到过这样的代码。如果没有,说明你很年轻。但是这一段代码哪里有问题呢?答案是哪里都有问题。
我们有一个 Activity 操作数据库,访问网络,解析数据,切换线程以及渲染数据。所有的利益相关者都在看这一个类,没有关注点是分离的,它是不可测试的,业务逻辑和 Android 的东西混杂在一起。
译者注:留意上图左边红色的标签。每个标签分别对应一条黄金法则,红色表示不满足。SRP 是指单一职责原则,即分离关注点。
第二次迭代 —— MVP
第一种方法显然是不能工作的。我们尝试过的第一件事情是 MVP,或者说 model-view-presenter。每个人都熟悉 MVP。它是最受欢迎的架构模式之一。看起来像这样:
这里,我们分离了实际上是 Android Fragment 的 View,我们拥有代表我们业务的(领域)模型,最后我们有协调一切的 Presenter。这肯定是更好的。关注点有了一些分离,利益相关者不再那么困惑,你也可以写一些单元测试了。尽管如此,由于 Presenter 直接操作数据库和所有一切,我们仍然和真实世界混杂在一起。Presenter 成了上帝对象。它处理模型,将数据发送到视图,它拥有业务逻辑(业务逻辑是那些齿轮 😃),它访问数据库和网络,获取传感器数据,等等。所以,是好了些,但可以更好。
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数Android工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Android移动开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且后续会持续更新
如果你觉得这些内容对你有帮助,可以添加V获取:vip204888 (备注Android)
分享读者
作者2013年java转到Android开发,在小厂待过,也去过华为,OPPO等大厂待过,18年四月份进了阿里一直到现在。
被人面试过,也面试过很多人。深知大多数初中级Android工程师,想要提升技能,往往是自己摸索成长,不成体系的学习效果低效漫长,而且极易碰到天花板技术停滞不前!
我们整理了一份阿里P7级别的Android架构师全套学习资料,特别适合有3-5年以上经验的小伙伴深入学习提升。
主要包括腾讯,以及字节跳动,阿里,华为,小米,等一线互联网公司主流架构技术。
如果你觉得自己学习效率低,缺乏正确的指导,可以一起学习交流!
我们致力打造一个平等,高质量的Android交流圈子,不一定能短期就让每个人的技术突飞猛进,但从长远来说,眼光,格局,长远发展的方向才是最重要的。
35岁中年危机大多是因为被短期的利益牵着走,过早压榨掉了价值,如果能一开始就树立一个正确的长远的职业规划。35岁后的你只会比周围的人更值钱。
。
[外链图片转存中…(img-nuJcinxC-1712067989061)]
如果你觉得自己学习效率低,缺乏正确的指导,可以一起学习交流!
我们致力打造一个平等,高质量的Android交流圈子,不一定能短期就让每个人的技术突飞猛进,但从长远来说,眼光,格局,长远发展的方向才是最重要的。
35岁中年危机大多是因为被短期的利益牵着走,过早压榨掉了价值,如果能一开始就树立一个正确的长远的职业规划。35岁后的你只会比周围的人更值钱。