鴻蒙系統的編譯構建是基於 Gn 和 Ninja 完成的，那麼 Gn 和 Ninjia 有什麼關係呢？具體又是如何工作的呢？想必大多數熱衷於應用開發的同學都還沒有深究過，那麼今天就藉此機會帶着大家扒一扒 Gn 和 Ninja。
我們先來說說 Ninja 吧！
Ninja 是藉由 Google Chrome 項目而誕生的一個構建工具，它的誕生目標是爲了速度。換句話說，在 Google Chrome 項目的開發過程中，開發者們認爲同類型的其它構建工具不給力，所以纔會考慮重新開發更高效的工具。要說同類型，那麼不得不提構建界的老大哥 make ！make 即 GNU Make，一個用於決定如何使用命令完成最終目標構建的程序。
在這裏強調 make 的 3 個特性：
- make 只是一個通用程序，它不知道如何具體的完成目標的構建工作
- make 需要 makefile 中的描述來決定目標構建的具體方案
- make 需要藉助其它工具（如：gcc）才能執行方案，最終完成工作
這是不是跑題了！不是說好的討論 Ninja 嗎？怎麼扯到 make 上去了？！
因爲 Ninja 可以看作是一個更好的 make ！而大多數同學都熟悉 make ，所以通過對比 make 學習 Ninja 是一個非常好的選擇！上述關於 make 的 3 個特性對於 Ninjia 同樣適用（理論上，make 有的 Ninjia 都有，並且更好！）。那麼，是不是得先學習 make 再學習 Ninja 呢？我覺得倒也不是！畢竟我們最終還是在鴻蒙上做應用開發，編譯構建系統只需要大體瞭解即可。
接下來通過一個簡單的例子向大家展示 Ninja 的用法！
test.c 是一個簡單的 Hello World 程序，用於打印一個字符串和頭文件 test.h 中常量 CONST 的值。
根據 C 程序的編譯方式可知：
- 在預處理階段 test.h 中的代碼直接嵌入test.c 中（頭文件 .h 最終成爲源文件 .c 的一部分）
- test.c 編譯後得到目標文件 test.o
- test.o 鏈接後得到最終的可執行程序 test.out
各個文件在編譯過程中有明顯的上下游關係，即：上游文件影響或者產生下游文件。
上圖即描述了編譯過程，同時也反映了這樣一個事實：任何一個文件被改動時只可能影響下游文件，而不會影響上游文件。如：test.c 被修改了，那麼可能導致編譯得到 test.o 發生改變，進而導致最終的可執行程序 test.out 改變。因此，當 test.c 被修改時，那麼應該重新觸發編譯和鏈接這兩個動作。
看到這裏，有同學可能存在這樣的疑問：怎麼知道文件已經被修改了並觸發相應動作呢？
其實很簡單，可以根據文件修改時間判斷呀！目前幾乎主流的文件系統都會記錄文件被修改的時間，所以結合文件的上下游關係可知：上游文件被修改的時間應該總是 小於等於 下游文件被修改的時間。這樣，只需要遍歷一次上面的構建圖就可以知道執行哪些動作產生最終可執行程序了。
接下來思考這樣一個問題：如何向構建工具 Ninja 描述構建圖？
Ninja 的本質是一種通用程序。既然是程序，那麼擅長的必然是處理結構化文本！因此，可以用結構化文本（Ninja腳本）來描述構建圖。
下面直接上代碼！
解讀：
1. Ninja 腳本中的 build 語句描述構建圖中的一個文件上下游關係。如：build test.o cc test.c 指明 test.o 由 test.c 通過規則 cc 而構建，test.c 在構建圖中位於 test.o 的上游，從 test.c 到 test.o 需要執行的動作通過規則 cc 定義。Ninja 通過判斷上下游文件的修改時間決定是否執行規則中定義的動作。多個 build 語句共同描述一個編譯構建圖。
2. Ninja 腳本中通過 rule 定義規則描述構建圖中需要執行的動作。如：規則 cc 所定義的具體動作是 gcc -c $in -o $out ，其中 $in 指代上游文件， $out 指代下游文件。對於 build test.o cc test.c 而言，最終執行的動作爲：gcc -c test.c -o test.o 。
3. 由 C 語言及其編譯方式可知：當源文件包含的頭文件改動時，源文件需要重新編譯。因此，在構建圖中頭文件順理成章的成爲了源文件的上游文件，需要考慮的僅僅是如何定義 rule 最終觸發編譯動作。這裏使用的技巧是通過命令 touh 更新源文件的修改時間，於是可定義 rule dp 的執行動作爲 touch $out。這樣 build test.c : dp test.h 的意思就很清楚了：當 test.h 被修改時，執行 touch test.c 更新修改時間，進而觸發重新編譯。
4. default test.out 指明默認構建的目標是 test.out，即： ninja 執行當前腳本時默認編譯構建的是 test.out。
理解了 Ninja 腳本的基本構成後就可以通過實驗進一步體會了！
1. 將上面的腳本另存爲文件，並重命名爲 build.ninja，且與 test.c 和 test.h 位於同一目錄下
2. 打開命令行定位到源碼目錄，執行 ninja > log.txt
通過編譯輸出（log.txt）以及 test.out 的運行結果可知目標構建成功。
後記：
這只是一個 Ninja 的入門級介紹，更多的細節大家可以參考附件中的手冊。同時，文中的示例代碼也可以在附件中下載。大家可以自己動手修改源碼（比如：修改 test.h 中 CONST 的值）然後自行編譯體會 Ninja 的用法。
Enjoy it！
文章相關附件可以點擊下面的原文鏈接前往學習
原文鏈接：https://harmonyos.51cto.com/posts/2972#bkwz
https://harmonyos.51cto.com/#bkwz