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.（专家就是把领域内所有该犯的错都犯完的人。）

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

• UI

• 构建系统

• 离线工作

• 并发

• NDK

• 持续集成

• 性能

• 架构

• 监测

• 项目管理

• 专业知识领域

还有很多很多。需要注意的是，上面我列出来的内容，一些并不属于严格的技术领域。只要你能为你的雇主产生价值，你可以选择你喜欢的任何领域并进行深入研究。

我认为，一个 Android 技术专家，至少有 2～3 个专业领域，例如，我的专业领域是：架构、单元测试、并发、依赖注入。我相信，在不久的将来，我能够将“重构祖传代码”添加我的专业技能列表里面。