最近有朋友突然問我一個問題 “你怎麼把UE4引擎程式碼看的那麼深入的？”

看到問題後我還愣了一下，因為這是第一次有人給我打了個”深入UE4”的標籤。其實我接觸虛幻引擎滿打滿算也就兩年，確實談不上深入。只是靠著平時的學習習慣積累，寫了一些相關的技術文章。

但這個事卻讓我突然意識到最容易被我忽略的學習習慣很可能是有一定價值和意義的。我只想著分享我對引擎學習的心得總結，卻從沒有想過分享我的學習方法，或許後者更為重要。

每一個人做事都有自己的風格與習慣。當你發現身邊一個人很優秀的時候，你去看一下他的24小時是怎麼度過的，然後再對比一下你的24小時，答案就很明瞭了。同理，如果你覺得學習原始碼很困難，不妨請教一下那些比較牛的”過來人”，看一下別人學習原始碼模組的流程。當然具體來說，影響一個事物的維度，細節，前提條件都很多，別人的方法照搬過來可能是行不通的，比如說別人能一天雷打不動地學10個小時，這個放到有些人身上幾乎不可能。這些道理大家都明白，我也不過多闡述。

迴歸主題，既然標題是“如何學習大型專案的原始碼”，所以下面我把自己學習虛幻引擎原始碼（C++）的思路和過程給分享給大家。

虛幻引擎原始碼大概有幾百萬行(沒有確切統計過，可以參考下面的純程式碼資料夾截圖)，最早可以追溯到1998年Epic自主研發的3D遊戲——虛幻。對於一個提供瞭如此完善功能的遊戲引擎，可以想象到他的程式碼是相當複雜的。所以，在學習的一開始你要明確，你的目的不應該是從頭到尾地讀遍他所有的原始碼，而是確定好學習目標後，抽絲剝繭地且有條理的整理出某一個具體模組的內容。

這裡先給出簡化版的總結，然後我會針對每條做進一步的闡述。

準備工作:建議準備大塊且連續的時間（細碎的時間容易中斷類關係的梳理），一個比較方便查詢的IDE或工具（VS，Notepad++等），類圖工具（staruml，Edraw等）

學習步驟（簡化版）:

• 1.決定要學習的模組，查詢官方文件、相關的總結文章，整理出大概的學習內容與目標
• 2.執行程式，觀察表現
• 3.執行原始碼，斷點除錯，從頭跟一邊原始碼的執行流程，注意函式堆疊
• 4.畫類圖、流程圖，先把遇到的重要類記錄下來，表明各個類的關係
• 5.記錄問題，把不理解的類或者內容以問題的方式記錄下來
• 6.寫文章、筆記，嘗試逐個解決之前遺留的問題

2-6可能需要持續的重複進行

學習步驟（詳細版）:

1. 查詢官方文件、相關的總結文章
   比如說我想研究網路模組，首先去官方文件、論壇、wiki裡面過一遍網路相關的所有內容，這時候遇到不懂的問題儘可能解決，解決不了的就把問題記下來，先去官方文件看我覺得是非常有必要的，因為這裡的文章是最權威的，錯誤率非常低。然後，去Google、百度搜索相關的文章與帖子，同時可以加入一些技術qq群（有一些水群果斷退了就行，保留一些優質的交流群），過一遍這些文章和資料。目前能看到比較好的技術網站大體上就是各個技術對應的官方網站（論壇）、StackOverflow、知乎、部落格園、簡書、CSDN、一些個人網站等，當然有些網站複製貼上現象嚴重，需要自己篩選。建議能找到原文連結的儘量去原文裡面看，因為你有可能從原創作者那裡看到更多優秀的文章。

2. 在執行程式的時候，我們需要調整各種引數來執行不同的情況，進而觀察其表現效果來驗證我們的猜想與結論。
   比如說，對於一個處於休眠狀態的Actor屬性是否能正常同步，如果客戶端屬性與伺服器一樣是否還會執行回撥函式等。執行程式可以快速的得到結論，然後根據結論我們可以更快速準確的進行分析。為了提高效率，最好在一開始就設定不同的配置、GM等來在專案執行時動態改變執行內容，因為大型專案一般都是編譯型語言，我們可能可能需要頻繁的修改程式碼編譯再重新執行。

3. 除錯可以說是最為關鍵的一步了，80%的細節需要你在除錯中去理解函式什麼時候執行到這裡（函式斷點）？每一步每一個屬性值是多少？屬性值什麼時候發生變化（條件斷點）？一個完整的執行流程是什麼樣的（函式堆疊）？這些問題需要你一點一點的進行跟蹤除錯，最後再去解決。

4. 畫圖的習慣可能很多人沒有，但是我個人覺得這是一個必不可少的環節，因為他可以大幅度提高你對框架理解的速度對於任何一個複雜的專案，每一個模組都會牽扯到大量的類（排除純C專案），類的關係錯綜複雜，而且為了降低耦合還可能用到各種設計模式，這些都大大提高了程式碼的閱讀難度，很有可能你看了3、4個類之後就完全搞混了他們都是幹什麼的。舉例來說，我在看UE4屬性同步模組的時候，完全被各個類之間的關係搞蒙了，所以我看到一個類就把他的類圖畫下來，看到相關的類就記錄他們的關係，最後得到了下面這樣一個簡化的類圖。經過梳理後，幾句話我就可以概括他們之間的關係。當然，除了類圖以外，還有流程圖、時序圖，甚至是你自己為了方便發明的“模組關係圖”，這時候圖的種類與規範其實沒有那麼重要，只要能幫助你理解就行。

5. 記錄的問題有兩種：別人給你的問題以及你自己給自己的問題別人給你的問題
   別人給你的問題：你在閱讀的時候不可能一帆風順，可能在第一步的時候，就已經遇到了無數的問題。這時候不要著急，按照重要程度順序依次解決，簡單的問題直接網上搜一搜，解決不了可以找身邊的大神，網上的牛人解決。如果還是不行，就把問題記下來，然後繼續學習，當你深入到一定程度的時候，你的問題可能就不攻自破了。
   自己給自己的問題：當你解決了別人給你的問題後，你應該已經理解了一大半了。不過，任何人寫的文章都不可能覆蓋到全部，你需要自己挖掘更多更深的問題，然後自己再去解答，這樣你才能做到比別人瞭解的更多，更能體現出你自己的價值。

6. 寫文章和寫筆記是有區別的，但是都很有意義
   寫文章這件事相比上面的步驟我覺得不算是必須的，這個適合那些追求完美還能擠出時間的人。你寫的東西是要給別人看的，所以你的目的是給別人講清楚。我在寫文章的時候會去考慮這個東西我說的真的對麼，有沒有把握，考慮的是否全面。在這種自我拷問下，我會盡可能的完善我的知識體系，修改文章中那些看起來不夠準確的內容。如果最後能做到給讀者講清楚的話，那你是真的會了。
   寫筆記相比寫文章要輕鬆很多，我只是把我總結的內容，學習的收穫記錄下來，不需要考慮太多的東西。雖然沒有寫文章那麼追求完美，但是這個過程中我們可能也會多了很多思考，在之後的學習過程中快速的回憶起自己學習的經驗。

備註：第一次執行這個過程是相當漫長和艱難的，如果和我一樣一開始知識儲備不夠，那麼幾乎每走一步都需要大量的學習和查資料。不過只要堅持下去，你最後會發現自己的收穫非常大，閱讀其他模組的原始碼也變得容易很多。
上面只是我學習原始碼的一個方法，可能並不適合所有人，也還有很多地方可以進一步完善。

最後，我再強調一點，如果只是為了使用好一個工具，你不需要徹徹底底的理解所有內容，因為你的時間是有限的。如果你真的是抱著學習的態度去研究原始碼細節，那請做好花費大量時間的準備並堅持下去。

有哪些更好的方法或者建議，歡迎留言評論。

更多內容歡迎關注同名微信公眾號: 遊戲開發那些事