有沒有必要閱讀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分鐘把原來的接口換個實現就搞定了，這或許是程序員工做中爲數很少的樂趣吧。