鸿蒙 ArkUI 项目为什么容易变成“巨型页面文件”？

网罗开发 （小红书、快手、视频号同名）

大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验 。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员

👋 大家好，我是展菲！

📱 全网搜索"展菲"，即可纵览我在各大平台的知识足迹。

📣 公众号"Swift社区"，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

💬 微信端添加好友"fzhanfei"，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。

📅 最新动态：2025 年 3 月 17 日

快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！

文章目录

• • 引言
  • [一、ArkUI 天生是"页面中心"的](#一、ArkUI 天生是“页面中心”的)
  • [二、声明式 UI 导致 UI 代码膨胀](#二、声明式 UI 导致 UI 代码膨胀)
  • 三、业务逻辑容易写在页面里
  • 四、组件拆分意识不足
  • 五、状态越来越多
  • [六、没有 Service 层](#六、没有 Service 层)
  • 七、一个典型的"巨型页面"
  • 八、如何避免"巨型页面文件"
  • • [1 UI 必须拆组件](#1 UI 必须拆组件)
    • [2 业务逻辑下沉到 Service](#2 业务逻辑下沉到 Service)
    • [3 数据结构统一](#3 数据结构统一)
    • [4 状态管理抽离](#4 状态管理抽离)
  • 九、推荐的代码结构
  • 总结

引言

很多开发者第一次写鸿蒙应用时，都会有一种感觉：

ArkUI 写起来很爽。

UI 写法很简洁：

Column() {
  Text("Hello")
  Button("点击")
}

页面逻辑也很直观：

@State list: string[] = []

但项目写到 2～3 个月以后，很多人会遇到一个非常典型的问题。

一个页面文件突然变成这样：

HomePage.ets
  1500 行代码

甚至更夸张：

3000 行
5000 行

于是项目逐渐变成了：

巨型页面文件项目。

那么问题来了：为什么 ArkUI 项目特别容易出现这种情况？

这其实和 ArkUI 的设计方式有关。

一、ArkUI 天生是"页面中心"的

ArkUI 的核心设计是：

页面 = UI + 状态 + 逻辑

例如一个典型页面：

@Entry
@Component
struct HomePage {

  @State list: string[] = []

  build() {
    Column() {
      ForEach(this.list, (item) => {
        Text(item)
      })
    }
  }
}

结构非常集中，很多人写着写着就会变成：

页面
 ├─ UI
 ├─ 网络请求
 ├─ 数据处理
 ├─ 事件逻辑
 └─ 状态管理

全部放在一个文件里。

二、声明式 UI 导致 UI 代码膨胀

ArkUI 使用 声明式 UI，例如：

Column() {
  Row() {
    Image(user.avatar)
    Text(user.name)
  }

  Row() {
    Text("等级")
    Text(user.level)
  }

  Row() {
    Text("积分")
    Text(user.score)
  }
}

当 UI 复杂时，很容易变成：

嵌套 5 层
嵌套 10 层

代码可能变成：

Column
  Row
    Column
      Row
        Stack

于是 UI 代码会快速膨胀。

三、业务逻辑容易写在页面里

很多人一开始会这样写：

async loadData() {
  const result = await fetch("api")
  const data = await result.json()
  this.list = data
}

或者：

async login() {
  const result = await http.post("/login")
  this.user = result.data
}

当业务变多时，页面里会出现：

loadData
refreshData
loadMore
login
logout
updateProfile

页面瞬间变成 业务中心。

四、组件拆分意识不足

很多 ArkUI 新手不会拆组件，例如一个页面：

用户信息
订单列表
推荐内容
广告

很多人会直接写在一个页面里：

Column() {

  // 用户信息
  Row() { ... }

  // 订单列表
  List() { ... }

  // 推荐内容
  Column() { ... }

}

但正确做法应该是拆组件：

components
 ├─ UserInfoCard
 ├─ OrderList
 └─ RecommendList

页面只负责组合：

Column() {
  UserInfoCard()
  OrderList()
  RecommendList()
}

五、状态越来越多

ArkUI 的状态使用 @State。例如：

@State loading: boolean = false
@State list: string[] = []
@State page: number = 1
@State hasMore: boolean = true

当业务复杂时，页面可能变成：

20 个 State
30 个 State

状态管理混乱。

六、没有 Service 层

很多项目没有 Service 层。例如：

Page
  ├─ HTTP
  ├─ 数据处理
  └─ UI

正确做法应该是：

Page → Service → Network

示例，Service：

export class ArticleService {

  async getArticles() {
    return await HttpClient.get("/articles")
  }

}

页面：

let service = new ArticleService()
this.list = await service.getArticles()

这样页面就不会膨胀。

七、一个典型的"巨型页面"

很多项目最终会变成：

HomePage.ets
  ├─ 50 个 State
  ├─ 30 个方法
  ├─ 1500 行 UI
  └─ 业务逻辑

这样的页面会出现几个问题：

• 难读
• 难维护
• 难复用

稍微改一点就可能引发 Bug。

八、如何避免"巨型页面文件"

解决办法其实很简单：

1 UI 必须拆组件

例如：

components
 ├─ UserCard
 ├─ ArticleItem
 └─ CommentList

页面只负责组合。

2 业务逻辑下沉到 Service

services
 ├─ UserService
 ├─ ArticleService
 └─ CommentService

页面只调用。

3 数据结构统一

models
 ├─ UserModel
 └─ ArticleModel

避免页面写各种数据结构。

4 状态管理抽离

例如：

store
 └─ UserStore

避免页面维护过多状态。

九、推荐的代码结构

如果项目稍微大一点，建议结构如下：

entry
 ├─ pages
 ├─ components
 ├─ services
 ├─ models
 ├─ store
 └─ utils

这样职责非常清晰：

Page → UI
Component → UI模块
Service → 业务逻辑
Model → 数据结构
Store → 状态

总结

鸿蒙 ArkUI 项目容易变成"巨型页面文件"，主要原因有：

1. ArkUI 是页面中心架构
2. 声明式 UI 容易膨胀
3. 业务逻辑容易写在页面
4. 组件拆分不足
5. 状态管理混乱

解决办法其实只有一句话：

页面只写 UI，业务逻辑全部下沉。

只要坚持这个原则，ArkUI 项目基本不会失控。