聊一聊阅读源码

---

为什么要阅读源码

要熟练使用一个工具、一套框架，最好的方式就是首先去阅读官方文档、API文档。通过官方的文档了解具体的功能，然后再聚焦自己最需要的部分，去逐个突破。
而熟练使用之后，有时候也会禁不住想了解，这些都是怎么实现的？想了解其中的原理。
了解了原理，就知道了类似的功能是怎么实现了，举一反三，以后遇到类似的情况，也有了可以参考的方案。
而且，了解原理，也能对工具的优缺点更加明确，可以优化性能，甚至可以自己动手来给工具做一下特定的调整。
往小了说，就是使用过程中出了bug，也能更快定位问题，找出解决方案。

那想要了解认识原理，最好的方式就是阅读源码了。
（这是我以前产生阅读源码想法的初衷。但除此之外，阅读源码，还可以对很多技术、思路、技巧、甚至整个体系的了解，都大有帮助，反正就是有空多看看源码，积累也在不知不觉间。）

---

读得脑壳痛

很多人应该也是跟我一样，一开始的时候，一看到源码就头疼。而且尽管看过了不少源码，现在的我也依然头疼。
毕竟阅读别人的源码，就是去理解作者的思路，要是不跟着源码的思路走，很容易就头疼了……

刚开始阅读源码，避免不了迷迷糊糊，不知道从哪入手。一个方法点进去，里面各种继承和实现、各种代理和接口，让人眼花缭乱。有时候一个方法进到底部，都要经过10几次的子方法调用，方法调用子方法、子方法调用他的子子方法……看着看着，头就疼起来了……

---

需要清楚自己的目的

但其实，对于这些源码的阅读，需不需要知道到这么深入呢？
可能你需要的只是理解表面的逻辑？
又或者你需要了解的是内部之间的交互？
也可能你就是想要钻研到最底层的实现？

这都需要你在阅读源码之前，对自己的目标有清晰的认知。
知道自己想要什么，才带着自己的目的去阅读。
这样，阅读的深度就能根据你的目的而来，而不是盲目的看，不是广撒网。这样只会越看越晕。
而且，在阅读的过程中，会感觉自己的疑惑在慢慢解开。因为有目的地阅读源码，关注点就知道聚焦在哪里。不会茫然地点开一个又一个的继承、接口、调用……搞得最后自己都不知道自己在看什么。
带着目标去看，更贴近作者的思路，因为你在思考的问题，也是作者在开发时考虑过的问题（毕竟是代码实现了功能，不管作者考没考虑过，反正功能是实现了的，思路也就对得上了），这样就能进一步进入到源码的逻辑当中。

---

源码是很规范的

然后还有注释。注释是为了让代码更易于阅读才加上去的。所以我们也需要利用起这点。人家作者为了你们看的方便，特地写的注释，怎么好意思不看（虽然更多的可能是作者自己写给自己以后看的）。
开源的代码，大多书写都是很规范的，尤其是那些开源框架。其中的注释，大多也能够说明了某个方法，某段代码的作用。
而且可读性也很高，这些都很有利于我们对于代码的阅读。
不要担心人家写的都是天书我们看不懂，再厉害的程序员也是人，用的工具和开发语言跟我们都一样，所以不用过于敬畏这些，耐心点钻研下去就能有所收获。

---

由浅到深

如果直接阅读一些开源框架的源码很困难，其实也可以从简单的先开始，练习下自己的阅读能力。
比如从同事写的业务代码开始，相信这个大家平常工作中肯定接触过了。
由于技术水平、书写习惯和业务逻辑都了解，所以这些代码看起来就比较轻松了。这其实就是一种源码的阅读。
再接着，也就可以看看自己实际用到的那些公共组件的源码。相信每个公司的项目，都会有一些自己人开发的公共组件、工具。毕竟是自家公司开发的东西，所以读起来肯定也会比其他的开源组件轻松一些。而且作为公共的工具，里面或多或少都会有值得参考学习的东西。
就这样，循序渐进，阅读其那些开源框架源码，也就越来越好上手了。

---

介绍下方法

最后简单说一下，可以怎么去开始一套源码的阅读：
0、首先肯定是要把源码拉下来到自己熟悉的开发工具上的。
1、调试：如果运行得起来，就用调试模式，找到程序的入口，从入口开始，一条工作流程走下去，查看它经过的每一步。
这样，跟着实际工作思路走，就可以比较清晰的理解这整个的运转过程。
慢慢的，就可以扩展开来，结合其他运行情况，深入了解自己最希望了解的部分。
2、先了解整体，再逐个深入：如果运行不起来，就先了解整个项目组织结构，理清项目有几大模块组成，各自是什么作用。由外而内，逐步突破。
这个时候也是很需要耐心的，可能很多是你不了解，或者觉得无关紧要的，但是需要耐心下来，都过一遍，对整体有个初步了解。
不需要多深入理解，只求知道个整体大概。
然后，再抓着自己想要深入了解的地方，进行攻克。毕竟如果不了解个大概，甚至连自己想了解的地方在哪里都不知道。