为什么以及要有的态度： 不要消极的去阅读别人的代码，而是带着挖掘宝藏的精神去寻找别人的代码中精华的部分，找出其中好的架构为我所用。   大体思路： （1）忽略细节，先前不要关注分支（支线）。不重要的功能，一扫而过。 （2）先整体再局部，先宏观再微观，先流程再细节。从上而下了解，先不关心内部细节。           注意：从上而下了解，先不关心内部细节。 （3）阅读代码有两种模式：top-down 和 bottom-up。需结合起来使用；   方法： （1）先建好环境，让程序能运行，玩一遍 （2）通过文档或者资料了解程序的架构； （3）断点调试、日志调试。 （4）善用搜索引擎；在查找一些函数在项目中的脉络，以及一些变量或对象在项目的使用点，这样比较有针对性； （5）写注释；从流程到细节，看流程时，只要把流程函数的功能注明即可，看细节时，就需要把难看懂的地方加注释，方便理解，和理清思路； （6）绘制UML。这个方法适用于类之间的关系较复杂和调用层次较深的情况，我一般都是先绘制顺序图，然后为顺序图中的类绘制关系图。         注：Unified Modeling Language (UML)又称统一建模语言或标准建模语言，是始于1997年一个OMG标准，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。 （7）类的快速阅读。先弄清楚它在继承链中的位置，看看它的内部状态，也就是成员变量，一般来说，类的对外接口都是对成员变量的访问、加工、代理等，然后看看它的对外接口，也就是公有成员函数，识别核心的一个或多个函数，这时候你应该可以大概了解这个类的职责或作用了。可能这个类是某个设计模式中的一个组成部分，所以，设计模式的掌握对代码的快速阅读也是很有帮助的。 （8）带着问题去阅读。比如想了解Android中的消息机制，那么看看Looper、Handler、MessegeQueue这几个类就可以了，其他的不要去看，要不然就跑题了。   必要使用： 方法1， 2， 3， 4， 5，8；   选择性使用： 方法6：在代码的耦合性比较高时以及需要理清代码的逻辑的时候； 方法7：需要知道具体的类的作用的时候，需要考虑细节的时候；   进阶： （1）了解别人的代码意图，然后再去修改，扩充，抽取，提炼精华。这是进阶的必经之路。   书： 「代码阅读方法与实践」   工具： 使用source insight工具                        

参考1：

如何快速看懂一个大型程序 - JYSG9的专栏 - CSDN博客
https://blog.csdn.net/jysg9/article/details/24193181 （1）先建好环境，让程序能运行，玩一遍 （2）看想办法掌握程序的结构；对于开源项目，通过作者微博、Google、百度、PDSN、等找到程序的体系结构，通常情况下是能找到些资料的。即使情况差一点，也能找到星星点点，而这些星星点点对你的研究往往有很大的帮助。 （3）先体系再细节；先平面再线点。 （4）断点调试、日志调试。 （5）忽略细节，先前不要关注分支（支线）。如有些函数一看函数名便知道是干什么的，没有要一开始便深入。
有些系统中的分支（如某此特殊场景下才执行的逻辑）、不重要的功能，则一扫而过。 （6）其它；善用搜索引擎，试试切换不同的关键字，往往有意外的收获。   先整体再局部，先宏观再微观，先流程再细节。  

参考2：

如何快速的看懂别人的代码 - SunWuKong_Hadoop的博客 - CSDN博客
https://blog.csdn.net/SunWuKong_Hadoop/article/details/59108612 1、阅读他人的代码就要阅读其中的精华，站在巨人的肩膀上，让自己成为巨人。 2、不要消极的去阅读别人的代码，而是带着挖掘宝藏的精神去寻找别人的代码中精华的部分，找出其中好的架构为我所用。 3、了解别人的代码意图，然后再去修改，扩充，抽取，提炼精华。这是进阶的必经之路。 4、要了解别人的代码，首先要熟悉代码中的命名规范。 5、阅读代码的目的在于了解系统全貌而非了解细节。(感觉这句话没说好!) 6、心中必须有对架构的层次感，例如，如果谈到对事件驱动式的架构时，应该想到，这个系统主要有三个重要角 {MOD}，事件调度，事件产生，事件处理。从上而下了解，先不关心内部细节。 7、从作者的角度去理解代码，理解架构。  

参考3：

牛人教你如何阅读源码 - 哆来咪er的博客 - CSDN博客
https://blog.csdn.net/Maxbyzhou/article/details/51424595 1）、一边阅读代码一边写注释。这是我用过的最好的方法，对代码理解得更深入，看一些重要代码或者特别难懂的代码时挺有用。更何况，注释也是一种文档嘛。

2）、一边阅读代码一边绘制UML。这个方法适用于类之间的关系较复杂和调用层次较深的情况，我一般都是先绘制顺序图，然后为顺序图中的类绘制关系图。

3）、通过Debug来跟踪程序的主要执行过程，这样就可以分清主次了，阅读的时候更有针对性。（前面参考有说到）

4）、类的快速阅读。先弄清楚它在继承链中的位置，看看它的内部状态，也就是成员变量，一般来说，类的对外接口都是对成员变量的访问、加工、代理等，然后看看它的对外接口，也就是公有成员函数，识别核心的一个或多个函数，这时候你应该可以大概了解这个类的职责或作用了。可能这个类是某个设计模式中的一个组成部分，所以，设计模式的掌握对代码的快速阅读也是很有帮助的。

5）、带着问题去阅读。比如想了解Android中的消息机制，那么看看Looper、Handler、MessegeQueue这几个类就可以了，其他的不要去看，要不然就跑题了。

  下面列几个阅读源码时所处的情景，在特定场景下用哪些方法：
     不太熟悉业务逻辑，还不是很清楚它是干啥的，可以用3、5。
     代码量很大，有几十万行，甚至百万行，可以用2、3、5。
     你无法看见程序的运行过程，比如没有用户界面，也有可能是无法运行的，可以用3、5。
     设计复杂，用了大量的设计模式，调用链很深，可以用1、2、3、4、5。
     时间有限，没有那么多时间让你看源码，可以用3、5。   以及： 1）读代码最忌讳的是不抓结构抓细节，只见树木不见森林 2）首先应该先了解代码的功能业务，在了解业务逻辑的情况下，进行代码阅读觉得是事半功倍的，可以先多用用列跑起来，看看功能。 3）阅读代码有两种模式：top-down 和 bottom-up。 Top-down 模式，就是先设定一个 use case，比如说打开一个文件。然后静态跟着代码看，或者用 debugger 跟着看。每次出现函数调用的时候，把函数的执行层次纪录下来。大致如下：
func1( )
   func2(  )
       func(  )
   func3(  )


这种图表很随意，你可以根据自己的需要增加信息。比如我有时会把重要的「实际参数」一直标下来，这样阅读深层次代码不用再回头查形式参数到底指什么。这个图的基本作用是防止在阅读深层次代码时忘记总体执行层次。

Top-down 模式进行到一定层次，往往会发现虽然图画了出来，但还是无法了解程序再干什么。这时需要转入 bottom-up 模式，一直深入到最底层，给能了解作用的底层函数一个一个的写文档。当然这时的文档是完全底层的观点。

然后就是不断在两个模式之间转换，不断的细化两种模式的理解。 4）「代码阅读方法与实践」推荐这本书   总结来说： 1、带着问题读（前面参考有说到） 2、对它先产生初步映像 3、使用source insight工具 4、使用debugger模式（前面参考有说到） 5、做好注释（前面参考有说到）