從Android入行開始，因為工作需求和解決疑難bug的原因陸陸續續的看過一些原始碼，但都不成系統，從2016年年底開始，在Github上建了一個Android Open Source Project Analysis，專門針對 Android 7.0 原始碼進行系統的分析，這是一個從實踐角度去分析原始碼的專案，目前專案一期已經完成。
更好的閱讀體驗？?
程式碼版本
- 細分版本：N6F26U
- 分支：android-7.1.1_r28
- 版本：Nougat
- 支援裝置：Nexus 6
分析思路
Android是一個龐大的系統，Android Framework只是對系統的一個封裝，裡面還牽扯到JNI、C++、Java虛擬機器、Linux系統核心、指令集等。面對如此龐大的系統，我們得有一定的 章法去閱讀原始碼，否則就會只見樹木不見森林，陷入卷帙浩繁的細節與瑣碎之中。
- 不要去記錄那些API呼叫鏈，繪製一個序列圖理清思路即可，Android Framework中有很多複雜的API呼叫鏈，你去關注這些東西，用處不大。你需要學會的是跟蹤呼叫鏈和梳理流程的 技巧，思考一下作者是怎麼找到關鍵入口的，核心的實現在什麼地方。
- 要善於思考，要多問為什麼，面對一個模組，你要去思考這個模組解決了什麼問題，這個問題的本質是什麼，為什麼這麼解決，如果讓我來寫，我會怎麼設計。事實上不管是是計算機還是 手機，從CPU、到記憶體、到作業系統、到應用層，看似紛繁複雜，但問題的本質無非就是這麼幾種：時間片怎麼分配？執行緒/程式怎麼排程？通訊的機制是什麼？只是在不同的場景下加了具體 的優化，但問題的本質沒有改變，我們要善於抓住本質。
- 要善於去粗存精，Android Framework也是人寫的，有精華也有糟粕，並不是每行程式碼你都需要問個為什麼，很多時候沒有那麼多為什麼，只是當時那種情況下就那樣設計了。但是 對於關鍵函式我們要去深究它的實現細節。
寫作風格
和大家一樣，筆者也是在前人的書籍和部落格的基礎上開始學習Android的底層實現的，站在前人的肩膀上會看的更遠。但是這些書籍和部落格有個問題在於，文章中羅列了大量的程式碼，這樣 很容易把初學者帶入到瑣碎的細節之中，所以本系列文章在行文中更多的會以圖文並茂和提綱總結的方式來分析問題，關鍵的地方才會去解析原始碼，力求讓大家從巨集觀上理解Android的底 層實現。另外，基本上一個主題對應一篇文章，所以文章會比較長，但是文章會有詳細的標題劃分和提綱總結，可以有的放矢，閱讀自己需要的內容。
好了，讓我們開始我們的尋寶之旅吧~?
Android系統架構圖
Android系統架構圖
從上到下依次分為六層：
- 應用框架層
- 程式通訊層
- 系統服務層
- Android執行時層
- 硬體抽象層
- Linux核心層
在正式閱讀本系列文章之前，請先閱讀導讀相關內容，這會幫助你更加快捷的理解文章內容。
Android系統應用框架篇
Android視窗管理框架
- 01Android視窗管理框架：Android視窗管理框架概述
- 02Android視窗管理框架：Android應用檢視的載體View
- 03Android視窗管理框架：Android應用檢視的管理者Window
- 04Android視窗管理框架：Android應用視窗管理服務WindowServiceManager
- 05Android視窗管理框架：Android佈局解析者LayoutInflater
- 06Android視窗管理框架：Android列表控制元件RecyclerView
Android元件管理框架
- 01Android元件管理框架：Android元件管理框架概述
- 02Android元件管理框架：Android元件管理服務ActivityServiceManager
- 03Android元件管理框架：Android檢視容器Activity
- 04Android元件管理框架：Android檢視片段Fragment
- 05Android元件管理框架：Android後臺服務Service
- 06Android元件管理框架：Android內容提供者ContentProvider
- 07Android元件管理框架：Android廣播接收者BroadcastReceiver
- 08Android元件管理框架：Android應用上下文Context
Android包管理框架
Android資源管理框架
Android系統底層框架篇
Android程式框架
- 01Android程式框架：程式的建立、啟動與排程流程
- 02Android程式框架：執行緒與執行緒池
- 03Android程式框架：執行緒通訊的橋樑Handler
- 04Android程式框架：程式通訊的橋樑Binder
- 05Android程式框架：程式通訊的橋樑Socket
Android記憶體框架
Android虛擬機器框架
Android應用開發實踐篇
Android介面開發
- 01Android介面開發：View自定義實踐概覽
- 02Android介面開發：View自定義實踐佈局篇
- 03Android介面開發：View自定義實踐繪製篇
- 04Android介面開發：View自定義實踐互動篇
Android應用開發
- 01Android應用優化：優化概述
- 02Android應用優化：啟動優化
- 03Android應用優化：介面優化
- 04Android應用優化：記憶體優化
- 05Android應用優化：影象優化
- 06Android應用優化：網路優化
- 07Android應用優化：併發優化
- 08Android應用優化：優化工具
Android媒體開發
其他
Android系統軟體設計篇
歡迎關注我們的微信公眾號，新文章會第一時間釋出到掘金部落格與微信公眾平臺，我們也有自己的交流群，下方是QQ交流群，微信群已滿，可以加我微信 allenwells 邀請入群。
微信公眾平臺
QQ交流群
關於此專案後續的計劃
一個人的力量是有限的，後續此專案會做成一個團體專案，在Github建立新的工作組和新的Repo，設計新的名字和Logo，每篇文章會在文章頭部註明作者的名字和Github賬號。希望有更多的小夥伴參與進來，不僅僅是學習原始碼原理，也可以提升自己的技術品牌。
後續的文章內容會按照難易程度進行分級，大家可以按照自己擅長的部分進行認領，還會定義文件規範、PR規範與參與方式等，會先出一個草案供大家討論，這是個比較細緻的事情，剛來公司事情比較多，等忙完這一段再著手去做。
大家有空也可以考慮一下自己擅長什麼以及想要做哪一塊的內容。以及專案運作的一些核心問題：① 如何保護作者的智慧財產權，署名？核心貢獻者？② 專案的名字和Logo ③ 文件規範、繪圖規範、PR規範。④ 專案的具體內容和目錄。⑤ 參與方式，希望參與內容的可以成為作者，進行實際的內容創作。希望成為讀者的可以參與校對，校對人的名字也會被寫在文章頭上，校對的任務是糾錯，包括：錯別字、錯誤排版、錯誤拼寫以及可能有偏差的內容。
文章的最後再聊一聊工作這幾年來的感悟，其實我一向是比較少的去聊這些事情，因為覺得這些東西講多了，有點誇誇其談的感覺，但是這幾年工作下來，有幾點東西確實是感觸頗深的，這裡 簡單總結一下。
客戶第一 - 人與人之間的關係
這個挺起來好像有點官僚風的味道，但這裡要說的不是我們產品的客戶，而是說我們自己的客戶，有沒有想過這個問題，我們自己的客戶是誰？一般說來，我們向哪些人提供服務，哪些人 就是我們的客戶，比如我任職於公司的平臺架構部，我們向業務研發團隊、產品團隊，運營團隊和測試團隊輸出產品和工具，所以他們都是我的客戶，除了你提供服務的那些人外，你的leader 也是你的客戶，他會給你佈置任務，你去完成他的任務。
那麼什麼是客戶第一呢？
比方說你的leader在給你佈置任務的時候，他會根據他心目中你的能力大小來制定對任務完成結果的預期，他覺得以你的能力可以把一個10分的事情做到6分。然後他就會以六分為標準來安排任務，當你最終 完成了這些任務後，他並不會進一步的認可你的能力，因為你做的事情都在他的預期之內。所謂客戶第一，就是你需要向辦法找到leader以及其他團隊對這個事情10分的預期是什麼，然後按照這個標準去完成 任務，也就是說要高於客戶的預期去完成需求，不單單是滿足需求，而是去幫助我們的客戶解決更多的問題。
團隊合作 - 人與團隊之間的關係
團隊合作也是個老生常談的問題，但是吧這一點做好並不簡單，尤其是公司越來越大，團隊越來越多的時候，溝通成本就變得十分巨大。團隊合作主要解決三個方面的問題：我如何和我所在 的團隊進行合作？我所在的團隊如何和其他團隊合作？我所帶領的團隊如何和其他團隊合作？那所有的退隊集合在一起，往一個方向去做事
擁抱變化 - 人與產品之間的關係
擁抱變化對產品而言的，我們所寫的程式最終會變成一個產品，去解決某個商業場景下的問題，所以對於我們來說，公司的需求也絕不是隻是讓我們把程式寫好，只是把程式寫好是不夠的，我們還需要設身 處地的去考慮客戶在使用我們的產品的時候會遇到哪些問題，如果去優化解決這些問題。也就是說需求是多變的，我們要設計出能應對複雜需求的產品，擁抱變化的需求。
以上就是想分享的三點，部分內容也都是老生常談的問題，但很多事情就是這樣，萬變不離其宗，做人做事的正確方法始終都是不變的。