登录社区云,与社区用户共同成长
邀请您加入社区
这篇只拆一个具体点:鸿蒙电脑窗口边界恢复。版本边界先放前面:下面的写法面向 HarmonyOS 7.0 / API 26。工程里如果还在混用旧 SDK、旧模拟器镜像或旧设备系统,先不要直接照搬代码,先把版本对齐。
ArkUILab 里存在两个「世界观」:页面世界有完整的主题系统——ThemeEngine 管品牌与明暗、AppStorage 做全局状态、$r('sys.color.*') 系统令牌自动跟随深色模式,《Theme Foundation》和《Brand Theme Engine》两篇已经把它讲透了。组件世界(GrokBot、ThinkingOrbs、BorderBeam、FlowAvatar、Me
这是 ArkUILab「横切总结」系列的第四篇,讲一个很少被写进教程、却决定自定义动效组件成败的环节:验收。一个翻书组件「代码写完」和「真机上满意」之间,隔着几十轮「感觉不对→改一个数→再跑」。没有方法的话,这个过程是这样的:改完靠感觉描述(「好像卡了」「翻得有点假」),复现靠运气,结论靠记忆。E017 Coverflow 的真机笔记里有一句话浓缩了全部风险:
这是 ArkUILab「横切总结」系列的第三篇。前两篇讲组件的内部与外交,这一篇回答一个每个动效组件动手前都要面对的问题:在 ArkUI 上让一个东西动起来,至少有四条通道:animateTo 隐式属性动画、createAnimator 显式进度、DisplaySync 帧时钟、setInterval 定时器。选哪条?
这是 ArkUILab「横切总结」系列的第二篇。第一篇《自定义 Canvas 动效的分层范式》讲的是组件内部怎么分层(Core / Models / Painter / Component);
Web 上有一类很出效果的「3D 手风琴书架」:一排书立在架子上,点一本,封面从书脊上旋出来面向你,邻书向两边避让——全靠 CSS transform: rotateY + perspective 实现。想在鸿蒙上复现它,直觉路线有三条:套 WebView(重)、预制图片序列(假)、上 WebGL/XComponent(杀鸡用牛刀)。
「翻书」是阅读类应用最经典的动效之一。它看起来简单,实际上是一条完整的图形学链路:把一页纸在 3D 空间里弯起来,再投影到 2D 屏幕。很多鸿蒙实现会退而求其次,用两个半页做 rotate 假立体——纸是硬的、没有卷曲、背面镜像还经常出错。
这篇只抓一个点:鸿蒙电脑快捷键作用域。我不按概念顺序铺开,而是按项目里最容易出问题的路径来拆:先复现坏写法,再补上边界判断,最后用日志和状态验证结果。
这篇只讲一个点:鸿蒙电脑快捷键。我不按官方说明书那种顺序铺概念,而是按开发时最容易出事的路径来拆:什么时候会坏、怎么复现、怎么修、怎么验证,以及这个判断以后能不能复用。
这篇只拆一个 HarmonyOS 7.0 / API 26 相关点:鸿蒙电脑桌面窗口适配。我不会把它写成“新能力清单”,因为清单看完很快就忘。更有价值的是把一个具体问题讲透:它怎么出现、怎么复现、怎么兜底、代码里怎么封装,最后怎么验证。
写了十来个鸿蒙自定义动效组件之后(GrokBot、ThinkingOrbs、FlowAvatar、Coverflow、GradientSpin、BorderBeam、MetalFx……),回头一看,它们虽然长得完全不一样——有的是表情头像、有的是状态球、有的是 3D 轮播、有的是边框流光——但内部结构惊人地一致:都拆成了 Core / Models / Painter / Component 四层
本文基于 ArkUILab 项目 E017「Coverflow Carousel(路线 B)」 实验,完整记录从 Flutter coverflow_carousel 移植到 ArkUI 的过程,重点讲七个 ArkUI 特有的坑:「数值对、UI 不动」的渲染绑定陷阱(ForEach key 稳定 ≠ transform 会重绑)、Controller 禁止 @Prop(深拷贝导致 attach 失
很多产品用「首字母 + 随机色块」当默认头像,但不同用户可能撞色、且没有「这个头像就是这个人」的确定性。flow_avatar(Flutter)给出了一套更优雅的方案:用一个字符串 seed(如邮箱、用户名)生成一个稳定、可复现、会流动的渐变头像——同一个 seed 永远得到同一个身份,换 baseColor 只改变配色、不改变形状。
本文基于 ArkUILab 项目 E023「Border Beam 边框光束」 实验,诚实记录一次**「效果确实还原出来了,但真机非常卡」的完整工程过程**。这不是一篇「成功教程」,而是一篇踩坑预警:讲清楚 Web 那一套 mask-composite/@property/filter: blur 在 ArkUI 里为什么失效、Canvas 的手工等价手段(destination-out 掏孔、c
本文是 GrokBot 系列第二篇,聚焦渲染层,覆盖六大干货:viewBox 到 Canvas 的坐标映射(DPR 无关的统一缩放)、躯干圆角的 CSS border-radius 语法解析(含椭圆角与比例 clamp)、球面投影 grokBotProjectEye(经度/深度/透视的全过程)、弹簧 GrokBotSpring(半隐式欧拉 + 固定步长子步进)、blink / spin 的缓动节奏
本文是 GrokBot 系列的第一篇,重点讲架构与数据层:为什么要拆成「组件 / 核心 / 绘制 / 模型 / 数据」五层、25×2×48 眼睛点数据是怎么来的、表情与状态如何解耦、@Prop + @Watch 如何驱动数据流、以及 GrokBotController 的「一比一控制」设计约束。文中代码均通过 HAP 构建验证,可直接作为鸿蒙数字人 / 表情头像组件的架构参考基线。
在 HarmonyOS ArkUI 的组件化开发体系中,插槽(Slot)机制是实现高复用、低耦合自定义组件的核心能力。本文从状态管理服务层的视角出发,深入剖析装饰器的技术原理,系统讲解单插槽、多插槽、参数化插槽及条件插槽的实现方式,并结合AppStorage等状态管理工具,构建一套完整的状态驱动型动态插槽组件系统。通过实战案例与性能优化策略,帮助开发者掌握在企业级鸿蒙应用中灵活运用插槽机制的关键技
多设备场景里,页面状态不能只放在当前组件里。设备切换后,当前页、筛选条件、未完成任务都要能恢复。 这类问题如果只看官方接口说明,通常只能知道“能力能不能用”;真放到工程里,还要继续回答:什么情况下会坏、怎么复现、失败以后页面怎么恢复、日志能不能解释、后面能不能复用。
在鸿蒙应用开发中,时间选择是闹钟设置、会议预约、倒计时管理、排班系统等场景的核心交互能力。HarmonyOS ArkUI 提供了原生的TimePicker与组件,能够满足基础的时间选择需求。代码冗余:每个页面都需要重复编写时间格式化、范围校验、12/24小时制切换等逻辑;样式割裂:不同页面的时间选择器外观不一致,难以维护统一的设计规范;功能缺失:原生组件不支持自定义时间格式、秒级选择、时间段范围校
在鸿蒙应用开发中,日期选择是表单交互、日程管理、预约系统等场景的核心能力。HarmonyOS ArkUI 提供了原生的DatePicker与组件,能够满足基础的日期选择需求。代码冗余:每个页面都需要重复编写日期格式化、范围校验、回调处理等逻辑;样式割裂:不同页面的日期选择器外观不一致,难以维护统一的设计规范;功能缺失:原生组件不支持农历显示、自定义主题、防抖回调等高级需求;状态混乱:日期状态分散在
多设备适配的关键不是“放大”,而是“重排”。手机、平板、鸿蒙电脑要有不同的信息组织方式,断点要能随着窗口变化重新计算。
本文系统介绍了鸿蒙应用开发中本地文件管理的核心操作,重点解析了同步与异步接口的选择策略,并通过三个典型场景的代码实战演示了文件读写的最佳实践: 核心接口全景图:对比分析了同步与异步文件操作的适用场景,强调耗时I/O操作必须使用异步接口避免阻塞主线程。 沙箱路径获取:演示了如何正确获取应用私有目录路径,确保多设备兼容性。 基础文件读写:通过新建配置文件案例,详细说明文件打开模式选择、缓冲区转换和资源
本文深入解析了鸿蒙ArkUI框架中openCustomDialog接口的核心使用方法。通过对比传统CustomDialogController方案,文章重点阐述了openCustomDialog在解耦设计、动态更新、动画控制等方面的优势,并提供了完整的工具类封装方案。主要内容包括: 架构设计:将弹窗管理封装为独立工具类PromptActionClassNew,实现与页面逻辑的彻底解耦,支持静态属性
做过设置页面的都知道,用户改了配置项之后,退出页面再进来,状态应该还保留着。在 Web 开发里我们用,在 Android 里用。鸿蒙 ArkUI 提供了一个更优雅的方案——,直接把变量和全局的AppStorage绑定在一起,而且是双向的。这篇文章用一个"用户信息 + 积分 + 主题"的案例,把的实际用法讲清楚。的默认值只在AppStorage中没有对应 key 的时候才生效。如果之前已经写入过值,
在鸿蒙上接语音识别,API 调用本身只有几行,难的是长会话稳定性:VAD 约 60 秒截断后怎么无感续接、多轮 kit 会话的回调怎么不串台、错误怎么分级重试。本篇讲一套生产级 ASR 适配层:唯一系统边界文件、双重 sessionId、三重校验的回调隔离、退避重试预算——全部来自真机验证过的实现。
这篇文章总结了鸿蒙应用开发中固定样式弹出框的核心使用方法和注意事项。主要内容包括: 固定样式弹出框的特点:布局由系统固定,开发者只需关注内容,提供高效、规范的弹窗解决方案。 弹出框类型全景图:详细介绍了8种固定样式弹窗的调用方式、核心用途和模态特性。 调用路径的两种方式:通过PromptAction对象或UIContext对象调用,不同弹窗需采用不同路径。 异步回调中的正确调用方法:提前捕获UIC
系列开篇。以一个真实上架应用(AI 口语教练"开口练")为样板,讲清鸿蒙工程的三个核心配置文件、SDK 基线怎么选、目录怎么分层,以及如何用命令行干净地打出签名 HAP。读完你能从零搭出一个"第一天就朝着上架去"的工程骨架,而不是一个迟早要推倒重来的 Demo。
本文介绍了HarmonyOS ArkUI动画系统的核心概念与实现方式。主要内容包括: 动画设计价值:通过渐变过渡提升用户体验,保持界面连续性、提供操作反馈,但需避免过度设计。 动画体系分类: 属性动画:通过.animation()修饰器(声明式)或animateTo()函数(命令式)实现组件属性过渡 关键帧动画:通过keyframeAnimateTo定义复杂运动路径 实现对比: 声明式动画适合简单
在开发电商首页、购物车、列表卡片等复杂页面时,页面中存在大量重复的样式、重复的UI结构、统一的交互逻辑。如果全部手写,会出现代码冗余、样式不统一、后期维护成本极高的问题。样式复用、UI结构复用、自定义组件复用,配合父子组件数据通信机制,能够实现高内聚、低耦合的前端开发模式,也是企业级鸿蒙项目模块化开发的基础。单纯的结构复用只能解决代码冗余问题,想要实现数据驱动UI更新,必须依靠组件状态通信机制。
鸿蒙的多媒体能力覆盖图片、相机、音视频全链路。Image 负责展示与处理(圆角/模糊/裁剪),photoAccessHelper 负责选图与存库,CameraKit 负责相机采集,MediaKit 的 AVPlayer/AVRecorder 负责播放与录制。权限先声明再申请、媒体对象按状态机流转、资源用完 release。掌握这些,你能做出带图、带声、带影像的富媒体应用。
传统移动操作系统围绕"单设备"设计,而鸿蒙的核心主张是分布式软总线——把手机、平板、手表、智慧屏、车机等设备虚拟成一个"超级终端",应用可以跨设备调用硬件能力、迁移状态、协同计算。对开发者而言,这意味着一次开发,多端部署(一多)。ArkTS 是鸿蒙上的应用开发语言,它在 TypeScript 的基础上做了强化与约束保持 TypeScript 的类型系统,但开启更严格的类型检查(禁用any、强制类型
文中的成绩单是示意材料,不能作为正式成绩证明。评价项权重得分需求与选题2017技术实现3026团队协作2015测试与文档1511展示与答辩1513总评10082痛点真实;核心闭环完整;弱网处理有思考;团队分工后期失衡;测试介入太晚;性能证据不足;复盘比较诚实。选题被否定;范围被收缩;接口发生变化;代码被评审;弱网暴露问题;团队任务失衡;测试发现缺陷;答辩被追问;项目留下遗憾。
HarmonyOS 应用开发者高级认证的价值,不只是增加一行证书经历,而是迫使开发者把碎片化知识整理成完整能力结构。以官方大纲为基线;以官方课程和文档为主要资料;以 ArkTS 编程保持基础手感;以项目验证架构和性能;以错题本减少重复错误;以模考训练时间;以合规方式参加考试;通过后继续积累工程经验。不要相信“背一套题就能掌握高级开发”,也不要因为大纲范围广就焦虑。把知识拆成模块,把模块放进项目,把
鸿蒙 + AI:手写公式识别与错题本应用”是一个非常适合毕业设计的题目,因为它把算法能力、端侧部署、UI 体验和学习场景结合在了一起。它的真正价值不在于“识别出一个积分符号”,而在于把复杂的手写公式录入问题,转化为一个可持续复习、可分析掌握度、可辅助提分的学习闭环。在 HarmonyOS 生态中,这类项目尤其适合用平板和手机双端完成:平板负责手写录入与识别,手机负责轻量复习与错题回顾。
这篇毕业设计的核心价值不是“做一个校园地图”,而是把 HarmonyOS 的系统能力与校园真实场景结合起来:通过 ArkUI 构建双端体验,通过 Intents Kit 实现服务直达,通过元服务降低入口门槛,通过分布式能力实现跨设备接续,通过离线缓存和无障碍路线提升实际可用性。从校企合作教学角度看,这个项目非常适合作为毕业设计:它有清晰的用户痛点,有可展示的界面,有可讲解的架构,有算法和数据模型,
AI Agent 应用的安全风险比普通应用高一个量级——因为它手里有 API Key(直接关联费用和账号安全)、能执行工具(可能产生不可逆副作用)、处理用户隐私数据(对话内容、图片、文档)。如果 API Key 泄漏到 HAP 包里,任何人解包就能提取。如果错误信息打印了 Authorization Header,日志收集就能看到。如果工具没有权限控制,Agent 可能被诱导执行危险操作。本文基于
纯文本对话只是 AI Agent 的起点——用户可能想拍照让 Agent 分析、想上传 PDF 让 Agent 总结。但在鸿蒙上做多模态输入,远不止"把图片转成 base64 发给模型"那么简单。智谱的视觉模型接受 image_url,DeepSeek 根本不支持图片;智谱的文档用 file_url,DeepSeek 只接受宿主提取的文本。如果你不做 pre-call 校验就把不支持的格式发给 P
# 鸿蒙原生开发手记:徒步迹 - @Provide/@Consume 跨组件通信> 掌握跨级组件通信,构建灵活可复用的组件体系---## 一、前言在复杂应用中,经常出现祖先组件需要向后...
系统讲解一套生产级评估体系是怎么运转的。文章覆盖七大主题:EvalEnvironment 生命周期(prepare/dispose SPI、每个 trial 独立 workspace/clock/controller/lease)、Record/Replay 机制(录制真实 LLM 交互、回放时 HTTP 请求严格为 0)、SHA-256 请求哈希(canonical JSON + trial s
文章覆盖六大主题:Hook SPI 的九个槽位(每个槽位的入参、出参、四种/三种 action 的语义)、串行短路 Pipeline(为什么必须按注册顺序串行、改写如何传递、第一个短路为什么立即生效、工具改写为什么必须保 id)、AgentController 的"零状态"设计(为什么控制面不持有 Runtime 状态、ApprovalHost 桥接怎么走、approve/deny 为什么幂等)、
系统讲解 Agent 的技能与规划子系统是怎么运转的。文章覆盖六大主题:对象技能模型(Skill 的 private 构造器 + static 工厂、SkillToolBinding、ReservedToolNames 保留名、forceActivate 强制激活与 sanitizeActiveSkills 清洗)、目录技能与 SKILL.md 发现(SkillDirectoryAccess SP
,系统讲解 HAR(HarmonyOS Archive)的打包与分发。文章以 @arkagent/core 和 @arkagent/eval 两个真实 HAR 为例,覆盖七大主题:HAR 与 HAP 的本质区别与依赖方向、三模块分离铁律(core/eval/entry 的有向无环图)、assembleHar 命令行构建与 --no-daemon 的真正原因、HAR 产物的内部结构(modules.
文章覆盖六大主题:工具契约设计(为什么用对象参数而非反射、ToolContext 为什么显式传入、五字段签名)、ToolRegistry 注册与执行(三步注册校验、执行时四道关卡、工具错误的结构化回填)、Schema 校验器(白名单关键字策略、为什么不支持的关键字必须报错、两层校验)、风险分级与审批流(三档风险等级、整 batch 冻结、PendingApproval 可持久化审批)、Hook 干
文章覆盖六大主题:ArkTS 类型系统的五条约束(为什么递归类型别名、索引签名、对象字面量、throw 任意类型、any 全部被禁)、JsonValue class + JsonKind + JsonObject(Map) 三件套设计(私有构造器 + 静态工厂 + asXxx 访问器)、手写递归下降 Parser(为什么不依赖 JSON.parse 的动态结果、怎么逐字符解析并报错定位)、解码四规
文章覆盖六大主题:流式输出的三层挑战(协议/编码/语义)、Transport SPI 与鸿蒙 HTTP 的桥接(dataReceive/dataEnd/取消)、SseParser 逐行解帧(LF/CRLF/多行 data/注释/[DONE])、IncrementalUtf8Decoder 的残字节保留(跨 chunk 多字节字符)、StreamAssembler 的字节→事件管道(8 种事件 +
文章以"烘焙助手"为完整案例:用户说"帮我查烘焙记录并计算失重率",Agent 先调 read_baking_records 工具读取三条记录,再调 calculate_weight_loss 工具计算失重率,最后用中文给出结论。文章覆盖六大主题:环境准备与 HAR 接入(构建 HAR、声明本地依赖、INTERNET 权限)、Provider 与 LLMClient 组装(智谱/DeepSeek
文章覆盖七大干货:List Pattern 决策模型(Setting / Management / Card / Content Browser 怎么选)、ListCell 解剖结构(prefix / title / subtitle / suffix 的官方心智)、三大模式实战(SettingSection、CardSection、SwipeActionRow)、官方 HDS 原生路径(HdsL
文章覆盖七大干货:滚字的正确心智模型(每字素一槽,不是整段 Text 动画)、字素分割与 MeasureUtils 测宽(emoji / ZWJ / 组合字符怎么处理)、共享时间轴 + 确定性 timing(比每字多个 timer 更适合 ArkUI)、Controller 的 set / flash / finish(声明式与命令式双入口)、动态节点 identity(为什么会 12 → 21、