在心中谋划已久的此事终于要开篇了,虽然迟了点,十年前没有种的树,就从现在开始种吧。

自 2014 年底从 Windows 开发转向 Android 开发以后,到现在的两年多时间里,也陆陆续续看了一些强相关的书籍和教程,按我在豆瓣标记的时间顺序:

  • 《Android Programming: The Big Nert Ranch Guide》
  • 《疯狂 Java 讲义》
  • 《疯狂 Android 讲义》
  • 《Android 软件安全与逆向分析》
  • 《深入理解 Java 虚拟机》
  • 《Android Training》
  • 《Android 开发艺术探索》
  • 《Android 群英传》
  • 《App 研发录》

再加上平时在 GitHub 和掘金等技术社区的晃荡,接触过的资料其实也不少了,但回想起年初找工作的时候一些比较失落的经历,自身存在一些很要命的问题,就是如自己一直也知道的那样:

  1. 技术的广度还可以,可深度不够,不够聚焦;
  2. 掌握的知识是散乱的,不成体系,禁不住往深了问。

这一方面归因于自己的学习方式需要优化,技术书籍的学习不能只是通读,精读、主题阅读和针对性的实践总结一样不能少;另一方面挑选书籍要更有目的性,最好是明晰的由浅入深的层次递进;还有就是市面上流行的书籍和网络上的技术分享恐怕都无法让我彻底改善这种情况。

这个尴尬的年纪,在一个个焦虑的夜晚,躺在床上听着窗外偶尔传来的狗叫,汽车的呼啸,也会对自己呐喊,我不要做一个会用九种语言写 Hello World 但无一精通的程序员,迫切需要 聚焦精通成体系

一切就从自己的工作内容最相关的业务与技术开始入手。业务相关的知识可以在工作时间来积累,业余的时间里,多 Read The F*cking Source Code,从优秀的源码和设计里汲取营养。有 AOSP 这样包罗万象的宝藏在侧,也无需纠结和寻觅到底应该看些什么,里面程序设计语言、设计模式、架构模式等等,应有尽有。

所以,最近计划开始写一系列 Android 源码分析的文章,包括 Android 系统源码及一些优秀的第三方类库等等。这将是一个比较漫长的过程,需要一个脉络,可选的方式是自底向上和自顶向下:

自底向上,一开始就是啃硬骨头,理解各种底层概念和知识,对我这样的选手来讲,容易失去兴趣,但是后期理解上层的东西更顺畅,毕竟基础知识点已经铺垫好了。比如《老罗的 Android 之旅》,就是比较典型的采用这种方式的。

1
2
3
4
5
6
7
8
9
10
11
12
^ 难度
| ---
| / \
| | |
| / |
| | |
| / |
| | |
| | +-----------------
|/
+------------------------->
时间

自顶向下,预计是需要从几个熟悉的话题展开,充分下探之后,基础知识大致铺垫开,后面才会比较容易。这样做的一个好处是比较有目的性,总是知道下一个步要去找些什么,看些什么;另一点是从熟悉的东西讲起,前期曲线比较平滑。

1
2
3
4
5
6
7
8
9
10
11
12
^ 难度
| _
| _/ |
| _/ \
| _/ \
| / \
| _/ |
| _/ \
| _/ \----
|/
+------------------------->
时间

自认为没有恒心与毅力像罗升阳那样自底向上面面俱到地把 Android 的各个方面都分析一遍,我的大致的思路是打算从我们最常用的一些类开始,自顶向下摸索,牵扯到哪些需要深入理解的知识点,就另开一篇详细说明,这个过程类似 JVM 的 GC 中采用的可达性算法,只要选好了 GC roots,无论是深度优先还是广度优先,天长日久,总会覆盖所有我们常用的技术及其内部的原理。

举个例子,比如我第一篇打算分析 Toast 类,那由它展开可能会逐渐讲到很多的话题:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Toast
|
|--- Handler
| |
| |--- Communicating with the UI thread
| |
| |--- Looper/Message/MessageQueue
| |
| |--- ThreadLocal
|
|--- Binder
| |
| |--- ServiceManager
| |
| |--- Inter-process communication
| |
| |--- ...
|
|--- Update UI outside the main thread
|
|--- ...

每介绍一篇,可能会发散出一些本篇中涉及但是没有深入讲解的知识点,留待后续补上,我将在文章最后把这些知识点列出来。在当前文章中需要提到的地方,就插个桩,留个尽量恰当的比喻在那里,「把它当作 XXX 理解就好了」。

当暂时沿着某一个主题延伸不下去,又没有找到合适的新主题的时候,就按一些比较有体系的主题来写,比如「Android 里的设计模式」,可以单独写一个系列。

这样做的目的,主要是想进行一些比较深入的学习和对过往知识的整理,将一个一个散落的知识点孤岛串联起来,让它们成为我的技能战斗群,写着应用代码时能对表面之下的原理了然于胸,减少写代码时对猜测和调试的依赖,对每一个我敢写出来的技能点,都能自信满满地与人对谈。

目前的计划是按照我最近一段时间更新公众号的频率,大约十天更新一篇,阅读源码主要使用的工具和方式是:

大致思路就是这样,实践一阵试试。不知道自顶向下的方法是否走得下去,要是实在不行,还是乖乖回去跟着老罗的脚步学习吧。

开篇,就当先立个 Flag 在这里,万一坚持做下去了呢,牛皮都不敢吹还哪敢做成什么事啊,最次也「世上无难事,只要肯放弃」嘛。对此有兴趣的朋友,请关注我的微信公众号「闷骚的程序员」,一起 Read The F*cking Android Source Code。

后续相关的系列文章,会在 GitHub 仓库 mzlogin/rtfsc-android 汇总更新,欢迎关注,看我起高楼,或是啪啪打脸。