欢迎加入开源鸿蒙跨平台社区： https://openharmonycrossplatform.csdn.net

如果说第一天是“纸上谈兵”准备环境，那么第二天就是真正的“短兵相接”。今天我们的目标是：基于 Flutter for OpenHarmony 模板创建一个工程，并让它在模拟器、真机、开发板这三种迥异的终端上跑起来。

一、 工程初始化的隐形坑

在克隆完 AtomGit 仓库并准备创建 Flutter 项目时，最容易犯的错误是工程层级的混乱。

1. 混合工程的 .gitignore 陷阱

Flutter 项目本质上是一个“壳”，它包含 Android、iOS 以及我们今天的主角 ohos 目录。

• 技术深度： 默认的 Flutter .gitignore 并不包含鸿蒙特有的构建中间产物（如 .test、oh_modules、build 下的 .hap 文件）。

• 对策： 在提交代码前，务必检查 ohos 目录下的 oh_modules 是否被排除。否则，你推送的将是数万个细碎的小文件，直接导致 AtomGit 仓库因容量或索引过载。

二、 多终端运行验证

这是今天最核心的实验环节。同一套代码，在不同终端上的反馈截然不同。

1. 模拟器：逻辑验证的“温室”

模拟器（通常是 x86_64 架构）主要解决的是 UI 布局验证。

• 发现问题： 部分 Flutter 插件涉及底层 C++ 代码（如某些加密库）时，模拟器可能会因为指令集不匹配而崩溃。

• 排查思路： 检查 flutter build hap --debug 生成的是否包含对应架构的 .so 库。

2. 真机与开发板（DAYU200）

这是初学者最容易卡住的地方。鸿蒙系统为了安全，要求所有 HAP 包必须经过签名。

• 深度解析： 不同于 Android 只要开启“允许未知来源”即可，鸿蒙真机调试需要配置 p12 证书、p7b 配置文件。

• 实战方案： 在 DevEco Studio 中通过 File -> Project Structure -> Signing Configs 开启 Automatically generate signature。

• 注意： 开发板（如 DAYU200）如果固件版本过低，可能会导致 hdc 无法识别签名，务必保持固件版本与 SDK API Version 对齐。

---

三、 技术攻坚

在多终端切换运行过程中，我遇到了经典的 hdc list targets 找不到设备的问题。

现象： 模拟器开着，同时插上 DAYU200，DevEco Studio 无法识别任何一个。 底层原因： hdc server 版本冲突。当你同时安装了华为手机助手和 DevEco Studio 时，后台可能运行着两个不同版本的 hdc 进程。

解决方案：

1. 执行 hdc kill 关掉所有进程。

2. 在环境变量中显式指定使用 DevEco Studio 路径下的 hdc.exe。

3. 通过 hdc tmode usb 或 hdc tmode port 强制切换通信模式。

---

四、 AtomGit 代码提交规范

任务要求代码“可直接拉取并复现”。这不仅是文件的完整，更是提交记录的专业性。

git add .

git commit -m "feat: 完成鸿蒙跨平台工程创建与多终端运行验证，新增日志与截图"

git push origin main

1. 提交粒度与 Commit Message

不要一次性提交所有改动。我采用了以下规范：

• feat: init flutter ohos project structure

• chore: add .gitignore for harmonyos build artifacts

• test: complete running verification on emulator and DAYU200

2. 运行日志凭证

我将编译过程中的关键日志 build.log 以及真机运行时的截图存放在了工程根目录的 docs/evidence 文件夹下。

---

五、 Day 2 复盘总结

今天最大的收获是理解了 HAP 包的构建生命周期。从 Flutter 的 build hap 命令调用，到触发 hvigor 进行 ArkTS 侧的编译打包，最后通过 hdc 进行分布式部署。