如果瞭解很少的情況下，建議先看原始碼分析類文章，跟著梳理，瞭解加深了再自己梳理，因為主流程都不瞭解的話，看起來是挺費勁的，作為一名安卓開發者的心聲，安卓還有各種跨程序，c和c++的程式碼，更費勁

得有人帶一下，體系太龐大，像一座原始森林，要有總體認識，和關鍵點分析，不然分分鐘迷路，過了那一關越看越有意思

抓住主線，分析原始碼首先就是宏觀上知道這個原始碼的目的是什麼，例如spring就是實現了IOC和DI的功能，概念比較抽象，也可以直接去實踐一下，沒有spring和有spring寫一下建立物件的程式碼有啥不同，加深對框架的理解，只有清楚了整個框架帶來的價值之後，分析原始碼才能避免“不識廬山真面目” 的尷尬。

區分jar的邊界與職責，很多框架都是一堆的jar去不斷的整合，我們分析原始碼首先要宏觀的去看待整個框架做了什麼事情，然後再分清楚每個jar對應大概做了什麼事情，然後這樣就能在分析原始碼的時候儘量不迷路。

抽象思維，對於開源框架來說，其很重要的一個特性就是要把通用需求給穩定化，在此基礎上進行迭代，不斷的新增最新的特性，在這個過程中保持良好的相容性與擴充套件性，這就要求對其他框架採取解耦的方案，保持非入侵的方式。這樣帶來的程式碼上的體現就是處處是介面，處處是抽象類，很多方法都是模板方法。這裡的行話，就是不要“寫死”。依賴抽象而不是實現，這樣就可以儘量的松耦合，所以有意識的增強對於介面和抽象類的理解，所以很多人也認為 要比較好的閱讀原始碼首先要熟悉經典設計模式與設計原則等面向物件理論。

底層程式碼能力，這一塊是對於一些偏底層的一些技術實現的熟悉，例如反射，動態代理，位元組碼植入，或則是範型的使用，函式程式設計等語法糖的熟悉。當然如果能熟悉JUC包的東西，多執行緒的理解也非常重要。

帶著問題看原始碼，單純的閱讀的確很容易枯燥，但是我們在使用的過程中，由於前期可能主要關注在如何快速上手可能網上隨便搜尋入門教程就開始使用後，滿足了日常工作需求就沒再深入的動力，但是其中某個特性為什麼實現，例如mybatis定義的mapper介面沒有實現類，是如何注入到spring容器，帶著這樣的疑問，我們就很自然的產生了好奇心。

畫圖，影象是比文字更容易加強記憶和理解的東西，語言是後天的，但眼睛是天生的，我們應該善於利用這點，閱讀感覺有點混亂的時候就開始進行思維導圖的整理，流程圖的整理等等，這樣的腦圖是很有價值的，當然也不要因此打斷閱讀的連貫性，而是一個大的階段整理一下即可，每個人的邏輯思維強度會有些不同，可以按需掌握節奏。

其實直接看原始碼就是比較讓人難以琢磨的，因為很多時候原始碼的底層是計算機深層技術，和

表面看到的邏輯是不大一樣的，原始碼分析，可以從某一個技術點來看，自己看純理論的說明

的話，倒不如看一些圖例分析或者影片講解來得更明瞭一些，只要是大白話一些能給你舉幾

個現實的事物比較，就更加形象啦，比如說一個bean例項的建立過程，可以看看這篇文章，

https://m.toutiaocdn.com/i6745978831934325260/?app=news_article&timestamp=1593417076&use_new_style=1&req_id=202006291551150101300371352404BFFB&group_id=6745978831934325260

看看不同時期做的具體操作和為什麼這樣的做，原始碼的底層一般效率都是比較高的，尤其

這種設計風格，在以後自己的程式碼風格中可以多多借鑑！ 就像通訊技術，簡單地看一個短連線和長連線的區別，以及這樣做的優缺點，加以分析和比較！

帶著問題去看程式碼，為了解決問題去看程式碼，如果不是為了具體的開發目標，而是為了提高技術水平，應該按教程學習或自己開發開源軟體。 這類似於學習語言，放到 這個語言的環境下，經過一段時間，無意識就學會了。而想考高分而突擊背單詞，肯定一背就犯困。就比如這個問題，transaction 你看懂後，是要修改transaction 哪部分功能? 到達什麼目的，先把這些想清楚