鸿蒙 ArkTS 实战Failure Review Book 从失败复盘本到个人成长工具完整解析前言Failure Review Book 是一个基于鸿蒙 ArkTS 声明式 UI 编写的轻量应用核心目标是把事件、原因、经验和行动串成闭环的复盘工具。它不是复杂后台系统而是把一个真实的个人成长场景拆成状态字段、交互按钮、结果反馈和可读布局四个部分。本文围绕项目真实的Index.ets页面展开分析它如何用State驱动界面如何用函数处理交互如何用Column、Row、Scroll、Grid或Stack组织页面并进一步讨论在鸿蒙应用里做同类工具时需要注意的结构、体验和可扩展点。图示说明本文配图用于表达鸿蒙应用从状态、组件到交互反馈的组织关系重点是帮助理解页面结构而不是替代真实运行截图。可以配合阅读 HarmonyOS 应用开发文档、ArkTS 语言基础、ArkUI 声明式开发范式、组件参考 等资料理解本文涉及的 ArkTS 与 ArkUI 基础能力。一个小型鸿蒙应用的质量往往不取决于页面元素数量而取决于状态是否清晰、交互是否闭环、结果是否能被用户立即理解。一、项目定位与使用场景1.1 应用解决的问题失败复盘本 面向的场景是项目延期、错过截止时间或决策失误后的经验沉淀。在这个场景中用户真正需要的不是一个大而全的数据库而是一个进入成本很低的记录面板。页面打开后用户可以直接看到主题、当前状态和可操作按钮不需要先学习复杂流程。这类应用很适合用鸿蒙 ArkTS 实现因为 ArkUI 的声明式语法能把页面结构和状态关系写得非常集中。1.2 目标用户与操作节奏本文面向 希望把失败记录转化为下一次行动规则的个人效率应用开发者。从交互节奏看Failure Review Book 更接近一个单页工具用户输入当前信息。点击主要按钮触发状态变化。页面立即刷新结果文本或数字。用户根据反馈继续调整记录。这种节奏对移动端很友好尤其适合碎片时间使用。1.3 为什么适合做成鸿蒙示例Failure Review Book 的代码足够短但包含了完整的应用骨架。有多个State字段。有用户输入。有按钮事件。有结果反馈。有基础布局设计。有可扩展的数据模型。这让它非常适合作为鸿蒙 ArkTS 入门之后的实战案例。二、工程结构与入口页面2.1 页面文件位置这个项目的核心逻辑位于入口页面Index.ets。entry/ src/ main/ ets/ pages/ Index.ets这个结构符合鸿蒙应用常见的页面组织方式入口页面承担状态声明、交互函数和 UI 构建三类职责。2.2 组件声明方式页面使用Entry与Component标记一个可渲染组件。EntryComponentstruct Index{build(){// 页面 UI 在这里声明}}Entry表示它可以作为页面入口Component表示它是一个 ArkUI 组件。2.3 单页工具的边界Failure Review Book 没有引入路由、网络请求或本地数据库所有数据都在当前页面状态中完成。这让示例的重点非常明确先把状态驱动 UI的基本功做好。当后续需要持久化、同步或分享时再把状态层抽离出去会更自然。三、状态模型设计3.1 状态字段总览失败复盘本 的状态字段如下。状态字段初始值页面职责eventNameMissed deadline失败或偏差事件reasonStarted too late原因归纳lessonCut scope earlier复盘输出actionSet midpoint review下一步行动reviews3累计复盘次数这些字段覆盖了页面最核心的信息用户正在编辑什么、系统已经生成什么、页面需要显示什么。3.2 状态设计的特点这组状态有三个特点。字段数量不多容易维护。字符串状态偏多适合表达记录类内容。数字状态用于计数、等级、进度或温度反馈直观。对于个人成长类工具这种状态结构比复杂对象更容易阅读。3.3 真实源码片段下面是项目中的核心状态与函数片段。StateeventName:stringMissed deadline;Statereason:stringStarted too late;Statelesson:stringCut scope earlier;Stateaction:stringSet midpoint review;Statereviews:number3;refine():void{this.reviews;this.lessonExperience: this.reason, next action: this.action;}这段代码体现了 ArkTS 页面里最常见的写法状态字段先声明事件函数再读取和修改状态。当状态变化后页面中引用这些状态的组件会自动刷新。四、交互流程分析4.1 主要交互点失败复盘本 的交互点并不复杂但每个按钮都对应一个明确的结果。交互点触发效果用户价值refinereviews 自增并把 reason 与 action 拼接成 lesson让页面从静态记录变成可反馈的工具TextInput onChange同步编辑事件、原因和行动让页面从静态记录变成可反馈的工具Extract Lesson触发复盘抽取让页面从静态记录变成可反馈的工具交互设计越简单越需要让反馈文字清楚。在这个项目里按钮点击之后通常会更新结果卡、计数字段或说明文本用户能立刻知道操作已经生效。4.2 输入框绑定页面通过TextInput的onChange回调同步输入值。TextInput({text:this.eventName,placeholder:失败或偏差事件}).onChange((v:string)this.eventNamev)这种写法适合表单很少的轻量页面。如果字段继续增加可以把输入区拆成独立组件或者把字段配置抽成数组来渲染。4.3 按钮反馈闭环一个好用的小工具至少要完成三件事。用户知道当前输入是什么。用户知道点击按钮后发生了什么。用户能从结果里继续下一步。Failure Review Book 的按钮逻辑围绕这三个点展开所以虽然代码短体验上仍然是完整的。五、布局结构拆解5.1 页面整体布局项目的页面结构可以概括为顶部四步流程条展示 Event、Cause、Lesson、Action正文使用输入框和白色结果卡承载复盘结论。这个布局没有堆叠过多装饰而是优先让主要状态可见。对于工具类应用这一点比复杂视觉更重要。5.2 关键 UI 片段下面是项目中最能代表页面结构的 UI 代码。Row({space:10}){Text(1 Event).layoutWeight(1).padding(12).backgroundColor(#FEE2E2).borderRadius(8)Text(2 Cause).layoutWeight(1).padding(12).backgroundColor(#FEF3C7).borderRadius(8)Text(3 Lesson).layoutWeight(1).padding(12).backgroundColor(#DCFCE7).borderRadius(8)Text(4 Action).layoutWeight(1).padding(12).backgroundColor(#DBEAFE).borderRadius(8)}可以看到页面通过颜色、留白、字号和权重区分主次信息。5.3 滚动容器的意义移动端屏幕高度有限记录类工具经常需要输入多个字段。Scroll可以保证在小屏设备上仍然能访问完整内容。Scroll(){Column({space:16}){Text(Failure Review Book).fontSize(30).fontWeight(FontWeight.Bold)// 输入区、按钮区、结果区}.padding(20).width(100%)}这种写法让内容区天然具备纵向扩展能力。六、视觉层级与颜色策略6.1 颜色不是装饰而是信息分组失败复盘本 使用的背景色是#F8FAFC强调色是#DBEAFE。这些颜色的作用不是单纯美化而是把功能区分开。区域视觉处理作用标题区大字号、粗体建立页面主题输入区白底或浅底降低编辑压力结果区卡片或强调色呈现操作反馈按钮区高对比色引导用户完成动作6.2 字号层级页面中的字号通常可以分成三层。26 到 58用于标题、数字或核心指标。18 到 24用于结果文本和重要卡片。15 到 16用于说明、日志和辅助状态。这种层级让用户扫一眼就能知道哪里最重要。6.3 圆角和留白项目里的卡片普遍使用borderRadius(8)和padding。Text(this.reviews).fontSize(15).fontColor(#374151)留白让文本更容易读圆角则让记录类工具更温和。七、ArkTS 状态更新细节7.1 字符串拼接的业务意义在 Failure Review Book 里很多结果不是复杂计算而是把用户输入重新组织成更有用的句子。这类字符串拼接看似简单但它是应用业务表达的核心。constresultCurrent: this.eventName / Status: this.reviews;当记录类工具能把零散输入变成结构化表达时用户就会感觉它真的在帮自己整理思路。7.2 数字状态的边界如果页面中存在数字变化就需要关注边界。例如温度、进度、次数、版本、等级等字段都应该避免出现负数或超过预期范围。constnextValueMath.min(100,currentValue10);constsafeValueMath.max(0,nextValue);即使当前项目只有少量数字字段提前形成边界意识也很重要。7.3 状态命名的可读性这些状态名都直接对应页面语义。命名方式示例可读性业务名词eventName直接表达用户输入结果名词reviews表达页面反馈数字名词count、progress、version表达可累计指标好的命名会让后续扩展更轻松。八、可扩展的数据模型8.1 从页面状态扩展为记录对象当前项目把字段直接写在页面状态里。如果要支持历史记录可以先定义一个接口。interfaceRecordItem{id:string;title:string;summary:string;createdAt:number;tag:string;}这个接口可以覆盖 失败复盘本 的基础记录需求。8.2 列表渲染结构当记录变多时可以使用数组状态和ForEach渲染列表。Staterecords:RecordItem[][];Column(){ForEach(this.records,(item:RecordItem){Text(item.title).fontSize(18).fontWeight(FontWeight.Medium)})}这样可以从单条记录平滑扩展到记录库。8.3 本地持久化方向当前示例没有写入本地存储。如果希望用户关闭应用后仍能看到记录可以把状态保存到首选项或数据库。interfacePersistedState{payload:string;updatedAt:number;version:number;}持久化时要注意版本号避免后续字段升级造成旧数据无法解析。九、用户体验优化点9.1 首屏要显示核心价值Failure Review Book 的首屏会尽快展示标题、关键数字或主要卡片。这对工具类应用很重要。用户打开页面时不应该先看到一堆说明文字而应该看到可以立刻操作的内容。9.2 按钮文案要短按钮文案越短动作越清楚。按钮类型文案特点适用场景主按钮动词明确保存、生成、发布、拆解次按钮辅助动作报告、回放、降温、切换模式按钮名词短语Interview、Social、Pitch短文案能降低用户在移动端的阅读负担。9.3 反馈文字要能复述动作结果区不要只写 “完成”。更好的反馈方式是复述用户刚刚完成的动作例如 “已保存某个关键词” 或 “已为某个目标更新进度”。this.reviewsUpdated from this.eventName;这样用户能确认系统理解了自己的输入。十、调试与验证10.1 先验证状态变化调试这类页面时可以优先检查状态是否变化。Button(Debug State).onClick((){console.info(state changed: this.eventName);})如果状态已经变化但 UI 没刷新通常需要检查组件是否引用了正确字段。10.2 再验证布局适配移动端页面要重点检查三种情况。输入内容很长。屏幕高度较小。按钮文案或结果文案换行。这些情况会暴露出滚动容器、卡片高度和文字对齐的问题。10.3 常见问题表场景风险处理方式文本输入为空失败复盘本 的关键记录缺失保留 placeholder并在结果区体现当前可用内容数值变化过快页面反馈不稳定使用上限、下限或自增规则限制状态卡片文字过长影响移动端阅读使用滚动容器和固定卡片留白主题色过重长时间使用疲劳背景色与强调色分层正文保持清爽这个表中的问题都可以在开发阶段通过真机预览或模拟器预览提前发现。十一、工程化改造思路11.1 抽离常量当页面颜色和间距逐渐变多时可以抽离常量。constPAGE_PADDING20;constCARD_RADIUS8;constPRIMARY_COLOR#DBEAFE;这样既方便统一视觉也方便后续换主题。11.2 抽离动作函数当前函数写在页面组件内部适合小项目。如果业务逻辑变复杂可以把动作函数移到独立工具文件。exportfunctionbuildSummary(input:string,status:string):string{returninput - status;}页面组件只负责调用函数和展示结果逻辑测试会更容易。11.3 抽离卡片组件重复出现的卡片可以封装成 Builder。BuilderfunctionInfoCard(title:string,value:string,color:string){Column({space:6}){Text(title).fontSize(14).fontColor(#6B7280)Text(value).fontSize(18).fontWeight(FontWeight.Bold)}.padding(14).backgroundColor(color).borderRadius(8)}这样可以减少页面重复代码。十二、与同类工具的设计对比12.1 功能边界对比类型功能重点复杂度适合阶段失败复盘本把事件、原因、经验和行动串成闭环的复盘工具低MVP 和个人工具多页面系统分类、检索、统计中数据量增大后云同步产品账号、同步、分享高商业化阶段从这个对比可以看出当前项目选择了非常适合练手的边界。12.2 为什么先做小闭环小闭环能让开发者更快验证交互是否成立。对于 失败复盘本 来说只要用户能完成一次记录、一次点击、一次反馈应用价值就已经出现。12.3 后续增长空间后续可以扩展这些能力。历史列表。标签筛选。搜索。统计图。桌面卡片。多设备同步。但这些能力都应该建立在当前清晰的状态模型之上。十三、构建与运行流程13.1 使用 DevEco Studio 打开工程开发者可以使用 DevEco Studio 打开项目根目录。# 使用 DevEco Studio 打开项目后等待依赖同步完成# 然后选择模拟器或真机运行 entry 模块运行前需要确认 SDK、签名和设备连接状态正常。13.2 检查模块配置鸿蒙工程通常包含模块配置文件。{module:{name:entry,type:entry,srcEntry:./ets/Application/EntryAbility.ets}}具体字段以工程实际文件为准本文重点是页面开发思路。13.3 预览页面变化调试 UI 时可以把修改拆成小步骤。# 1. 修改状态字段# 2. 修改 UI 绑定# 3. 运行预览# 4. 点击按钮确认反馈这种节奏能快速定位问题。十四、代码可维护性分析14.1 当前代码优点Failure Review Book 当前实现有几个明显优点。业务目标单一。状态字段语义清楚。按钮动作直接。页面布局不绕。适合继续扩展。这些优点让项目非常适合作为 ArkTS 小应用案例。14.2 可能变复杂的地方随着功能增加复杂度通常来自三处。记录数量增加。页面交互增加。结果生成规则增加。提前识别这些变化可以避免页面文件过早膨胀。14.3 分层后的目录示例entry/src/main/ets/ pages/ Index.ets model/ RecordItem.ets utils/ summaryBuilder.ets components/ InfoCard.ets这个目录结构适合从单页工具扩展到更完整的应用。十五、发布级文章视角下的技术亮点15.1 状态与业务强绑定失败复盘本 的每个状态字段都能在页面上找到对应含义。这让读者可以直接从代码理解产品设计。15.2 交互路径短从输入到按钮再到结果路径非常短。这种设计适合个人效率和成长工具因为用户不会愿意在记录前完成复杂配置。15.3 可扩展但不臃肿当前项目没有为了未来需求提前堆叠复杂框架。它把重点放在一个可运行、可理解、可继续扩展的页面上。对初学者来说能把一个小工具做完整比把很多概念写在同一个项目里更有价值。十六、总结Failure Review Book 用非常直接的 ArkTS 代码完成了失败复盘本的核心体验用户输入信息按钮触发动作页面立刻给出反馈。从技术角度看它覆盖了State、TextInput、Button、布局容器、文本展示和基础视觉层级是一个适合反复拆解的鸿蒙单页应用案例。从产品角度看它把 项目延期、错过截止时间或决策失误后的经验沉淀 这个具体场景压缩成一个轻量工具让用户能在短时间内完成记录和反馈。如果把它继续扩展可以加入历史记录、本地存储、标签筛选和统计图但当前版本已经具备完整的最小可用闭环。相关资源HarmonyOS 应用开发文档ArkTS 语言基础ArkUI 声明式开发范式组件参考状态管理应用工程结构性能调优DevEco Studiormonyos-guides/arkts-get-started)ArkUI 声明式开发范式