gn文件編譯

① 給Chromium增加 Android 手機管理和投屏

要給Chromium增加Android手機管理和投屏功能，可以按照以下步驟進行：

Android手機管理功能實現步驟：

1. 創建代碼目錄：

   • 在Chromium的src目錄下創建adbdev目錄，用於存放相關代碼。

2. 設置編譯參數：

   • 在adbdev/build/release.gn文件中設置編譯參數，以簡化命令行輸入。

3. 研究並實現SidePanel功能：

   • 借鑒Read List功能的實現方式，該功能基於WebUI並由SidePanelCoordinator管理。
   • 在SidePanel中添加一個空頁面，作為Android手機管理功能的基礎。

4. 創建WebUI資源：

   • 創建adbdev/webui_resource目錄，用於構建簡單的空白Web頁面。
   • 將Web資源打包進Chrome瀏覽器。

5. 放置WebUI Controller代碼：

   • 在adbdev/webui目錄下放置WebUI Controller代碼，用於載入資源。

6. 添加編譯依賴：

   • 將adbdev加入Chrome的編譯依賴中，並添加Factory入口。

7. 實現設備監視功能：

   • 通過訪問chrome://adbdev.topchrome/，在HTML和Controller間建立通信。
   • 利用Chromium已實現的硬體設備監聽服務，支持USB設備，通過監聽USB消息得知設備插入和拔出。
   • 通過Mojo消息將設備狀態告訴HTML頁面進行顯示。

8. 定義通知介面：

   • 定義通知介面，完成設備管理功能，此過程無需額外編碼，只需拼裝Chromium現有能力。

Android屏幕投屏功能實現步驟：

1. 實現投屏原理：

   • 借鑒scrcpy原理，通過TCP傳輸Android UI視頻流和控制數據。

2. 渲染視頻流：

   • 使用WebGL渲染解碼後的YUV數據，或使用插件進程處理視頻解碼和數據收發。

3. 創建插件框架：

   • 創建adbdev/plugin目錄，編寫插件框架。
   • 注冊插件並添加編譯依賴。
   • 注意設置ContentSecurityPolicy，確保安全。

4. 整合ADB操作：

   • 將ADB操作整合到WebUI Controller中，利用Chromium的Adb Client實現ADB操作，簡化依賴。
   • 定義新介面供Web端控制。

5. 支持滑鼠和鍵盤操控：

   • 將滑鼠和鍵盤事件轉換為scrcpy消息格式。
   • 通過Control通道發送至Android設備，實現操控功能。

通過上述步驟，可以在Chromium中實現Android手機管理和投屏功能。

② 【XR806開發板試用】基礎篇，從零開始搭建一個LCD彩屏時鍾（ST7735S驅動）

本文從搭建XR806開發環境開始，逐步引導讀者實現通過SPI屏幕（ST7735S驅動）顯示時間，連接WiFi實現ntp對時。具體步驟如下：

首先，基於ubuntu 20.04，安裝鴻蒙官方給的開發環境所需的依賴包。創建並進入xr806_openharmony文件夾，進行代碼初始化和配置。

然後，下載編譯工具鏈，解壓到指定文件夾。完成鴻蒙官方倉庫的配置後，執行代碼同步。

進入原生SDK目錄，配置並執行首次編譯，初始化編譯環境。在編譯過程中，選擇wifi_skylark並完成相應的配置。

接著，連接屏幕與開發板，並在新建的工程文件夾lcd_weather_clock中創建頭文件和源文件，配置BUILD.gn文件。

在代碼編寫階段，重點實現驅動ST7735S屏幕的功能，連接WiFi，設定sntp伺服器自動對時，並將時間和日期顯示到LCD屏幕上。關鍵代碼部分，如SPI初始化、GPIO初始化以及sntp伺服器設定等。

編譯固件後，按照GPIO口定義連接屏幕，並通過數據線將開發板連接到電腦。檢查串口連接狀態，賦予用戶讀寫許可權。配置下載工具，修改USB轉串口路徑和固件存放位置。

使用下載工具執行命令，完成固件下載。程序運行前，需要按下開發板的復位鍵或拔插USB數據線，實現程序啟動。

最後，提供了工程文件下載鏈接和參考文章，確保讀者能夠獲取完整代碼和實現更多功能的指導。

③ 在windows下使用vs2022編譯v8引擎的穩定版本(2023.7.22)

為了在Windows環境下使用VS 2022編譯v8引擎的穩定版本，本指南將分步驟進行詳細說明。首先，確保環境配置完備：安裝python3.10和Git，同時安裝VS 2022並啟用C++的桌面開發和通用Windows平台開發功能。

下一步是下載v8項目源代碼，但請注意，v8官方已停止在官方網站發布博客來更新穩定版本。因此，推薦訪問谷歌的分支詳情頁，例如chromiumdash.appspot.com，選擇一個穩定版本，例如10.4-lkgr，然後創建名為「v8」的文件夾並進入該文件夾。

配置代理，確保其與您使用的代理工具埠匹配。系統全局代理設置也需相應調整，以便v8項目能夠正確下載依賴。保持cmd窗口和代理程序運行狀態，進行後續操作。

接下來，下載開發工具，訪問commondatastorage.googleapis.com，找到並下載名為「depot_tools」的包，解壓後將其路徑添加至PATH環境變數中，確保Python已安裝且其目錄在PATH中位於depot_tools之前。

回到代理設置完成的cmd窗口，設置環境變數以允許谷歌工具下載Windows相關的工具。執行命令`set DEPOT_TOOLS_WIN_TOOLCHAIN=0`，然後運行`fetch v8`命令拉取源代碼。拉取過程可能需幾分鍾，直至完成。

成功拉取源代碼後，進入v8文件夾，並設置環境變數`DEPOT_TOOLS_WIN_TOOLCHAIN=0`，以確保動態庫編譯模式。使用`git checkout 10.4-lkgr`檢出版本。執行`gclient sync -v`完成依賴處理。

在cmd中運行`python3 tools\dev\v8gen.py x64.release -vv -- is_component_build=true v8_static_library=false`配置x64 release動態庫編譯。若遇到錯誤提示，需確保安裝Windows 10 SDK版本10.0.20348.0，包含「Debugging Tools for Windows」功能。

安裝SDK後，再次編譯動態庫，確保成功後使用ninja工具進行編譯。此過程耗時，且CPU佔用率高，建議避免進行其他操作。

編譯完成後，通過輸入`console.log("test"+4*8),5*7;`測試d8.exe程序，結果輸出`test32，返回35`，表明編譯成功。將動態庫復制至指定文件夾作為運行時。

為運行時准備靜態庫，首先刪除v8文件夾中的out.gn文件夾，設置環境變數`DEPOT_TOOLS_WIN_TOOLCHAIN=0`，使用`python3 tools\dev\v8gen.py x64.release -- v8_monolithic=true v8_use_external_startup_data=false use_custom_libcxx=false is_component_build=false treat_warnings_as_errors=false v8_symbol_level=0 is_clang=false`配置靜態庫編譯，然後使用ninja工具編譯。

成功編譯後，找到並復制v8_monolith.lib作為靜態庫。重復此過程以生成不同版本和環境下的靜態庫。

同樣，為ia32版本執行動態和靜態庫編譯，配置方法與x64版本類似，確保路徑和文件名正確。

完成所有編譯步驟後，即可在本地環境中使用v8引擎的穩定版本。記得將編譯文件存儲並共享，方便使用。

整個過程復雜且耗時，需耐心並仔細遵循每一步驟。希望本指南能幫助您成功編譯v8引擎，如有任何疑問或困難，請查閱相關博客或參考文章。

④ Open Harmony移植：build lite編譯構建過程

本文介紹了Open Harmony移植過程中的build lite輕量級編譯構建系統及其編譯構建過程。通過配置文件build\lite\BUILD.gn，可以執行編譯操作hb build。本文詳細闡述了如何調用和編譯產品解決方案、晶元開發板解決方案以及內核代碼的過程。

產品解決方案代碼的調用：在BUILD.gn配置文件中，通過構建目標//build/lite:proct實現調用產品解決方案代碼。進一步調用則依賴於特定的代碼配置文件，如恆玄的device\soc\bestechnic\bes2600\BUILD.gn文件。產品解決方案根目錄下的ohos.build文件解析出子系統和部件信息，生成到特定的文件路徑中，用於後續編譯構建。

晶元開發板解決方案代碼的調用：在kernel\liteos_m\BUILD.gn文件中，通過構建目標moles實現對晶元開發板解決方案代碼的調用。根據開發板是否與soc進行文件夾解耦，選擇不同的構建配置文件路徑。moles構建目標進一步被libkernel和kernel構建目標調用。

內核代碼的調用：在生成的文件out\v200zr\display_demo\build_configs\kernel\liteos_m\BUILD.gn中，通過構建目標build_kernel_image和_liteos、liteos構建目標，最終調用//build/lite:ohos文件。該文件依次調用各個子系統和部件的構建目標，完成內核代碼的編譯。

此外，public的config定義在BUILD.gn文件中，用於判斷晶元和開發板是否解耦，從而選擇正確的配置集位置。然而，在實際的晶元、開發板代碼目錄中的BUILD.gn文件中並未發現config(「public」)，這在實現上可能存在一些不一致之處。

通過深入理解這些調用和編譯過程，可以更深入地掌握Open Harmony移植過程中的build lite輕量級編譯構建系統及其工作機制。後續可以進一步研究相關代碼和機制，以實現更細致和深入的了解。