Android 开发者成神之路_浏览器插件

一个 Android 技术专家，至少有 2～3 个专业领域。

作者 | Vasiliy Zukanov，已获翻译授权

译者 | 罗昭成，Android 开发者

责编 | 唐小引

出品 | CSDN（ID：CSDNnews）

许多 Android 开发者经常会问我，要学会哪些东西才能成为一个优秀的 Android 工程师？对于这个问题，他们的描述或多或少都有些差异，但是，总体来说，我们都需要学习一系列的技能，才能成为一个优秀的 Android 工程师。

在我看来，存在这样的困惑是正常的。Android 是一个巨大并且动态的生态系统，你可能需要花好几周时间去了解并学习它相关的一些工具和概念，但是最后你会发现，它们有好多都不是很重要，或者说并不是非常有用。因此，在本文中，我将分享我在 Android 开发中所使用到的重要技能，希望能够帮到你，让你把你的精力集中到重要的事情上。

当然，如果你是一个经验丰富的 Android 开发者，这些知识可能你都知道。有很多技能和观点都需要很多基础知识的沉淀，当你没有足够的经验的时候，很难看到这些技能点。文中，我不可能列出所有 Android 开发者都需要的技能。所以，我根据不同的经验，将这些知识点进行了粗略分组。请注意，这只是一个粗略的分组，并不一定是很精确的。

写在前面

如果你只是一个想成为 Android 开发者的人，并且还没有写过任何应用，那么这篇文章对你来说，还有点太早。本文主要是为了帮助开发者成为一个更专业的人。

本文，我会给你很多建议，不会让你空手而归。文章中列出了如何在短时间成为一个专业的开发者。读完文章，需要你自己去练习，并时常回来看看这些技能。

在本文开始之前，我就当你已经在 Google Play 发布过 Android 应用并且使用 GitHub 来进行源码管理。

0-2 年开发经验

Android 是一个非常复杂的框架，它拥有陡峭的学习曲线。有一些复杂的概念的确是 Native 的 Android 开发者需要学习的，但另一部分却是由于 Android 的原因，造成了它的复杂度。

当你向专业进军时，除了你的软件开发工作以外，你应该学习 Android 框架，忘记语言、架构、流行的开源库，专注于核心概念，并进行深入的研究。

具体来说，我建议你更多的了解以下内容：

Android 内存管理和进程调度

当面临「Low Memory Killer」的时候，如何保证你的应用程序稳定可靠的运行？这是一件很复杂的事情。长话短说，当用户切换到其它应用时，你应用的生命周期就会被打乱，但是当用户过一会儿重新切换回来的时候，用户却希望你的应用程序像任何事情都没有发生过一样，正常运行。

在本文中，我并不会介绍内存管理的任何细节，如果你想了解它们，可以看看这篇文章。

生命周期

如果有人要我说出 Android 应用程序中的复杂度和 Bug 的主要来源，我会立马大声告诉他是“生命周期”（然后捂住脸哭）。

Application、Activity、Fragment、Service、BroadcastReceiver、ContentProvider 和一些 Android 框架的核心组件，都拥有复杂的生命周期，并且它们的生命周期还不一样。如果你觉得这还不够多，Google 也一直在推出新的库和框架，这些库都有自己的复杂性和独立的生命周期。Loader, ViewModel 和 LiveData 都是为了解决这些问题而推出的。

有件有意思的事情，我从来没有看到过任何有关“生命周期“的定义。我们一直在使用它，但是它到底是什么意思呢？据我所知，在某种程度上，你只是把一些节点串联在一起，构建出一个生命周期的图。我对生命周期有过很多的思考，在这里，我将尝试对它进行定义。

组件的生命周期是一个抽象的状态机。这里的抽象的意思是指，这些状态机的状态是预先定义好的，它们之间的转换条件也是定义好的。但是这些定义是不完整的。你需要去实现缺少的部分，使他们可以正常工作。这些缺少的部分是这些组件方法的子集，我们称其为“生命周期回调”，除了状态机本身之外，这些生命周期回调中，也有很多隐式的限制和约束。这些限制有些写在了文档中，而有些却并没有记录。

生命周期到底有多复杂？我们先来看一下这张图 (它有点不完整，还有点过时)。这张图，看起来有点可怕。不过，你也不要慌，大多数 Andorid 开发者都搞不明白这个图。事实上，即使 Google 的 Android 开发者也搞不明白生命周期的问题。Google 在发布 Lifecycle 组件的时候，里面引入了一些有关 Fragment 的 bug，直到后续的新版本发布了才得以修复。

虽然现在你不需要完全掌握 Android 的生命周期，但是你必须要知道一些重要的细节。否则，你的代码会变得混乱不堪，并且容易出现一系列难以解决的问题。我写了两篇文章 Activity 生命周期与 Fragment 生命周期，描述了生命周期的细节。当你不知道如何使用 onStart 和 onResume 时，你可以去看看这两篇文章。

当你掌握了生命周期的基础知识，你可以去看看 Gabor Varadi 写的 Android 开发的十宗罪，这篇文章，列举出了大多数开发者都会犯的错误。这些错误大多数都与生命周期有关。

顺便说一下，在面试中，生命周期相关的问题也会被经常问到。这也是你必须好好学习生命周期的原因。

Context

在每一个 Android 应用程序中，都有一个或多个上下文对象。

和生命周期一样，它也很难被解释。它就像是一个“上帝类“一样，它有非常多的能力。我们很难用一两句话就把它描述清楚。尽管如此，理解 Context 职责和不同 Context 之前的区别也是非常重要的。

本文中，没有更多关于 Context 的内容，我建议你去读一下 StackOverflow 中关于《What is 'Context' on Android?》的回答和这个回答的内容.

UI 线程

每一个 Android 应用程序都有一个特殊的线程 —— UI 线程。这一个线程在屏幕上绘制出 UI 页面。如果你让 UI 线程超负荷运行，你的应用程序将会变得卡顿，不响应。在极端情况下，UI 线程中的错误会导致整个应用程序出错（至少看起来像是出错了）。

如果你想详细了解线程背后的机制原理，你可以去看这个视频，视频中详细解释了 Android 中的多线程，包含 UI 线程的相关细节和可能存在的问题。

逻辑拆分

从整体上说，Android 框架的代码很不“整洁”。它包含着很多的上帝类，这些类中，每一个有数千行代码，并且我们还必须去扩展这些类，才能让我们的应用程序运行起来。在多数情况下，不管是 Application, Activity ，Fragments 还是 Service，我们都是在一个很大的类中，做很多的事情。

虽然在 Andorid 开发中，这是一个常见的做法，但这样子做并不利于长期维护我们的代码逻辑。因此我建议，要尽可能的注意这个问题，多找机会去重构代码，将逻辑拆分到独立的类中去。

说实话，我现在并不认为，一个初级开发者可以对架构和设计做出太多的改善工作。正确的封装代码逻辑，提取出有意义的类，都需要一些开发经验。当然，我也不希望你不去思考代码拆分，你可以做一些力所能及的事情，避免出现不可控的情况（例如，一个 Activity 中写了超过 5000 行代码）。

刚开始，你可以尝试拆分这篇文章中描述的与 Context 有关的逻辑。

2-4 年开发经验

当你在你的职业生涯中工作几年，你变成经验丰富的 Android 开发者，通过研究和学习，你可以很轻松的实现一些非专业化的功能。那下一步，你该做什么？

我认为，在这个时候，你已经很熟悉 Android 框架的基础知识了，可以尝试去学习更高层次的技能。这些技能不局限于 Android，它们是一些通用的软件开发的技能。具体来说，你可以研究以下主题：

依赖注入

依赖注入是一个关注结构分离的设计模式。它主要是用来进行分离应用程序的两个功能：应用程序和核心功能、核心功能组件实现之间的链接。

从某些方面来说，实现了依赖注入的代码库就好你一个计算机：依赖注入的基础库就像是主板一样，而其他的功能组件就好像是 CPU、内存、外设等。只要你的代码中实现了依赖注入，你就可以很方便的插入新功能，并且可以很容易的重用其它组件的功能，也可以很方便的使用新组件的功能。虽然这个比喻有点夸张，但是在我看来，它也确实很好的反映了依赖注入背后的思想。

不幸的是，现在关于依赖注入的文章，很多都存在误解，这给初学者带来很多干扰。因此，如果你想学习依赖注入，我建议你读一下这篇文章，本文中，我分析了众多依赖注入的“神话“。

UI 分离

由于 Android 框架本身的架构，造成了我们在开发的过程中，使用户页面与应用程序中的其它逻辑耦合在一起。几乎所有的 Android 初学者都会这样。这种耦合会导致我们写一个很大的类，这个类里面有应用程序的 UI 绘制、网络处理、多线程处理、应用业务逻辑等。

根据我的经验，UI 逻辑与其它逻辑耦合在一起，会导致代码的可维护性越来越差，迟早会使用代码变得难以理解，无法阅读。到最后，可能会因为功能上的一点小变化，引起很大的副作用。

要将 UI 逻辑与其它逻辑进行分离，可以用使用 Model- View - X 的架构模式。例如: Model-View-Contoller(MVC)、Model-View-Presenter(MVP)、Model-View=ViewModel(MVVM)。这些架构模式都属于同一类架构，当然，这一类架构不仅仅包含列举的这几个，还有其它的架构模式。在这里，为了更方便的描述这一类架构模式，我把他们统称为 MVx 模式。

当你在学习 MVx 模式的时候，请记住，这些都不是架构，而是一种架构模式。这些架构模式仅用于 UI 展示逻辑。因此仅仅使用 MVx 并不能给你一个好的架构，要有一个好的架构，你还需要在其它方面做出更多的努力才能实现。

多线程

有经验的 Android 开发者都会了解多线程，并且了解他们对应用程序的影响。你也许会说，我精通 AsyncTask、RxJava、协程等。我想表达的多线程不是你理解的这个。会使用多线程框架并不等同于理解多线程。

举个例子，众多 Android 开发者都认为，使用 AsyncTask 会导致内存泄漏。这个观点来自 Android Studio 默认的多线程 lint 规则中。既然如此，那这个观点就是对的了吗？很不幸，这个观点是错误的。在这里，我不讲解它们的细节，你可以读一下这篇文章，里面有很多关于 AsyncTask 的内容。

我认为要理解多线程程，就必须可以使用任何多线程框架，甚至是基于基础的 Thread ，都可以写出正确的并发代码。要实现这个目标，你不仅仅需要知道你喜欢的多线程库的 API，你还需要理解多线程的细节。这些多线程库虽然好用，但如果你不理解多线程的基础细节，那么你的应用程序出现多线程的问题只是时间问题。

如果你想学习多线程，从这个视频开始，视频中讲解了所有 Android 开发人员都需要知道的基本概念与原理。

自动化测试

据我所知，很多 Android 项目，都没有使用任何的自动化测试。在使用自动化测试的项目中，大多数也是 QA 人员使用 Appium 之类的工具来完成的。这是整个 Android 行业的现状，非常可悲。之所以没有自动化测试，这个问题可以追溯到 Android 起源，Google 也在很长一段时间里，没有关注过第三方应用的自动化测试。

现如今，有单元测试和 UI 自动化测试经验的开发者需求量很大。即使你到一家没有使用过任何自动化测试的公司去面试，如果你说你会自动化测试，就会给你的面试加分。反之，如果你去的是一个广泛使用自动化测试的公司，你没有自动化测试的技能，这会给你面试减分，处于劣势。

因此，我建议每一个 Android 开发者都去学习一下自动化测试的相关知识。就个人而言，我更喜欢单元测试。而一些开发者喜欢 UI 自动化测试。所以，可以选择一个你更感兴趣的技术，尝试一下。

4 年以上经验

如果你对 Android 已经有了非常丰富的开发经验，那么，是时候学习一些“元”技能了，并且在特定领域进行深度研究。在我看来，以下技能对专业的开发人员来说，都是非常不错的方向。

技术方案评估

如果你还没有做过这件事情，那么现在是时候开始做了。每一个重要的技术决定，都需要进行评估、权衡。有时候，这种决定带来的结果非常好，立竿见影。但是大多数时候，并非总是能够立竿见影，看到效果。通常情况下，需要决策的范围越大，所涉及到的评估范围就越大，除了可以简单进行决策的事情，还有很多可评估项都是非常抽象，短时间内根本看不到结果的。

在自己丰富的经验水平下，面对众多选择，你至少应该知道如何找到取舍。如果你能对技术方案评估提供有用的建议，你就非常优秀了。技术方案评估权衡这是一项非常复杂的技能。通常，在与其它开发者、项目经理甚至是其它部门员工讨论的时候，你能找到折中方案，就能进行方案评估。因此，在大数情况下，你只需要掌握评估方案的能力就够了。

那我们所说的“技术方案的评估”到底是什么意思？说实话，很难具体说明它是什么。不过，我们可以提供一些反例，来解释为什么不适合在开发中使用。举个例子：

我们应该将多线程的使用迁移到 RxJava, 而不是 AsyncTask, 因为 AsyncTask 会导致内存泄漏。

正如我前面所说，AsyncTask 并不会导致内存泄漏。所以上面这句话是错误的。说这句话的开发者并没有深入的研究多线程。此外，他也没有提到 RxJava 的问题。对于一个项目中的开发人员来说，RxJava 存在一个很陡峭的学习曲线。

我们应该为我们的新代码写单元测试，并且设定一个长期的目标，覆盖所有的代码，以确保我们的代码质量。

这句话包含几个前提，首先，我们现在开始单元测试是不可能的，至少需要开发人员投入时间来学习这种技术。编写单元测试是一个很明智的决定。我们不能为所有代码编写单元测试，因为有一些部分是不稳定的。最后，达到特定的覆盖目标并不会自动提高“质量“。在这个例子中，开发者并不了解单元测试，他们无法确定在项目中使用单元测试所涉及的问题和影响。

我希望，你对“技术方案评估”已经有了大致的想法，如果你有一个重要的决定，你需要完成所有必要的调研，如果你依然看不到整个评估中存在的复杂网络，那可能是你的调研没有做好。在做决定的时候，有些事情可能超出技术范围，你也需要考虑你的决策对其它部门同事的影响。

专业领域

如何区分一个技术专家和一个普通开发者？是我们熟悉的概念的数量吗？我认为，在技术方面，区分是否是专家主要在于知识上的深度。

作为一个技术专家，你应该有一个或者多个专业领域。你知道这些领域的详细细节，比一般的开发者知道的要多得多。你需要持续深入的研究，来保证你的专业深度，了解专业领域的最新发展，不会对新的工具和技术感到惊讶。此外，即使你并没有在任何项目中使用某些技术，你也需要研究这些技术使用上相关联的各种成本。

现如今，有一个自己的专业领域很难。这不是从博客中挑选几篇好文章进行阅读就可以的，也不是读完几本好书、上完几门好课就可以的。当然，通过这些内容进行学习，对你的专家之路都是有帮助的，但是要有自己的专业领域，唯一的方法就是积极参与其中进行学习研究并获得大量经验。

我很喜欢物理学家尼尔斯·玻尔说的这句话：

An expert is a man who has made all the mistakes which can be made, in a narrow field.（专家就是把领域内所有该犯的错都犯完的人。）

我们可以在哪些领域进行深入研究呢？实际上，几乎所有的都可以进行深入的研究，在软件开发领域，没有任何一个领域会因为太小而不能设置成专业目标。对此，我也有一些建议：

构建系统

离线工作

并发

NDK