查看原文
其他

Android 开发者成神之路!

VasiliyZukanov​ CSDN 2020-02-17

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

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

  • UI

  • 构建系统

  • 离线工作

  • 并发

  • NDK

  • 持续集成

  • 性能

  • 架构

  • 监测

  • 项目管理

  • 专业知识领域

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

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

所以,如果你有 4 年以上的经验,你的专业领域是什么?


总结


以上,这是我建议你,作为一个专业的 Android 开发者应该具备的技能。

你可能已经发现,我的文章标题是 《Android Developer Skills for 2020(2020 年,Android 开发者需要的技能)》,但是这篇文章中没有什么内容是特定于 2020 年的。我可以在一两年前写这篇文章,因为本文内容适合所有时间,基础和重要的概念不会经常改变。

现在,如果你对 Android 生态系统的最新发展感到好奇,你可以阅读我的另一篇文章 ,我总结了 2019 年底 Android 发展的状况。最后,我再重复一次,如果你想成为一个优秀的 Android 开发人员,请集中精力,对基础和重要的事情做深度研究。

一如既往,感谢你的阅读。你可以在下面留言评论和提问。

英文:Android Developer Skills for 2020

链接:https://www.techyourchance.com/android-developer-skills/

作者:Vasiliy Zukanov,独立 Android 开发及软件顾问

译者:罗昭成,Android 开发者

【END】

热 文 推 荐 


如何走出物联网死亡之井?
无代码开发究竟是不是伪需求?
华为百度美团驰援抗击疫情;自由软件基金会建议开源 Windows 7;印度超越美国成第二大智能手机市场 | 极客头条

☞疫情严重,潜伏期也有传染性?科技公司在行动

程序员谈从科比的曼巴精神中,我们能学到什么?

你点的每个在看,我都认真当成了喜欢

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存