有没有必要阅读Android源码

或许对于许多Android开发者来讲，所谓的Android工程师的工做“不过就是用XML实现设计师的美术图，用JSON解析服务器的数据，再把数据显示到界面上”就行了，源码什么的，看也好不看也罢，反正应用层的开发用不上，再加上如今优秀的轮子愈来愈多，拿来主义泛滥，能用就是，反正老板也不关心是否是你本身写的，用我如今老大的话来讲，阅读源码彷佛只是一种“锦上添花”的事，有天然好，没有也罢。

那么，做为Android开发者的自我修养，到底有没有必要阅读AOSP以及其余开源项目的源码呢？

刚开始时候的故事

对于我来讲，选择编程是由于我看见了 MoeLoader 这款收图应用实在是漂亮才开始写代码，我要的目的只是应用漂亮，不用在意代码写成什么样，并且我以为代码是我写的，这么辛苦的做品可不能白白开源给别人看。因此对于这个时候的我，那时候虽然没有考虑过相似的问题，可是极可能以为阅读源码是没有必要的。

后来我开始学习Android，缘由很是简单，C#根本没法找到合适的工做，而学生党的我根本没法买得起苹果三套件，此外，IE6的兼容工做让我实在是对前端敬而远之，因此选择只剩下Android了。说实在的，一开始我是不太喜欢Android开发，特别是IDE从Visual Studio切换到万恶的Eclipse，丑，卡顿，动不动就找不到依赖，甚至有时候编译一直报红Error，定位了半天找不到问题，到最后把红色的Error删除掉后竟然就编译经过了！这时候的我，别说阅读源码了，我只求同一份代码在运行的时候有一样的逻辑就好。

再到后来，我已经有一些Android程序设计的经验了，IDE也开始换到Android Studio（Preview版本刚出来的时候，我在Android Studio和Eclipse之间切换过好几回，不得不说习惯这种东西有时颇有帮助，有时候也会很可怕），换到Android Studio很大一个缘由是由于Github上面许多开源项目用Android Studio来部署很方便。这个时候我接触的开源项目已经比较多了，许多时候一些开源项目总有一些BUG，我会给其提交ISSUE，不过更多时候我不能等项目全部者来解决，须要我本身解决BUG；许多时候开源项目并不能直接知足业务的须要，因此我也须要先阅读源码再改形成本身的项目能用的。

这里须要特别说明的是，个人第一份工做的项目是一个SDK项目，总体使用了基于ClassLoader的动态加载的框架。那时候还比较早，国外对动态加载不感兴趣，国内的话也只有零星的技术博客对这有讨论，不过大可能是介绍如何实现动态加载而没有分析其工做机制。因此，当有新的技术需求，或者项目出现BUG的时候，我都须要本身阅读源码去解决问题。好比，有一次设计师须要一个全圆角的菜单背景，然而Android的点九图是X轴和Y轴都须要拉伸的，当Y轴拉伸的时候就没法实现全圆角。我能作的就是，先把点九图的原图等比缩放到Y轴填满，这样Y轴就不会被拉伸了，可是原图缩放后，点九图X轴的拉伸却出现了扭曲的样式。经过阅读NinePatchDrawable的源码，我发现点九图的原理就是一个普通的Drawable加上一个用于描述拉伸坐标的数组chunk，当我缩放Drawable的时候，也必须更新chunk，否则拉伸的坐标就对不上，后面经过阅读源码中关于chunk的描述，把对应的拉伸坐标更新后，全圆角的点九图 也就实现了。

为何要阅读源码

说了这么多，到底有没有必要阅读源码？有必要，并且很是有必要！缘由有三。

其一，了解基层，高层才能更好地工做。

好比，了解View的绘制过程，了解TouchEvent的分发和拦截过程的细节，才能写出酷炫的UI，要否则，只知道大概的原理的话，你可能要在“没法接收到触摸事件”或者“滑动事件和点击事件冲突”的这些问题上折腾半天。

又好比，若是哪里出现异常，你能快速定位到源码抛异常类的地方，就能快速解决BUG，对症下药，一招撂倒，有些时候，修复BUG的时间不是用在解决问题上，而是用在定位问题上。

这里有必要提一下，当Logcat把异常的栈信息打印出来的时候，有些异常出现的缘由并不真的是Logcat的信息里描述的缘由，由于Logcat里的异常的信息也只是由系统源码打印出来的，而这些源码大多时候只是普通的Java代码，和你本身写的没什么区别，若是源码抛出异常的代码的逻辑不够严谨的话，那实际的异常和Logcat里描述的异常可能对不上。好比以前搞动态加载的时候，在使用LayoutInflator渲染一个外部的XML布局时，抛了一个“Class not found”的异常，我要渲染的类但是LinearLayout啊，怎么可能没有！定位到源码里才发现，这里只要是类渲染失败就会抛这个异常，再定位到具体抛异常的地方，发现实际是Dimens资源找不到，困扰半年的问题马上解决。

其二，可以理解Android设计者的意图。

这个描述可能很差，好比说，许多人都以为Android开发其实就是Java开发，经过阅读Context类的设计，你可以理解Google是如何在Java的基础上加上Android的特性的，你可以理解Context被叫作“环境”的缘由。此外，阅读Activity/Service的源码，你能理解到四大组件类明明就是普通的JAVA类，为何他们就是组件而别的类就不是组件。阅读Handler/Message/Looper的源码，你还能理解到Handler的精髓，数据驱动比事件驱动更适合用于设计须要常常改动的框架。阅读源码，你能知道Android是怎么管理Window以及向控制View的触摸事件的，你能知道基本上全部的res资源都有等价的Java代码的实现方式，你还能知道Dalvik是怎么无缝向ART过分的，在看通的那一瞬间，保证你以为“水可载舟，亦可赛艇”！

其三，可以学习优秀开源项目的代码风格和设计理念。

这也是最重要的，看多了源码以后，你会发现所谓的源码也不过是普通的的Java代码，在不知不觉中受到这些优秀设计思想的影响。相信许多人在看 Volley 源码此前，对异步任务控制的想法基本就是毫无想法，看完以后简直是醍醐灌顶，原来代码也能写得这么有魅力，再看看本身以前写的异步任务，“new Thread().start”...，简直是“too young, sometime naive”有没有。

看了愈来愈多Android的源码，本身的写应用的时候，也就能写出更加“Best Performance”的代码，见识了愈来愈多的开源项目，本身也可以更容易找到最符合本身应用的框架和技术方案，学习了愈来愈多的优秀的代码风格，本身也就更能写出漂亮以及容易扩展的代码。

或许对许多作Android开发来讲，平时的工做就是按照设计的图写个布局，再解析后台的数据，下班了把测试用的安卓机扔进抽屉拿出本身的苹果手机…… 但有时候花点时间看看源码，或许会以为设计代码仍是挺有意思的，特别是，当你花了两天的时间构思代码，再花两天的时间写代码，这时你可能以为你还有许多代码要写，可是忽然发现只要把你写好的接口衔接一下就都完成了，并且写了两天的代码竟然一次编译经过！更甚，产品忽然改了个需求，你在抱怨了一顿后发现只要花10分钟把原来的接口换个实现就搞定了，这或许是程序员工做中为数很少的乐趣吧。