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轻量级编译构建系统及其工作机制。后续可以进一步研究相关代码和机制，以实现更细致和深入的了解。