前言
作為一個基本上可以說是從0開始起步讀源碼，到現在已經完成了一系列源碼剖析技術文章的作者來講，我覺得我的經驗還是有一定的可借鑒性的
如何深入學習Framework源碼？
首先，我也是一個應用層開發者，我想大部分有“如何深入framework源碼”這個疑問的，應該大都是應用層開發
那對于我們來講，讀源碼最大的問題，其實是沒有應用場景，或者說短期來看成本高，收益底，容易半途而廢
一、
針對這個問題，首先是要要有一定的定力和研究精神，打算拿下哪部分的源碼分析，即使遇到再多的問題，也要想辦法解決，自己定的目标，跪着也要完成 其次，就是從什麼方向入手，正如題主所說，源碼很多，ndroid11的aosp整個下載下傳下來，有150G左右，是以找入手點很重要，否則隻會把源碼下載下傳完成之後就讓它在硬碟裡吃灰了
（上圖為Android11的aosp源碼大小）
針對應用層開發來講，我這裡提供幾個面試比較常問，也比較容易上手的入手點
- 四大元件啟動流程
- 應用啟動流程
- 系統啟動流程
- 音頻相關内容
這裡看上去的4個小點，其實真正做起來至少要半年的時間，因為裡面涉及的内容既多又深，就第一點來講，Activity啟動流程就夠你搞至少兩周了，這裡面會涉及
ActivityThread
,
AMS
Zygote
,
Binder
跨程序調用等一系列知識
這裡再額外提一句，看到weishu大佬回答說不要關注各種流程的跟蹤，其實我是不認同的，當然這隻是小弟我基于自身知識和認知的看法
對于廣大的應用層開發者也是一樣，我們要明白自身的定位，小白走小白的路，大佬走大佬的路，個人認為，不論是跟各種系統流程的調用鍊也好，還是按系統服務去整塊梳理也好，這些都是“過程”，而我們的目标，是深入framework源碼，試問連調用鍊都沒跟過，怎麼深入源碼？
當然，我也同意weishu大佬說的，要分析其後面涉及的思想和原理，但是這是第二層了，沒有第一層的基礎就想幹第二層的事情，無異于空中樓閣，癡人說夢
二
回到正題上來，我們已經搞定了從什麼地方入手，第二個要解決的問題是，我們需要具備什麼樣的基礎，才能讀懂源碼，或者有能力去讀源碼
個人認為，當你提出如何深入學習Framework源碼這個問題的時候，你就已經具備了最基礎的條件–探索欲和求知欲。當然這個東西比較虛，我再講一些實在的
目前新版本的AOSP底層代碼基本上都用C++重構過了，是以如果你想深入到native層，比如我們最常提到的handler，其實在native層也有一套實作，取消息的時候會通過管道機制進行喚醒通知，避免死等阻塞問題 那是不是說我們必須要先有C++或C語言基礎才能去讀源碼呢？我認為，有基礎自然好，沒有也不會有太大影響，邊度邊補相關知識，可能比學完C++再來繼續讀源碼效率要更高
是以，在我看來，不論你基礎如何，隻要有應用層開發經驗，有探索和研究Framework的興趣和欲望，這就夠了。隻要開始，就是進步
三
第三點我要講的是，深入到什麼程度是合适的。我在讀源碼的過程中，經常會跟着單個調用鍊越挖越深，比如在研究系統啟動流程的時候，甚至到了虛拟機層面和彙編層面，但是一般來講，我們不需要挖這麼深，一來是沒有必要，二來确實會花費大量精力，且很難見到成效
是以我在研究某個點的時候，會把這個點拆分成一個個的小問題，舉一個具體的例子，在研究SystemServer相關流程的時候，我給自己提了這些問題
- SystemServer是如何被fork出來的
- SystemServer做了些什麼事情
- SystemServiceManager是負責什麼的？
- SystemServiceManager是如何建立的？
- ServiceManager是負責什麼的？
- 啟動服務有幾種方式？他們之間有什麼差別？
- SystemServiceManager和ServiceManager有什麼差別？
- LocalService是負責什麼工作的？
- SystemServer是服務端程序，那麼誰是用戶端程序？他們是如何通信的？内部機制是什麼？（Binder相關的問題）
當然一上來可能提不出問題，或者不知道裡面都涉及哪些重要的類，我們可以先閱讀相關文章，有個大概的思路，此時就能提出一些基礎的問題了，然後在閱讀源碼的過程中再不斷提問和歸納，這也是我寫源碼分析文章的步驟和思路
四
第四點，我要提到的就是，要有正向回報。很多人不是沒有定力，但就是感覺讀不下去，很大的原因就是沒有正向回報。我的正向回報來自于我的文章産出，文章閱讀量和部落格關注度，以及和小夥伴們可以互相交流（但大多數時候，越深入的方向，可交流的人越有限）
我也建議大家在學習framework的時候可以多多交流，産出文章和成果，激勵自己繼續在這條路上走下去
五
第五點，需要提醒大家的是
如果你工作中有涉及相關内容（比如插件化，音視訊，launcher，setting，AudioManger等），請優先研究相關源碼
如果沒有涉及，你可以參考我上面提到的入手點進行研究，隻有你擁有了閱讀和研究的能力，才能更好的完成更有挑戰性的，甚至跨入Framework開發的行列當中
六
最後，在談一談閱讀源碼的好處吧，當你研究完一兩個子產品之後再來看，可能體會更深
正如weishu大神所講，研究framework的好處并不在于記住了哪些調用流程，這些不是目的（但是确實必不可少的過程哦！），我們的目的是從更深的，或者說從更整體的視角來看我們的技術 比如四大元件是我們開發中最常用的，但fragment也是我們開發中常用的，為什麼它不能稱得上是“第五大元件”呢？
當我研究完四大元件的源碼之後，我發現了四大元件最大的特點–支援跨程序，他們的啟動流程都會涉及我的程序是否啟動了，是否需要先跟zygote通信去fork出程序，然後再執行元件自身的啟動邏輯 是以四大元件的重量級是很重的，而frament隻是依賴于activity的的一部分，遠達不到如此的重量級，是以也就自然不能成為“第五大元件”了
- 就是在于對應用層開發能了解的更深刻；
- 當遇到一些疑難問題的時候，我們有能力通過讀源碼去深挖問題的原因，并最終解決問題；
- 在于整體的閱讀源碼能力的提升，當我們在看其他三方庫源碼的時候，就會更得心應手了，連AOSP這個近200G的龐然大物都能搞定，Okhttp在它面前簡直就是弟弟