鸿蒙项目需要先判断应用、设备和生态目标
不是所有Android代码都能直接迁移，也不是所有设备都适合相同接入方式。先确认目标设备、系统版本和生态能力，才能控制改造范围。
现有应用迁移边界不清
Java/Kotlin、Flutter、React Native和H5的可复用范围不同。
第三方SDK兼容性不确定
音视频、地图、推送、支付和设备SDK需要逐项评估鸿蒙支持情况。
设备与应用协同复杂
BLE、Wi-Fi和局域网设备需要处理发现、配网、控制、状态同步和升级。
分布式能力容易被过度设计
跨设备流转应围绕真实用户任务，而不是为了展示技术增加复杂度。
OpenHarmony硬件适配工作量大
芯片、驱动、系统服务、板级支持和测试都需要目标硬件验证。
测试与上架要求变化
需要覆盖权限、隐私、设备兼容、性能和应用市场审核要求。
同一项目可以同时覆盖鸿蒙应用、智能设备和IoT平台
应用层负责用户交互和设备控制，设备层负责驱动、通信和本地能力，平台层负责账号、设备、消息、数据与远程运维。三层接口在项目早期统一定义。
- 01
HarmonyOS应用
使用ArkTS、ArkUI和系统能力构建手机、平板或其他终端应用。
- 02
设备接入
通过BLE、Wi-Fi、Zigbee、局域网或云端API完成配网和控制。
- 03
OpenHarmony适配
按目标芯片与硬件完成板级支持、驱动、系统服务和应用适配。
- 04
IoT平台联动
连接账号、设备模型、消息、告警、OTA和业务后台。
从关键能力到可用系统， 三类开发服务覆盖应用、硬件和行业IoT
保留源页面的鸿蒙原生应用、智能硬件和物联网解决方案三大区块，并补充迁移评估、测试和上线边界。
围绕鸿蒙原生能力建立稳定技术栈
技术选择取决于目标设备、系统版本、现有代码和第三方依赖，不以单一框架覆盖所有项目。
ArkTS
用于HarmonyOS应用业务逻辑、状态和系统能力调用。
ArkUI
构建鸿蒙应用界面、交互和多设备适配。
DevEco Studio
完成开发、调试、性能分析、构建和签名。
HarmonyOS SDK/API
接入通知、网络、存储、媒体、设备和安全能力。
OpenHarmony
用于行业设备、开发板和定制系统的适配与应用开发。
分布式能力
按真实任务实现跨设备发现、流转、同步和协同。
从单一应用到多设备协同，按产品目标选择范围
项目可从一个核心应用开始，也可以同步规划设备、平台和运营后台。
智能家居与家电
设备配网、控制、场景联动、状态同步和家庭成员权限。
运动健康设备
连接传感器、可穿戴设备和健康数据，提供本地与云端分析。
智慧办公终端
实现会议、门禁、环境、工位和设备协同管理。
工业与行业设备
在OpenHarmony终端上实现采集、控制、边缘处理和平台接入。
把技术能力落实到可验证的业务结果
项目目标在启动时转化为可检查的功能、性能、数据和交付标准，避免只完成演示而不能投入实际使用。
明确迁移边界
先评估代码、SDK和系统能力，减少进入开发后反复推倒重来。
应用与设备一起设计
统一配网、控制、状态、异常和升级接口，提高交付一致性。
保留后续扩展能力
设备模型和平台接口支持更多终端、账号和业务场景。
覆盖上线全过程
从设计、开发、测试到签名与上架材料形成完整交付。
先验证高风险环节，再逐步扩大交付范围
每个阶段都有明确输入、输出和验收条件，便于双方控制范围、技术风险与上线节奏。
- 01
目标设备与版本确认
明确手机、平板、行业终端或OpenHarmony硬件范围。
- 02
应用与SDK盘点
评估现有页面、业务逻辑、第三方SDK和系统服务。
- 03
原型与关键链路验证
优先验证登录、设备连接、核心业务和高风险SDK。
- 04
开发与设备联调
并行推进应用、设备、平台接口和异常流程。
- 05
测试与发布支持
完成兼容、性能、隐私、签名、上架与版本维护。
