阅读源码策略之我见

Read The Fucking Code

谁都知道阅读源码的好处，但是数次尝试进入源码的海洋，而数度又无功折返的惨痛经历，比如android框架的源码，linux内核的源码…..等等。就好像当年那帮出海寻找宝藏的水手们，在汪洋大海里历尽千辛万苦却徒劳无获。

1.先把他看成一个黑盒，用用看

首先得从使用者的角度去了解这个框架或者库是用来干啥的，作为上层的开发者去使用把玩他，了解它存在的意义。

2.猜

只是单纯看别人写的教程资料是不动脑筋的过程，而且无法得到深刻的理解和贯通。而前期“猜它的原理”则是一个很重要的过程，但如果你对于猜也一点头绪没有，那么不要急着去看源码了，而是应该返回第一步或者再补充一些相关的基础知识。
另一种方式 就是提出一大堆问题，去寻找问题的答案，

反正最后的最后就是绝对不能不去思考就去开始源码的征程。

3.底层出击

根据猜测搜索关键实现。比如在看RoboGuice的源码，它最终的实现肯定跑不开findViewById,这么一搜，一下子就找到最核心的那一层了。

3.1.这么做有什么好处呢？

3.1.1.树立方向感

如果从上层API正向深入的话，比较大的源代码框架它的实现层级会非常深，看着看着就被带晕掉了，但是如果一下子找到了这个最核心最关心的那一层，在源码的海洋里就像竖起了一台灯塔，让人有了方向感。

3.1.2.验证自己的猜测

如果我们带着自己错误的猜测去看代码，也许比没有猜测还差，通过这种方式快速的验证自己的猜测是否正确，如果有错误，那么是否应该再考虑考虑。

4.正向深入

从暴露的API接口开始深入源码 阅读。借助时序图工具，保证自己的思路清晰。

5.将正面深入和底层出击进行对接

第3步 底层出击 已然建立了一个灯塔，那么正面深入就需要寻找到通往这座灯塔的一条路径，一旦这条路径变得清晰，那么源码探索的征程才算完成一大半。

其他要点

看源码要有明确的目的

最好是带着一些问题？
最好是带着一种验证猜想的好奇心？
这样就不会在代码的海洋中迷失。

不要为细节所困

把握大框架，以自己看源码的初衷为主线，不要因为周边的细节而偏离，跳跃式阅读关键实现。

不要求全

每次扬帆出航，只为一个明确的目的，不要试图一次将每个角落都搞个明白。
当然当你扬帆的次数多了，渐渐的也就每个角度都熟知了，你就成为这个方面的专家。

设置断点来查找到使用的是哪个子类

一个父类有好几个子类，而外面使用的是父类的类名，程序庞大，不能很快知道其到底对应的是哪个子类，那么在每个子类的方法中设置断点，看看最后是停在哪个子类方法中便可知。