登录社区云,与社区用户共同成长
邀请您加入社区
文章摘要 本文探讨了AI Native时代下UI框架状态管理的范式转变。传统组件(Component)与状态(State)绑定的设计在AI持续运行场景中面临挑战:当任务跨页面、跨设备执行时,组件销毁会导致状态丢失。作者提出状态应归属于运行时(Runtime),而非组件,并通过HarmonyOS案例说明无状态组件如何更好地配合Goal/Task/Context等长期运行实体。未来架构可能形成"Run
摘要: 本文探讨了AI应用中**Context Cache(上下文缓存)**的关键作用。传统AI系统每次请求都需重新构建完整上下文,导致响应慢、Token消耗高。作者指出,应缓存运行时上下文(如当前任务、工作区状态等),而非仅Prompt文本,以实现增量更新而非全量重建。Context Cache作为AI运行时的“工作记忆”,能显著提升推理效率与准确性。HarmonyOS PC凭借对工作区、任务等
本文探讨了AI应用开发中常被忽视的关键要素——Context(上下文)的重要性。作者展菲指出,当前AI应用开发过度关注模型参数、推理能力等指标,而忽视了Context Engine的核心作用。文章通过七个方面分析:1)Context将成为AI Runtime的核心管理对象;2)聊天记录不等同于运行时上下文;3)Context Engine实质是运行时状态数据库;4)Context比Memory更能
摘要: 随着AI原生时代的到来,传统以"Process"为核心的OS架构面临变革。展菲(技术博主/图书作者)提出,用户关注的不再是具体应用(如微信或Chrome),而是目标(Goal)的完成(如"开发审批流"或"修复Bug")。当前系统以进程(Process)和线程(Thread)为调度单元,而未来将转向Goal Native Runtime,通过上下文引擎(Context Engine)、任务规
摘要 技术专家展菲提出,随着AI Native时代的到来,传统以线程(Thread)为核心的软件执行模型面临变革。在AI工作流(Workflow)、长任务(Long Task)等场景下,用户真正关心的执行单元已从线程转向任务(Task)。文章分析了Thread模型的局限性,指出其无法有效描述任务间的复杂依赖关系,而Task更适合作为跨应用、跨设备的执行对象。作者预测未来系统将形成"双执行系统"架构
摘要:本文介绍了如何在HarmonyOS上从零构建轻量级游戏引擎。作者展菲作为资深开发者,提出传统UI框架无法满足复杂游戏需求,需要基于ECS架构(实体-组件-系统)设计独立游戏Runtime。核心模块包括World(游戏宇宙)、Entity(实体容器)、Component(数据载体)、System(逻辑处理)、Scene(场景管理)等,通过主循环驱动各系统协同工作。相比直接使用页面驱动,该方案具
本文探讨了传统状态管理模型在AI时代面临的边界问题。作者指出,过去二十年软件开发默认"状态属于页面"的前提正在被颠覆,随着多窗口、Workspace、Agent、长任务等场景的普及,真正持续存在的对象已从Page转变为Task/Context/Workspace。传统以页面生命周期管理状态的方式导致状态生命周期过短,无法满足AI时代"目标驱动"的软件需求。文章提出未来状态管理将向Workspace
游戏引擎的未来:从渲染优先到运行时优先 随着AI技术发展,游戏引擎的核心正从传统渲染技术转向以Runtime(运行时)为中心的架构。过去引擎围绕Scene(场景)构建,关注GPU渲染效率;而AI驱动的NPC具备记忆、目标和社会关系,要求世界持续运行而非随玩家进出启停。鸿蒙等分布式系统更需World Runtime统一管理跨设备状态,推动架构演变为:System Runtime(调度Agent/任务
本文探讨了鸿蒙游戏开发中动画系统的设计思路。作者展菲通过分析常见开发误区,指出动画系统应与业务逻辑解耦,提出"状态驱动动画"的架构模式。文章详细讲解了动画状态机、事件系统、特效系统拆分、UI动画管理等核心概念,并给出性能优化建议。适合游戏开发者学习如何构建可扩展的动画系统架构,解决大型项目中动画管理混乱的问题。
本文由展菲分享鸿蒙App模块化架构设计经验。文章指出随着业务增长,缺乏模块化会导致项目依赖混乱、维护困难。作者强调模块化核心是解决边界问题,推荐按业务领域而非技术层拆分(如user/order/payment等独立模块)。针对鸿蒙分布式特性,提出模块内部应包含UI/Store/Task/System/Repository分层设计,模块间通过接口通信避免循环依赖。特别指出Store不应跨模块共享,并
Store 是应用唯一可信的状态中心。数据不一致共享同一份状态UI↓Store↓System↓RepositoryStore 不是状态容器,而是整个应用的数据秩序。页面太多功能太复杂AI 太难接入状态没有唯一来源。UI负责展示Store负责状态System负责处理Repository负责数据统一Store领域Store唯一写入口Task驱动无状态System项目开始变得可预测而这也是中大型鸿蒙 A
摘要: 本文探讨了鸿蒙开发中状态管理的核心问题——统一状态源(Single Source of Truth)的重要性。作者展菲(技术博主/图书作者)指出,随着项目复杂度提升,多状态源会导致数据不一致、同步困难等问题,尤其在鸿蒙多设备分布式场景下更易放大。文章提出通过分层架构(Store作为唯一状态源)确保数据一致性,并对比错误设计(如状态分散在多个页面或System中)与正确实践(集中管理+职责分
t ↓ 拆分System ↓ 分帧执行 ↓ 减少刷新范围 ↓ 避免GC ↓ 减少布局计算 最终目标: ```text 消灭慢帧 记住: 60FPS 不是目标,流畅体验才是目标。 <font color=#0A8BFF size=2><b>本文作者:展菲</font><font color=black size=2><b> 华为HDE、鸿蒙技术布道师</b> <font color=#0A8BFF
《鸿蒙游戏多端一致性开发实战》摘要:本文由资深开发者展菲分享鸿蒙游戏开发中多端一致性的核心解决方案。文章指出,真正的多端互通不仅是数据同步,关键在于确保所有设备遵循同一套System规则演化出相同的游戏世界状态。通过分析状态漂移问题,提出"Store+System"架构模式,强调同步输入而非结果,采用确定性模拟实现跨设备状态一致。方案包含客户端预测、服务端校正、状态快照同步等技术,特别适合鸿蒙原生
本文由资深开发者展菲分享鸿蒙游戏性能优化实战经验。文章指出游戏卡顿的核心并非CPU性能不足,而是帧时间(Frame Time)不稳定导致的体验波动。作者系统性地提出了5大优化方案:1)状态批量更新减少重绘;2)Store拆分实现局部刷新;3)对象复用避免GC卡顿;4)UI组件化降低渲染范围;5)System分层与分帧执行均衡计算负载。特别强调通过System-Store-HUD分层架构实现逻辑与渲
摘要 本文深入解析鸿蒙PC多屏协同的技术本质,指出其核心在于设备间状态共享而非简单的屏幕投屏。作者展菲(人工智能专家/技术博主)通过对比传统投屏方案,详细阐述了鸿蒙分布式系统的实现架构: 技术本质:传输Ability Context(应用运行上下文)而非画面 核心架构:包含设备发现、认证、状态同步等分布式系统功能 关键技术:分布式KVStore实现状态同步,Workspace概念统一工作环境 未来
鸿蒙 App 集成 AI 助手,不是在页面里放一个聊天框,而是在应用内部增加一个新的 Runtime。用户操作功能用户表达意图页面驱动业务Assistant 驱动业务App= UI+ State+ Task+ Tool很多开发者接入 AI 后,看到模型能够回复内容,就觉得已经完成了 AI 化。让 AI 会聊天让 AI 会做事聊天框只是入口,Assistant Runtime 才是核心。分布式 As
摘要: 鸿蒙系统通过分布式文件运行时(Distributed File Runtime)重构了文件共享体验,其核心在于将文件从设备归属转变为分布式状态空间的共享资源。传统文件共享基于设备间复制(如微信、AirDrop),导致版本混乱、存储冗余和同步延迟;而鸿蒙通过SoftBus统一调度连接,实现跨设备资源映射,用户可无缝拖拽文件,系统自动完成设备发现、数据流传输和状态同步。未来,鸿蒙将进一步从“文
本文由华为鸿蒙开发者展菲撰写,深入解析了ArkUI状态管理的核心机制与实践要点。文章首先指出新手常见的变量更新误区,强调鸿蒙采用"状态驱动UI"的设计理念。通过分析@State的工作原理,揭示了状态变更触发的自动刷新机制。针对项目规模扩大后的状态管理挑战,提出分层架构方案(LocalState/PageState/GlobalState/DistributedState),并展示了UserStor
本文深入探讨了鸿蒙游戏中手势系统的本质与架构设计。作者指出,手势并非简单的UI功能,而是输入事件(Input Event),应作为游戏状态的触发器而非直接驱动业务逻辑。针对常见架构失控问题,提出应建立独立的InputSystem作为中间层,统一转换各类输入(点击、拖拽、摇杆等)为标准化InputAction(如ATTACK、MOVE),再由专门System处理。特别强调持续输入(如拖拽/摇杆)需通
只重新构建“发生变化”的部分。增量构建,本质上是在“控制依赖扩散”。代码太多所有东西都互相依赖一个 App像一团代码一个 App像多个独立运行的小系统增量构建才真正成立ArkUI 太复杂AI 太重分布式太难架构没有“构建边界”。真正优秀的鸿蒙工程,一定是:代码可拆分,依赖可隔离,构建可增量。Feature 化Store 分层Task 解耦Runtime 稳定化单向依赖无状态 System整个鸿蒙项
本文探讨了传统前端开发思维在鸿蒙PC开发中的局限性。作者指出,鸿蒙PC已从"页面驱动系统"转向"Runtime系统",传统前端以页面生命周期、Router和组件状态为核心的模式在多窗口协作、AI集成和分布式同步等场景下会面临状态失控等问题。文章分析了Web前端与鸿蒙PC在架构理念上的本质差异,强调鸿蒙PC需要建立以Runtime状态管理、Task系统和Workspace持续上下文为核心的新开发范式
《鸿蒙App架构演进:从页面驱动到状态驱动的必然趋势》 本文探讨了鸿蒙应用开发中架构设计的关键转变。传统以页面为核心的开发模式会导致业务逻辑堆积、耦合严重,随着AI、分布式等能力的加入,页面复杂度将指数级增长。作者指出未来鸿蒙应用的核心将转向状态管理(Store)和任务调度(Task Runtime),页面角色将简化为"状态展示层"。这种架构演进表现为三个显著特征:1)业务逻辑从页面下沉至Stor
展菲是一位资深技术专家,专注于多领域开发与前沿技术分享。文章聚焦鸿蒙多端开发的常见误区,指出"跨端运行≠跨端体验"的核心问题。作者剖析了七大典型错误:简单UI适配、状态共享混乱、TV焦点忽视、固定布局、页面驱动设计、AI状态失控及非响应式组件,并强调优秀架构应实现"能力统一、状态隔离、UI自适应"的三层结构。文章为开发者提供了鸿蒙多端开发的实践指南,强调需根据不同设备特性重构交互模型,而非简单适配
本文探讨了鸿蒙PC跨设备拖拽功能的本质与实现架构。作者指出,传统拖拽模型(基于文件传输)在鸿蒙生态中存在局限性,无法满足AI Task、Workspace等复杂场景需求。文章揭示了鸿蒙跨设备拖拽的核心是传递"Task Context"而非单纯数据,详细阐述了包含状态快照、分布式运行时等关键组件的完整架构。通过五个关键点:拖拽上下文而非文件、Workspace恢复机制、Focus本地化、引用传递原则
摘要 本文深入探讨了HarmonyOS分布式能力的核心本质,指出传统"数据同步"思维的局限性。作者通过实战经验总结出分布式开发的六大关键能力: 分布式状态层的分层设计(LocalState/DistributedState/ProjectionState) 设备平等化的Runtime节点理念 以Task而非页面作为同步核心 Focus状态的设备本地化原则 Layout投影化的多设备适配方案 AI
摘要 本文深入分析了鸿蒙PC应用启动性能优化的关键策略。作者指出,与传统移动应用不同,鸿蒙PC启动的核心不是页面初始化,而是整个状态系统的恢复,包括Workspace、Focus、Task等多个运行时环境。文章揭示了常见误区,如将所有初始化操作集中在启动阶段,导致主线程阻塞。提出了八大优化方案:Workspace延迟恢复、Store分级初始化、AI Runtime后置、首页状态精简、启动快照构建、
摘要 本文探讨了鸿蒙PC开发中的性能优化策略。作者指出,鸿蒙PC的性能问题本质上是"状态流问题",而非简单的UI渲染问题。文章分析了传统App与鸿蒙PC在状态管理上的差异,并揭示了"状态扩散"是导致性能下降的主要原因。作者分享了10个关键优化方案,包括状态分层、Workspace隔离、Focus独立运行、build逻辑简化、Task异步化、状态原子化、列表虚拟化、动画去状态化、AI状态限流和分布式