我的意思是,你可以以这样一种方式组织你的代码,那个和交互设计师对接的程序员只需要打理和交互相关的代码。因此,所有交互被分离到那些负责交互的 classes / modules / components / whatever (组件)中,当处理 app 的交互部分时,只需要打理那些组件。
译者注:如果暂时不能理解利益相关者,没关系的,看完本系列第三部分你就明白了
II.支持关注点分离
我刚刚所说的就是一个关注点分离的例子。我们支持这种特定的方法,因为它能很好地表达团队组织和项目阶段的配合,一般来说,你的架构也应该支持关注点分离。关注点分离或者单一职责原则是指,每一个组件应该只有一个变化的原因。
III.逃离真实世界(Androi 《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》开源 d、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 JsonObje Android开源项目《ali1024.coding.net/public/P7/Android/git》 ctRequest
// (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 成了上帝对象。它处理模型,将数据发送到视图,它拥有业务逻辑(业务逻辑是那些齿轮 😃),它访问数据库和网络,获取传感器数据,等等。所以,是好了些,但可以更好。
译者注:黄色的标签表示好了些
第三次迭代 —— MVP + managers
当政府不知道做什么的时候它会做什么?它成立一个代理机构。当开发不知道做什么的时候他们会做什么?他们引入一些 Manager。你不一定把它命名为 “*Manager” 。 这些类有很多名字:uitls、helpers、fooBarBuzz-ator、等等。因此我们引入 Manager。
说实话,这甚至有点凑效。业务逻辑包含在 Manager 中。利益相关者知道往哪看,关注点一定程度是分离的但可以做得更好,你可以编写更多的测试,但你依然直接触摸 Android ,所以你必须编写 Android 测试用例,并预先填写数据库来测试业务逻辑,一个字:不爽。是的,Manager 有变成巨兽的倾向,很快就变得难以维护。你可能争论说它不会变得更复杂,你可以通过更简单的架构来更快地提供代码,但通过这种方法依然会有很多 BUG,可维护性也会遭到破坏。
结尾
我还总结出了互联网公司Android程序员面试涉及到的绝大部分面试题及答案,并整理做成了文档,以及系统的进阶学习视频资料分享给大家。
(包括Java在Android开发中应用、APP框架知识体系、高级UI、全方位性能调优,NDK开发,音视频技术,人工智能技术,跨平台技术等技术资料),希望能帮助到你面试前的复习,且找到一个好的工作,也节省大家在网上搜索资料的时间来学习。
家。
(包括Java在Android开发中应用、APP框架知识体系、高级UI、全方位性能调优,NDK开发,音视频技术,人工智能技术,跨平台技术等技术资料),希望能帮助到你面试前的复习,且找到一个好的工作,也节省大家在网上搜索资料的时间来学习。**
[外链图片转存中…(img-HWg5bTCG-1650012548536)]