AI单词记忆卡：基于HarmonyOS + ArkTS的智能记忆卡应用开发实战
AI单词记忆卡：基于HarmonyOS + ArkTS的智能记忆卡应用开发实战
摘要：本文详细记录了在HarmonyOS平台上使用ArkTS语言开发"AI单词记忆卡"应用的完整技术历程。文章按照"对齐→架构→原子化→审批→自动化执行→评估"六阶段开发方法论，系统阐述了从需求分析到架构设计、从任务分解到编码实现、从测试验证到复盘总结的全过程。通过丰富的ArkTS代码示例和HarmonyOS API调用实践，深度剖析了AI原生应用在鸿蒙生态中的开发范式与技术要点。全文约10,000字，适合HarmonyOS应用开发者、AI产品研发人员及对ArkTS/ArkUI技术栈感兴趣的读者阅读。
一、对齐阶段（Align）：从模糊需求到精确规范
1.1 项目背景与原始需求
"AI单词记忆卡"是一款面向英语学习者的智能背词工具，其核心诉求是：用户输入待学习的单词列表，AI自动生成结构化的记忆卡片，包含单词释义、音标、词根词缀分析、记忆技巧、搭配用法、复习计划等完整学习信息。
在当前的移动互联网教育赛道中，传统背词应用（如百词斩、墨墨背单词等）普遍存在以下痛点：
- 内容同质化：所有用户看到的是相同的词库内容，缺乏个性化定制能力
- 记忆方法单一：仅提供基础的释义和例句，缺少词根拆解、联想记忆等深度学习方法
- 复习计划机械：虽然遵循艾宾浩斯遗忘曲线，但无法根据用户的学习习惯动态调整
- 学习体验割裂：背词、查词、复习等功能分散在不同模块中，学习流不连贯
AI大模型的崛起为上述问题提供了全新的解决思路。借助大语言模型的语义理解和生成能力，我们可以为每个单词"量身定制"记忆卡片，在词根分析、联想记忆、智能例句等方面实现质的飞跃。
1.2 项目上下文分析
在着手开发之前，我们首先对现有项目结构和开发环境进行了全面分析。
1.2.1 项目结构分析
本项目基于DevEco Studio构建，是HarmonyOS原生应用。项目根目录为MyApplication，采用模块化工程结构：
MyApplication/
├── entry/ # 主模块
│ ├── src/main/
│ │ ├── ets/
│ │ │ ├── apps/ # 应用页面集合
│ │ │ │ └── AI单词记忆卡/ # 本应用模块
│ │ │ │ ├── AI单词记忆卡Page.ets # 页面层
│ │ │ │ ├── AI单词记忆卡Model.ets # 数据模型层
│ │ │ │ └── AI单词记忆卡Service.ets # 业务逻辑层
│ │ │ ├── pages/
│ │ │ │ └── Index.ets # 主入口页面（应用列表）
│ │ │ ├── entryability/
│ │ │ │ └── EntryAbility.ets # Ability生命周期
│ │ │ └── entrybackupability/
│ │ │ └── EntryBackupAbility.ets
│ │ ├── module.json5 # 模块配置文件
│ │ └── resources/ # 资源文件
│ ├── oh-package.json5 # 依赖配置
│ └── build/ # 构建产物
├── oh-package.json5 # 全局依赖配置
└── build-profile.json5 # 构建配置
从项目结构可以看出，这是一个典型的HarmonyOS多应用聚合平台——主页面Index.ets以网格形式展示所有AI应用，用户点击后通过router.pushUrl跳转到对应应用的详情页。每个应用独立封装在apps/目录下的子文件夹中，遵循"Page + Model + Service"的三层架构模式。
1.2.2 技术栈分析
- 编程语言：ArkTS（HarmonyOS的TypeScript方言，具备静态类型检查能力）
- UI框架：ArkUI（声明式UI框架，类似SwiftUI的语法风格）
- 开发工具：DevEco Studio（基于IntelliJ的IDE）
- 目标平台：HarmonyOS（设备类型为phone）
- 依赖管理：oh-package.json5（HarmonyOS的包管理配置）
- 路由方案：@kit.ArkUI的router模块
值得特别关注的是ArkTS相较于标准TypeScript的语法约束。在后续的编码阶段，我们必须严格遵守这些约束，否则编译将无法通过。例如：
- 不支持
any和unknown类型，必须显式指定类型 - 不支持解构赋值，必须使用临时变量逐字段操作
- 不支持
Function.bind、Function.apply、Function.call，需遵循传统OOP风格处理this语义 - 不支持索引签名，必须使用数组替代
- 不支持
in运算符，需使用instanceof替代 this只能在实例方法中使用，不能在独立函数和静态方法中使用
这些约束对ArkTS开发者的编码习惯提出了较高要求，但也正是这些限制保证了代码在HarmonyOS运行时中的高效执行。
1.3 需求理解与边界确认
在深入理解项目背景和技术约束后，我们梳理出"AI单词记忆卡"的核心功能需求：
| 功能模块 | 优先级 | 描述 |
|---|---|---|
| 单词列表输入 | P0 | 用户输入待学习的单词列表 |
| 记忆方法选择 | P0 | 用户选择或输入偏好的记忆方法（如词根法、联想法等） |
| AI记忆卡生成 | P0 | 基于输入调用AI服务生成结构化记忆卡片 |
| 卡片内容展示 | P0 | 展示单词、音标、词性、释义、词根、记忆法、例句、搭配、复习计划、分组建议、学习技巧 |
| 返回导航 | P1 | 提供返回上一级页面的能力 |
其中，P0为必须实现的核心功能，P1为辅助功能。本次开发的边界范围限定在"前端UI交互层 + 数据模型层 + 模拟服务层"，AI大模型的真实调用由于环境和成本的限制，在本次实现中以Service层的Mock数据替代。
1.4 疑问澄清与决策
在需求对齐过程中，我们遇到并解决了以下关键问题：
Q1：数据模型需要包含哪些字段？
经过分析，一个完整的单词记忆卡应当包含以下信息维度：
- 基础信息：单词（word）、音标（phonetic）、词性（pos）
- 语义信息：中文释义（meaning）
- 语言分析：词根（root）
- 记忆辅助：记忆技巧（mnemonic）
- 应用场景：例句（example）、搭配（collocations）
- 学习规划：复习计划（review_plan）、分组建议（grouping）、学习技巧（tips）
- 卡片集：cards（支持批量单词生成）
Q2：页面结构如何组织？
采用"输入区 + 生成按钮 + 结果展示区"的经典三段式布局。输入区收集用户参数，按钮触发生成逻辑，结果区以卡片形式展示AI生成的完整学习内容。这种布局符合用户"先输入→后查看"的操作心智模型。
Q3：如何与主页面集成？
主页面Index.ets通过apps.json配置文件维护应用列表，每个应用包含icon、title、subtitle、pageUrl等信息。AI单词记忆卡需要注册为其中一个应用，用户在主页面点击对应卡片后通过router.pushUrl跳转到本页面。
1.5 最终共识
经过上述对齐过程，我们形成了以下共识文档要点：
- 项目名称：AI单词记忆卡
- 技术栈：ArkTS + ArkUI + HarmonyOS
- 架构模式：Page（视图层）- Model（数据层）- Service（服务层）三层架构
- 核心功能：用户输入单词列表和记忆方法，AI生成结构化的记忆卡片
- 数据流：用户输入 → Page层收集 → Service层处理 → Model层封装 → Page层渲染
- 验收标准：输入框可正常录入、点击生成按钮可展示Mock数据、返回按钮可正确导航
二、架构阶段（Architect）：从共识到系统设计
2.1 整体架构设计
基于共识阶段的输出，我们设计了"AI单词记忆卡"的整体架构。架构设计遵循以下原则：
- 分层清晰：视图层、数据层、服务层各司其职，职责边界明确
- 单向数据流：数据从Service流向Model，再流向Page，避免双向绑定带来的复杂性
- 可测试性：Service层独立于UI，可以单独进行单元测试
- 可扩展性：未来接入真实AI API时，只需修改Service层，Page和Model层无需变动
架构分层图
┌─────────────────────────────────────────────────────────┐
│ UI 层 (Page) │
│ ┌──────────────────────────────────────────────────┐ │
│ │ AI单词记忆卡Page.ets │ │
│ │ ├── 输入区：单词列表 TextInput │ │
│ │ ├── 输入区：记忆方法 TextInput │ │
│ │ ├── 操作区：生成按钮 Button │ │
│ │ └── 展示区：记忆卡片 Column + ForEach │ │
│ └──────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────┤
│ 业务逻辑层 (Service) │
│ ┌──────────────────────────────────────────────────┐ │
│ │ AI单词记忆卡Service.ets │ │
│ │ ├── generateData(input) → AI单词记忆卡Data │ │
│ │ └── 内部数据处理逻辑 │ │
│ └──────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────┤
│ 数据模型层 (Model) │
│ ┌──────────────────────────────────────────────────┐ │
│ │ AI单词记忆卡Data │ │
│ │ ├── cards: string[] │ │
│ │ ├── word: string / phonetic: string │ │
│ │ ├── pos: string / meaning: string │ │
│ │ ├── root: string / mnemonic: string │ │
│ │ ├── example: string / collocations: string[] │ │
│ │ ├── review_plan: string / grouping: string │ │
│ │ └── tips: string │ │
│ └──────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────┤
│ 路由层 (Router) │
│ ┌──────────────────────────────────────────────────┐ │
│ │ @kit.ArkUI / router │ │
│ │ └── router.pushUrl / router.back() │ │
│ └──────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
2.2 模块依赖关系
Index.ets (主页面)
│
│ router.pushUrl({ url: 'apps/AI单词记忆卡/AI单词记忆卡Page' })
│
▼
AI单词记忆卡Page.ets ────import────▶ AI单词记忆卡Model.ets
│ │
│ import │ import (通过Page间接依赖)
▼ │
AI单词记忆卡Service.ets ◀───────────────────┘
│
└── 依赖：无外部依赖，纯逻辑层
依赖关系说明：
AI单词记忆卡Page.ets依赖AI单词记忆卡Model.ets（类型引用）和AI单词记忆卡Service.ets（服务调用）AI单词记忆卡Service.ets依赖AI单词记忆卡Model.ets（数据模型）AI单词记忆卡Model.ets无外部依赖，是纯数据定义- 所有文件均位于同一目录下，采用相对路径导入
2.3 数据流向设计
用户输入单词和记忆方法
│
▼
Page层收集输入 → inputData: Record<string, Object>
│
▼
点击"生成记忆卡"按钮
│
▼
调用 service.generateData(inputData)
│
▼
Service层处理输入，生成模拟数据
│
▼
返回 AI单词记忆卡Data 实例
│
▼
Page层赋值 resultData，触发UI更新
│
▼
showResult = true，条件渲染结果显示区域
│
▼
ForEach 遍历 cards 和 collocations 数组
Row 逐行展示 word/phonetic/pos/meaning 等字段
这个数据流的核心特点是：由状态变量驱动UI更新。Page层中定义了@State inputData、@State resultData、@State showResult三个状态变量，当Service返回结果并赋值给resultData后，ArkUI的响应式框架自动检测到状态变化，重新执行build()方法中与resultData相关的UI描述，从而完成视图更新。
2.4 接口契约定义
2.4.1 数据模型接口
// AI单词记忆卡Data - 核心数据模型
class AI单词记忆卡Data {
cards: string[] // 卡片列表（支持批量）
word: string // 单词
phonetic: string // 音标
pos: string // 词性
meaning: string // 中文释义
root: string // 词根
mnemonic: string // 记忆技巧
example: string // 例句
collocations: string[] // 搭配列表
review_plan: string // 复习计划
grouping: string // 分组建议
tips: string // 学习技巧
}
2.4.2 服务层接口
// 输入参数
input: Record<string, Object>
// 其中支持的键：
// '单词列表' → string 类型
// '记忆方法' → string 类型
// 返回结果
generateData(input: Record<string, Object>): AI单词记忆卡Data
2.4.3 页面层状态变量
@State inputData: Record<string, Object> = {} // 输入数据容器
@State resultData: AI单词记忆卡Data | null = null // 结果数据（可为空）
@State showResult: boolean = false // 结果展示控制
2.5 异常处理策略
在ArkTS的约束下，异常处理策略设计如下：
- 空值保护：
resultData声明为AI单词记忆卡Data | null类型，在UI渲染前通过!== null进行空值检查 - 条件渲染：通过
showResult布尔状态变量控制结果区域的显示/隐藏，避免在未生成数据时渲染空白内容 - catch子句：遵循ArkTS规范，catch子句变量不标注类型（ArkTS不支持catch子句类型标注为any或unknown）
- 数据边界：数组遍历使用
ForEach组件，当数组为空时自动不渲染内容
2.6 设计可行性验证
在架构设计完成后，我们进行了技术可行性验证，确认以下关键点均可行：
- ✅ ArkTS的
@State装饰器支持Record<string, Object>类型的状态变量 - ✅ ArkUI的
ForEach组件支持string[]数组的遍历渲染 - ✅
router.pushUrl和router.back()API在HarmonyOS中运行正常 - ✅ ArkTS类支持带构造函数的class定义（已在Model中验证）
- ✅ 条件渲染（
if表达式）在ArkUI中工作正常
三、原子化阶段（Atomize）：任务分解与工作量评估
在架构设计确认后，我们将开发任务分解为以下可独立执行、可验证的原子任务。
3.1 任务分解
任务1：数据模型层（Model）实现
文件：AI单词记忆卡Model.ets
子任务：
1.1 定义AI单词记忆卡Data类，包含所有字段声明
1.2 实现构造函数，完成字段初始化
1.3 处理数组类型字段（cards、collocations）的默认值
预估工时：0.5小时
验收标准：
- 类定义完整，所有字段类型正确
- 构造函数完成字段初始化
- 文件编译通过，无语法错误
任务2：业务逻辑层（Service）实现
文件：AI单词记忆卡Service.ets
子任务：
2.1 导入Model层依赖
2.2 定义AI单词记忆卡Service类
2.3 实现generateData方法，接收Record<string, Object>类型输入
2.4 实现Mock数据生成逻辑
2.5 返回AI单词记忆卡Data类型实例
预估工时：1小时
验收标准：
- 方法签名正确，参数和返回值类型匹配
- Mock数据生成逻辑完整
- 文件编译通过
任务3：页面视图层（Page）实现
文件：AI单词记忆卡Page.ets
子任务：
3.1 导入Model、Service依赖及router模块
3.2 定义页面组件结构，声明@State状态变量
3.3 实例化Service对象
3.4 实现顶部导航栏（返回按钮 + 标题 + 装饰图标）
3.5 实现输入区域（单词列表输入框 + 记忆方法输入框）
3.6 实现"生成记忆卡"按钮及点击事件绑定
3.7 实现结果展示区域（条件渲染 + 逐字段展示）
3.8 美化UI样式（颜色、圆角、间距、字体等）
预估工时：3小时
验收标准：
- 页面布局完整，输入区、按钮、结果区功能正常
- 点击按钮可触发Service调用并展示结果
- 返回按钮可正确导航回主页面
- UI样式符合设计规范
任务4：应用注册与路由配置
子任务：
4.1 在apps.json中注册AI单词记忆卡应用项
4.2 确认路由路径与文件路径一致
预估工时：0.5小时
验收标准：
- 主页面网格中可看到AI单词记忆卡入口
- 点击卡片可正确跳转到详情页
任务5：代码审查与测试
子任务：
5.1 ArkTS语法合规性审查（对照语法约束清单）
5.2 功能测试：输入→生成→展示全流程
5.3 边界测试：空输入、特殊字符输入
预估工时：1小时
验收标准：
- 无ArkTS语法违规
- 功能流程完整可用
- 边界情况处理合理
3.2 任务依赖关系图
任务1（Model层）
│
▼
任务2（Service层）── 依赖任务1
│
▼
任务3（Page层）── 依赖任务1、任务2
│
▼
任务4（路由配置）── 依赖任务3
│
▼
任务5（审查测试）── 依赖任务1~4
3.3 工作量汇总
| 任务 | 预估工时 | 复杂度 | 关键产出 |
|---|---|---|---|
| 任务1：Model层 | 0.5h | ★☆☆☆☆ | AI单词记忆卡Data类 |
| 任务2：Service层 | 1h | ★★☆☆☆ | 业务逻辑实现 |
| 任务3：Page层 | 3h | ★★★★☆ | 完整UI页面 |
| 任务4：路由配置 | 0.5h | ★☆☆☆☆ | 应用注册 |
| 任务5：审查测试 | 1h | ★★☆☆☆ | 质量保障 |
| 合计 | 6h | — | — |
四、审批阶段（Approve）：质量门控与审核确认
在进入编码阶段之前，我们对前面阶段的产出一一进行了审核确认，确保每个环节的质量达标。
4.1 ALIGNMENT文档审核
| 审核项 | 状态 | 说明 |
|---|---|---|
| 项目背景清晰 | ✅ 通过 | 明确了AI单词记忆卡的定位和目标用户 |
| 技术栈明确 | ✅ 通过 | ArkTS + ArkUI + HarmonyOS |
| 功能需求完整 | ✅ 通过 | 覆盖输入、生成、展示全流程 |
| 边界条件清晰 | ✅ 通过 | 明确了本次开发使用Mock数据 |
| ArkTS约束清单 | ✅ 通过 | 已逐条确认，规避了所有不支持的特性 |
4.2 架构设计审核
| 审核项 | 状态 | 说明 |
|---|---|---|
| 架构图清晰准确 | ✅ 通过 | 三层架构，职责明确 |
| 接口定义完整 | ✅ 通过 | Model、Service、Page接口均已定义 |
| 与现有系统一致 | ✅ 通过 | 沿用已有"Page+Model+Service"模式 |
| 设计可行性验证 | ✅ 通过 | 关键API和语法已验证 |
| 无过度设计 | ✅ 通过 | 仅实现当前需求，无超前设计 |
4.3 任务分解审核
| 审核项 | 状态 | 说明 |
|---|---|---|
| 任务粒度合理 | ✅ 通过 | 每个任务可在1~3小时内完成 |
| 依赖关系正确 | ✅ 通过 | 依赖图逻辑正确 |
| 验收标准明确 | ✅ 通过 | 每个任务有具体可验证的标准 |
| 工作量合理 | ✅ 通过 | 总计6小时，符合预期 |
4.4 质量门控确认
在进入编码阶段前，我们确认以下质量门控条件已满足：
- 需求边界清晰无歧义 ✅ — 功能范围、输入输出均已明确
- 技术方案与现有架构对齐 ✅ — 沿用项目已有的三层架构模式
- 验收标准具体可测试 ✅ — 每项标准均可通过编译检查或功能测试验证
- 所有关键假设已确认 ✅ — Mock数据方案已确认
- 项目特性规范已对齐 ✅ — ArkTS语法约束清单已对齐
五、自动化执行阶段（Automate）：编码实现与细节剖析
5.1 数据模型层实现（Model）
数据模型层是整个应用的"地基"，它定义了记忆卡片的数据结构。在AI单词记忆卡Model.ets中，我们定义了一个包含13个字段的类。
// 文件路径：entry/src/main/ets/apps/AI单词记忆卡/AI单词记忆卡Model.ets
export class AI单词记忆卡Data {
cards: string[] = []
word: string = ''
phonetic: string = ''
pos: string = ''
meaning: string = ''
root: string = ''
mnemonic: string = ''
example: string = ''
collocations: string[] = []
review_plan: string = ''
grouping: string = ''
tips: string = ''
constructor() {
this.cards = []
this.word = ''
this.phonetic = ''
this.pos = ''
this.meaning = ''
this.root = ''
this.mnemonic = ''
this.example = ''
this.collocations = []
this.review_plan = ''
this.grouping = ''
this.tips = ''
}
}
设计要点：
-
字段默认值：所有字段在声明时即赋予默认值（
string类型默认为空字符串''，string[]类型默认为空数组[]），这符合ArkTS"使用带初始化的声明"规范，避免了使用let v!: T的确定性赋值断言。 -
构造函数初始化：虽然字段声明时已赋值，构造函数中仍然显式进行了初始化。这是为了确保
new AI单词记忆卡Data()构造出的实例字段状态清晰可预期，也是一种防御性编程实践。 -
数组类型字段：
cards和collocations是string[]数组类型，对应ArkTS中"不支持索引签名，请改用数组"的约束。在UI层，我们将使用ForEach组件遍历这两个数组进行渲染。 -
export关键字：类使用
export导出，以便Page层和Service层通过import引用。这符合ArkTS"不支持UMD，请使用export和import语法"的规范。
5.2 业务逻辑层实现（Service）
业务逻辑层是应用的核心处理单元，负责接收Page层的输入参数，进行数据处理，并返回结构化的数据模型。在AI单词记忆卡Service.ets中，我们实现了完整的服务类。
// 文件路径：entry/src/main/ets/apps/AI单词记忆卡/AI单词记忆卡Service.ets
import { AI单词记忆卡Data } from './AI单词记忆卡Model'
export class AI单词记忆卡Service {
private model: AI单词记忆卡Data
constructor() {
this.model = new AI单词记忆卡Data()
}
// 生成AI单词记忆卡数据
generateData(input: Record<string, Object>): AI单词记忆卡Data {
let result: AI单词记忆卡Data = new AI单词记忆卡Data()
// Mock data generation based on input
let wordsVal: string = String(input['words'] || '')
result.cards = ['示例数据1', '示例数据2', '示例数据3']
result.review_plan = '生成结果：' + wordsVal
result.grouping = '生成结果：' + wordsVal
result.tips = '生成结果：' + wordsVal
return result
}
}
设计要点：
-
私有成员变量：
private model: AI单词记忆卡Data是Service类的内部状态，用于持有数据模型实例。在ArkTS中，不支持以#符号开头的私有标识符，需使用private关键字替代。 -
方法签名：
generateData方法接收Record<string, Object>类型参数，返回AI单词记忆卡Data类型。这里的Record<string, Object>是ArkTS支持的泛型工具类型之一（与Partial、Required、Readonly一样，是少数被支持的TS实用类型）。 -
Mock数据策略：目前Service层返回的是模拟数据，这是在没有接入真实AI API情况下的合理策略。当后续接入真实AI模型时，只需在
generateData方法中将Mock逻辑替换为API调用逻辑即可，Page层和Model层无需任何改动。 -
类型转换：
String(input['words'] || '')展示了如何在ArkTS中安全地处理可能为undefined的值。由于Record<string, Object>的索引访问可能返回undefined，这里使用|| ''提供默认值，再用String()进行显式类型转换。
5.3 页面视图层实现（Page）
页面视图层是用户直接交互的界面，也是代码量最大的部分。在AI单词记忆卡Page.ets中，我们实现了完整的UI交互逻辑。
// 文件路径：entry/src/main/ets/apps/AI单词记忆卡/AI单词记忆卡Page.ets
import { AI单词记忆卡Data } from './AI单词记忆卡Model'
import { AI单词记忆卡Service } from './AI单词记忆卡Service'
import { router } from '@kit.ArkUI'
@Entry
@Component
struct AI单词记忆卡Page {
@State inputData: Record<string, Object> = {}
@State resultData: AI单词记忆卡Data | null = null
@State showResult: boolean = false
private service: AI单词记忆卡Service = new AI单词记忆卡Service()
build() {
// 页面构建逻辑
}
}
5.3.1 状态变量与装饰器
ArkUI的声明式编程模型核心在于装饰器机制。我们使用了以下关键装饰器：
@Entry：标记当前组件为页面入口，使其可以被路由导航到@Component：标记当前struct为ArkUI组件，使其具备生命周期和构建能力@State：标记状态变量，当变量值变化时，自动触发UI重新渲染
三个状态变量的设计各有侧重：
inputData：收集用户输入，使用Record<string, Object>类型以支持灵活的键值对存储resultData：存储Service返回的结果，声明为AI单词记忆卡Data | null联合类型，在未生成数据时为nullshowResult：布尔类型开关，控制结果区域的显示/隐藏
5.3.2 顶部导航栏实现
Row() {
Text('← 返回')
.fontSize(13)
.fontColor('#6D28D9')
.onClick(() => { router.back() })
Blank()
Column() {
Text('📱 AI单词记忆卡')
.fontSize(17)
.fontWeight(FontWeight.Bold)
.fontColor('#4C1D95')
Text('FLASHCARD · 记忆卡')
.fontSize(9)
.fontColor('#7C3AED')
.margin({ top: 2 })
}
Blank()
Text('🃏')
.fontSize(22)
}
.width('100%')
.padding({ left: 20, right: 20, top: 16, bottom: 14 })
.backgroundColor('#F5F3FF')
设计要点：
- 布局对称：使用
Blank()组件将标题居中，左侧为返回按钮，右侧为装饰图标，形成对称的视觉平衡 - 返回导航：
router.back()是HarmonyOS的标准返回API，无需手动管理页面栈 - 层级标题：主标题使用17号字体加粗，副标题使用9号字体浅色，形成视觉层次感
- 品牌色系：采用紫色系（
#6D28D9、#4C1D95、#7C3AED），与"AI + 学习"的产品调性一致
5.3.3 输入区域实现
Column() {
Text('🃏 单词列表')
.fontSize(11).fontColor('#6D28D9').margin({ top: 6, bottom: 3 })
TextInput({ placeholder: '请输入单词列表' })
.fontSize(13).height(40).backgroundColor('#FFFFFF').borderRadius(8)
.border({ width: 1, color: '#C4B5FD' }).padding({ left: 12, right: 12 })
.onChange((val: string) => { this.inputData['单词列表'] = val })
Text('🃏 记忆方法')
.fontSize(11).fontColor('#6D28D9').margin({ top: 6, bottom: 3 })
TextInput({ placeholder: '请输入记忆方法' })
.fontSize(13).height(40).backgroundColor('#FFFFFF').borderRadius(8)
.border({ width: 1, color: '#C4B5FD' }).padding({ left: 12, right: 12 })
.onChange((val: string) => { this.inputData['记忆方法'] = val })
}
.width('100%').padding(18).backgroundColor('#FFFFFF').borderRadius(8)
.border({ width: 1, color: '#DDD6FE' }).margin({ top: 6 })
设计要点：
- TextInput组件：ArkUI的
TextInput是标准的文本输入组件，支持placeholder占位符、onChange回调等属性 - 数据收集：通过
onChange回调将用户输入实时写入inputData对
讨论HarmonyOS开发技术，专注于API与组件、DevEco Studio、测试、元服务和应用上架分发等。
更多推荐
9
0- 0
已为社区贡献113条内容
所有评论(0)