子玥酱 （掘金 / 知乎 / CSDN / 简书 同名）

大家好，我是 子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出

我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

很多人聊鸿蒙开发时，往往停留在几个表层关键词：

• ArkUI
• 分布式能力
• Stage 模型
• FA → Stage 迁移

听起来很热闹，但真正落到一个问题上时，很多人会卡住：

如果让我从 0 开始写一个完整的原生鸿蒙 App，到底第一步该做什么？

不是写一个 Demo，而是：

• 能安装
• 能运行
• 有完整结构
• 符合真实工程规范

我们就把这件事一步一步完整走通。

一、先搞清楚“完整 App”到底指什么

在真正动手之前，必须先统一一个认知：

完整 ≠ 功能多
完整 = 架构闭环

一个最小但完整的原生鸿蒙 App，至少包含：

1. 工程结构完整

• Entry 模块
• 页面路由
• 资源目录
• 配置文件
• 构建脚本

2. 生命周期完整

• Ability 启动
• 页面创建
• 前后台切换
• 退出销毁

3. 基础能力完整

哪怕只有一个功能，也应该具备：

• 数据存储
• 状态管理
• 页面跳转
• 异常处理

这才叫真实项目的最小单元。

二、创建第一个原生鸿蒙工程

1. 新建 Stage 模型项目

在 DevEco Studio 中：

New Project → Application → Stage Model → ArkTS

为什么必须用 Stage？

因为：

FA 已经进入历史阶段，未来能力全部围绕 Stage 架构展开。

2. 默认工程结构解读

创建完成后，你会看到核心目录：

entry
 ├─ src/main/ets
 │   ├─ entryability
 │   ├─ pages
 │   └─ common
 ├─ resources
 └─ module.json5

很多初学者第一反应是：

这些文件我该从哪开始看？

正确顺序其实是：

Ability → Page → Router → State

三、让 App 真正“跑起来”

1. 编写第一个页面

先从最简单的页面开始：

@Entry
@Component
struct Index {
  build() {
    Column() {
      Text('Hello HarmonyOS')
        .fontSize(24)
        .margin(20)
    }
    .width('100%')
    .height('100%')
    .justifyContent(FlexAlign.Center)
  }
}

这一步的意义不是显示文字，而是确认三件事：

• ArkUI 声明式 UI 正常工作
• 构建链路正确
• Ability 能成功加载页面

2. Ability 生命周期确认

在 Stage 模型中，入口是 EntryAbility：

export default class EntryAbility extends UIAbility {
  onCreate() {
    console.info('Ability onCreate')
  }

  onWindowStageCreate(windowStage) {
    windowStage.loadContent('pages/Index')
  }
}

这里其实完成了一整条链路：

系统启动 → Ability 创建 → Window 创建 → 页面加载

这就是鸿蒙 App 的真正入口。

四、加入第一个“真实功能”

只有 UI 不算 App，我们需要一个可交互能力。

示例：本地待办列表

1. 页面结构

@State todos: string[] = []

Column() {
  Button('新增待办')
    .onClick(() => {
      this.todos.push(`任务 ${Date.now()}`)
    })

  List() {
    ForEach(this.todos, item => {
      ListItem() {
        Text(item)
      }
    })
  }
}

这一步说明：

状态驱动 UI 已经形成闭环。

2. 加入本地持久化

真实 App 不能只存在内存里。

import preferences from '@ohos.data.preferences'

const pref = await preferences.getPreferences(context, 'todo')

await pref.put('list', JSON.stringify(this.todos))
await pref.flush()

读取：

let data = await pref.get('list', '[]')
this.todos = JSON.parse(data)

到这里为止：

一个最小真实应用已经成立。

五、补齐“工程级能力”

接下来才是很多 Demo 不会讲、但真实项目必须有的部分。

1. 页面路由体系

router.pushUrl({
  url: 'pages/Detail',
  params: { id: 1 }
})

工程意义：

解耦页面，而不是写死跳转。

2. 全局状态管理雏形

哪怕不用复杂框架，也应该有一个集中状态区：

class Store {
  todos: string[] = []
}

export const store = new Store()

这代表：

应用开始具备“架构意识”。

3. 异常与日志

try {
  await save()
} catch (e) {
  console.error('save failed', e)
}

没有日志的 App，等于不可维护。

六、从“能跑”到“像一个真正产品”

真正的鸿蒙 App，必须再补三块：

1. 资源与主题体系

• colors.json
• media 资源
• dark mode 适配

这一步决定：

你写的是 Demo，还是产品。

2. 多设备适配思维

哪怕先不做分布式，结构也必须支持：

• 不写死尺寸
• 使用响应式布局
• 预留设备能力层

因为：

鸿蒙不是手机系统，而是设备系统。

3. 模块化拆分

当功能开始增长时：

entry
feature-todo
feature-user
common-core

这是所有长期项目的必经之路。

七、到这里，你已经完成了什么？

很多人会低估这一套流程的价值。

但实际上，你已经从 0 完成了：

• 一个可安装的原生鸿蒙 App
• 一条完整生命周期链路
• 一个真实可用的功能
• 一套基础工程结构

这不是 Demo，这是：

真正项目的起点。

总结

写鸿蒙 App 最难的，从来不是某个 API，也不是某个 UI 组件。

真正难的是：

从“零碎知识”跨越到“完整工程认知”。

而当你真正从 0 走完一遍完整流程后，很多原本模糊的概念都会突然变清晰：

• Ability 为什么这样设计
• ArkUI 为什么是声明式
• 分布式为什么必须存在

这一步，才是鸿蒙开发真正的入门。