Android 7.0 原始碼分析專案一期竣工啦

大搜車無線開發中心發表於2018-02-28
Android原始碼

編者按
本文作者：郭孝星
個人主頁：https://github.com/guoxiaoxing

從 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 7.0 原始碼分析專案一期竣工啦

從上到下依次分為六層：

  • 應用框架層
  • 程式通訊層
  • 系統服務層
  • Android執行時
  • 硬體抽象層
  • Linux核心層

在正式閱讀本系列文章之前，請先閱讀導讀相關內容，這會幫助你更加快捷的理解文章內容。

Android系統應用框架篇

Android視窗管理框架

Android元件管理框架

Android包管理框架

Android資源管理框架

Android系統底層框架篇

Android程式框架

Android記憶體框架

Android虛擬機器框架

Android應用開發實踐篇

Android介面開發

Androidy應用優化

其他

Android系統軟體設計篇

有興趣參與此專案的小夥伴可以掃碼入群，本群主要討論Android Framework、主流開源框架以及Android工程化相關技術，本群不是一個讀者群，希望大家每個人都能成為專案的參與者。另外，為了營造一個 良好的技術氛圍，群裡儘量不要灌水閒聊，如果二維碼過期可以加我微信allenwells邀請入群。

Android 7.0 原始碼分析專案一期竣工啦

文章的最後再聊一聊工作這幾年來的感悟，其實我一向是比較少的去聊這些事情，因為覺得這些東西講多了，有點誇誇其談的感覺，但是這幾年工作下來，有幾點東西確實是感觸頗深的，這裡 簡單總結一下。

客戶第一 - 人與人之間的關係

這個挺起來好像有點官僚風的味道，但這裡要說的不是我們產品的客戶，而是說我們自己的客戶，有沒有想過這個問題，我們自己的客戶是誰？一般說來，我們向哪些人提供服務，哪些人 就是我們的客戶，比如我任職於公司的平臺架構部，我們向業務研發團隊、產品團隊，運營團隊和測試團隊輸出產品和工具，所以他們都是我的客戶，除了你提供服務的那些人外，你的leader 也是你的客戶，他會給你佈置任務，你去完成他的任務。

那麼什麼是客戶第一呢？

比方說你的leader在給你佈置任務的時候，他會根據他心目中你的能力大小來制定對任務完成結果的預期，他覺得以你的能力可以把一個10分的事情做到6分。然後他就會以六分為標準來安排任務，當你最終 完成了這些任務後，他並不會進一步的認可你的能力，因為你做的事情都在他的預期之內。所謂客戶第一，就是你需要向辦法找到leader以及其他團隊對這個事情10分的預期是什麼，然後按照這個標準去完成 任務，也就是說要高於客戶的預期去完成需求，不單單是滿足需求，而是去幫助我們的客戶解決更多的問題。

團隊合作 - 人與團隊之間的關係

團隊合作也是個老生常談的問題，但是吧這一點做好並不簡單，尤其是公司越來越大，團隊越來越多的時候，溝通成本就變得十分巨大。團隊合作主要解決三個方面的問題：我如何和我所在 的團隊進行合作？我所在的團隊如何和其他團隊合作？我所帶領的團隊如何和其他團隊合作？那所有的退隊集合在一起，往一個方向去做事

擁抱變化 - 人與產品之間的關係

擁抱變化對產品而言的，我們所寫的程式最終會變成一個產品，去解決某個商業場景下的問題，所以對於我們來說，公司的需求也絕不是隻是讓我們把程式寫好，只是把程式寫好是不夠的，我們還需要設身 處地的去考慮客戶在使用我們的產品的時候會遇到哪些問題，如果去優化解決這些問題。也就是說需求是多變的，我們要設計出能應對複雜需求的產品，擁抱變化的需求。

以上就是想分享的三點，部分內容也都是老生常談的問題，但很多事情就是這樣，萬變不離其宗，做人做事的正確方法始終都是不變的。

相關文章