Android 7.0 源碼分析項目一期竣工啦

時間 2019-11-17

原文原文鏈接

編者按
本文做者：郭孝星
我的主頁：https://github.com/guoxiaoxingandroid

從 Android 入行開始，由於工做需求和解決疑難bug的緣由陸陸續續的看過一些源碼，但都不成系統，從2016年年末開始，在Github上建了一個Android Open Source Project Analysis，專門針對 Android 7.0 源碼進行系統的分析，這是一個從實踐角度去分析源碼的項目，目前項目一期已經完成。git

更好的閱讀體驗？👇github

點擊進入GitBook閱讀

第一次閱覽本系列文章，請參見導讀，更多文章請參見文章目錄。編程

代碼版本設計模式

細分版本：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窗口管理框架

Android組件管理框架

Android包管理框架

Android資源管理框架

01Android資源管理框架：資源管理器AssetManager

Android系統底層框架篇

Android進程框架

Android內存框架

Android虛擬機框架

01Android虛擬機框架：Java類加載機制

Android應用開發實踐篇

Android界面開發

Androidy應用優化

其餘

Android系統軟件設計篇

有興趣參與此項目的小夥伴能夠掃碼入羣，本羣主要討論Android Framework、主流開源框架以及Android工程化相關技術，本羣不是一個讀者羣，但願你們每一個人都能成爲項目的參與者。另外，爲了營造一個良好的技術氛圍，羣裏儘可能不要灌水閒聊，若是二維碼過時能夠加我微信allenwells邀請入羣。

文章的最後再聊一聊工做這幾年來的感悟，其實我一貫是比較少的去聊這些事情，由於以爲這些東西講多了，有點誇誇其談的感受，可是這幾年工做下來，有幾點東西確實是感觸頗深的，這裏簡單總結一下。

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

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

那麼什麼是客戶第一呢？

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

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

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

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

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

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