在长沙待的那些年，身边所看到的大概可分为两类人，一类是不断反复的做业务逻辑，只求功能能够写出来，每天重复上下班，不想过多的去折腾；还有一类是不断的反思总结和学习，不只停留在做的层次上，是真正的喜欢做这行，且觉得非常有意思。没有什么好与坏，只是大家的追求不同而已。但如果我们想要去大一点的公司，或者找一份工资稍微高些的工作，后面我们就会有很多坎要去迈，其中一个就是阅读源码，所以这期我们主要来探讨一下阅读源码的 一些姿势。在真正踏上这条路之前，希望我们能明确以下几点：
- 没有人一上来就可以看得懂源码，我们都是从 Hello World 开始的，所以没有什么捷径可以走，无非就是看我们谁花的时间多，谁更愿意折腾。
- 大家都是上下班，为啥别人工资拿得高福利又好，而自己大小周，偶尔还需要加班通宵。同样三四年别人拿 20k，我自己却只拿了 10k。注意我说的是 20k ，之前写过一篇文章 《从3K到30K，23岁的年纪我到底经历了什么》 这次同样怕某些哥们会喷，哪有那么高？我们心中要有美好的信念，要有不断向上的激情。
能力提升过程中我们能从中获得很多东西，内心也会变强大，关键是我们在做项目的时候，的确会要顺手很多，这就可以拿来换钱和时间，前提是我们愿意拿时间去换。
一.常用工具
首先来介绍一些看源码的工具，第一个就是我们的开发工具 Android Studio ，这里我们以具体的示例来说，假设现在我想看 setContentView 的源码，那么我们可以直接跟进到源码的方法里面去：
这时如果再往里面跟发现是一个抽象类，我们必须要找到实现类，一般来讲我们可以搜索（ctrl + F）找到其创建实例的地方：
是红色的，这个时候我们再也没法往里面跟了（一碰到红尴尬症就犯了，肾得慌），碰到这种情况我们可以试试全局的搜索（双击 shift）
但很多情况下我们全局搜索也搜索不到，接下来给大家介绍第二个工具，我们可以在线浏览源码阅读：http://androidxref.com 这里面不光有 Java 层的源代码还有 native 层的源代码
在线查看一般都是比较精确要看哪个类的时候，并不能满足我们快速查看的需求。我就想在 Android Studio 中看，可以不断快速的往下跟进。其实我们在下载 sdk 的时候一般都会下载源码，只不过刚好 android.jar 包中没有这个 class 类的源码，所以我们才找不到而已。这个时候我们需要一个比较完整的 android.jar ，用来替换我们 sdk 中的 android.jar 文件，关键是这个 jar 怎么来？最好的方式是自己去编译，但很多哥们可能觉得自己编译成本高，那么我们也可以去 github 上下载。https://github.com/anggrayudi/android-hidden-api 把原来的保存一份改下命名，把下载的复制进去，然后重启 Android Studio 再去看看，发现不仅没有报红而且可以点击了。
到后面这些还是无法满足我们的需求，比如现在我们已经把 C++ 进阶学完了，我想跟到 native 层的源码去看看，比如去看看底层的 Binder 驱动，或者去看看类的加载机制，我再送大家一个链接，里面所有的源码基本都能找到：https://pan.baidu.com/s/1tGtBt5Y1G50yI10EkVRPAw
再啰嗦几句，如果我们对源码非常感兴趣，我建议大家还是自己去编译源码，这样我们就可以利用 Android Studio 去调试跟踪源码，屡试不爽。
二.前辈力量
文章的开头有提到，没有人一上来就可以看得懂源码，我们都是从 Hello World 开始的，所以没有什么捷径可以走，无非就是看我们谁花的时间多，谁更愿意折腾。别看网上有很多大牛写了很多分析源码的文章，但其实他们都是经过反复折腾，才能写出那一篇形如流水却很抽象的文章。所以我们写了那么多分析源码的文章，录了那么多直播课程，无非就是我们在背后花了很多时间而已。只要你愿意我能行的，你也能行。
当然刚一开始我并不建议大家自己去看源码，我记得自己第一次看源码的时候，点击进去是一脸蒙 B。所以刚一开始我们需要借助前辈的力量，跟着大牛的思路去看源码，也就是大家通常所说的老司机带带我。
有几点需要提醒大家是，有些文章可能篇幅比较长，要有耐心不断反复的多看几遍。当然有时也不必在一棵树上吊死，其他树上也可以多试几次。其次我们找一些稍微靠谱一点的，阅读量多一些的文章，排版稍微好点，图文并茂的。最后，不管别人的文章写得有多好有多清晰多牛掰，始终不是我们自己的，也有可能存在 bug 。这也是我为什么建议大家看阅读量稍微高些的文章，因为有问题大家会评论提出来，会经过很多次的修正调整。我们最好自己亲身去实践，自己做做笔记或者写写文章，把它真正变成自己的知识，这样提升的速度是非常快的，屡试不爽。
三.惯用套路
每个人阅读源码的思路都会有些不一样，姿势也会有所不同，下面我仅代表个人的观点谈谈我的惯用套路，假如我们想去分析 glide 这个开源库，假设现在网上的资料也没法满足我们了：
第一步会去画 UML 时序图，相信我们在分析 glide 源码的时候，刚开始可能连访问网络的码头都找不到。画时序图不光能防止我们沉入茫茫大海，还能让整个加载显示流程都非常清晰，好记性不如画流程图。
第二步会去画 UML 类图，每个第三方库在其架构设计上，都会有其值得借鉴的地方。如 retrofit 这个开源库，虽然类文件并不多，但里面的封装解耦思想，都能够在我们实际的开发过程中派上用场。
第三步会去抓细节，比如 Glide 怎么压缩适配图片的，缓存怎么处理的，是如何加载 gif 图片的，怎么解析视频封面的。我们在开发过程中遇到的很多问题，源码会给我们很多更好的解决方案。
第四步会去参考模仿，并不是建议大家去重复造轮子，比如我们知道了 IOC 的实现原理，就能完美的解决 mvp 中多 prsenter 的情况；清楚了 RxPermission 的实现方式我们就能很轻松的写出类似 RxPay 和 RxShare 等等。
第五步会去反思现有的架构设计，我们在写项目的时候，往往由于时间的原因，只是考虑了怎么实现，能实现能按时上线就好。随着业务的不断修改增加，可能已经没有了高蛋白低脂肪。当然随着经验的增长考虑的也会多一些，但仍然需要不断的反思和学习。
四.随心所欲
当我们阅读了大量的源码和第三方开源库后，我们就能打通任督二脉，学习的速度会越来越快。当同事遇到一些棘手的 bug ，我们能从源码的角度去分析解决；一些难以实现的需求，我们也能很快的找到解决方案。这时我们要么是在大公司镀金，要么是在小公司做负责人，是真正的喜欢工作、学习和折腾。
原创作者：红橙Darren（曾辉）
原文链接：https://www.jianshu.com/p/8012d5d38b01
原文地址：https://www.cnblogs.com/hejunlin/p/12694437.html