前言
今天突然想聊聊面试了,为什么要聊面试呢?因为最近有很多公众号和简书上的朋友跳槽让我看简历,也有很多朋友跟我吐槽说:面试又被虐了,火箭造的简直惨不忍睹,都有点怀疑自己的能力了。其实,我想说:正常,之所以这么说是很多朋友可能没有认清自己存在的一些问题。哪些问题呢?
两点:
-
**一是,**没有认清自己的技术实力,三天打鱼两天晒网的复习,对提升自己是没有任何一点效率的;
-
**二是,**去面试之前,没有真正了解公司。
其实说实话,我们作为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)]
当程序员容易,当一个优秀的程序员是需要不断学习的,从初级程序员到高级程序员,从初级架构师到资深架构师,或者走向管理,从技术经理到技术总监,每个阶段都需要掌握不同的能力。早早确定自己的职业方向,才能在工作和能力提升中甩开同龄人。