Android 架构分享— 那些年我们犯过的错，2022年Android阿里&腾讯&百度&字节校招面试汇总

前言

今天突然想聊聊面试了，为什么要聊面试呢？因为最近有很多公众号和简书上的朋友跳槽让我看简历，也有很多朋友跟我吐槽说：面试又被虐了，火箭造的简直惨不忍睹，都有点怀疑自己的能力了。其实，我想说：正常,之所以这么说是很多朋友可能没有认清自己存在的一些问题。哪些问题呢？

两点：

• **一是，**没有认清自己的技术实力，三天打鱼两天晒网的复习，对提升自己是没有任何一点效率的；

• **二是，**去面试之前，没有真正了解公司。

其实说实话，我们作为Android程序员，最起码得有 80% 的人都想进入大公司工作，比如：BAT ，小米，滴滴，今日头条，美团，华为等这样的大公司或者移动互联网界的明星企业。

进大公司的好处显而易见，福利好，待遇高，工作稳定，不像很多创业小公司说倒闭就倒闭，尤其是移动互联网进入下半场之后，很多创业公司都相继倒闭，而且Android开发者也越来越饱和，随着Android程序员越来越多，自然就进入了激烈竞争的恶劣环境，优胜劣汰的自然规律是不可逃避，也规避不了的。

所有的肮脏的 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 成了上帝对象。它处理模型，将数据发送到视图，它拥有业务逻辑（业务逻辑是那些齿轮 😃），它访问数据库和网络，获取传感器数据，等等。所以，是好了些，但可以更好。

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

第三次迭代 —— MVP + managers

---

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

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

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

总结

–

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

[原文链接](()

最后

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》开源

Android优秀开源项目：

• ali1024.coding.net/public/P7/Android/git

写在最后

最后我想说：对于程序员来说，要学习的知识内容、技术有太多太多，要想不被环境淘汰就只有不断提升自己，从来都是我们去适应环境，而不是环境来适应我们！

这里附上上述的技术体系图相关的几十套腾讯、头条、阿里、美团等公司2021年的面试题，把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，这里以图片的形式给大家展示一部分。

相信它会给大家带来很多收获：

当程序员容易，当一个优秀的程序员是需要不断学习的，从初级程序员到高级程序员，从初级架构师到资深架构师，或者走向管理，从技术经理到技术总监，每个阶段都需要掌握不同的能力。早早确定自己的职业方向，才能在工作和能力提升中甩开同龄人。
转存中…(img-FRUYWhu9-1649660030824)]

[外链图片转存中…(img-itKwFcrZ-1649660030825)]

当程序员容易，当一个优秀的程序员是需要不断学习的，从初级程序员到高级程序员，从初级架构师到资深架构师，或者走向管理，从技术经理到技术总监，每个阶段都需要掌握不同的能力。早早确定自己的职业方向，才能在工作和能力提升中甩开同龄人。