- 博客(1485)
- 资源 (3)
- 问答 (1)
- 收藏
- 关注
RSS订阅原创 HarmonyOS 游戏架构升级：从 Store 到 Runtime
本文探讨了HarmonyOS游戏开发中架构设计的演进过程。作者展菲（企业级AI项目研发管理者、技术图书作者）指出，开发者通常会经历三个阶段：从依赖ArkUI组件，到转向状态管理（Store），最终升级为运行时（Runtime）架构。文章通过对比分析，阐释了Store模式的局限性——它虽能管理状态，却无法处理游戏逻辑的复杂性，容易演变为"上帝对象"。 随着游戏系统（Physics、AI、Animation等）增多，Runtime层成为必要架构，它作为核心调度器统一管理系统执行顺序和频率，形成"Runtime→
2026-06-29 15:30:38
317
6
原创 鸿蒙游戏 System Runtime：AI 时代的新引擎内核
本文探讨了HarmonyOS游戏开发中引入Runtime系统的重要性。作者展菲指出，许多开发者在Demo阶段仅使用简单状态更新，但随着项目复杂度提升，缺乏统一调度机制会导致System执行顺序混乱、状态竞争等问题。 文章提出现代游戏必须构建Runtime内核，其核心在于任务调度（Scheduler）而非简单循环。Runtime需要管理： System执行顺序（如Input→AI→Physics→Animation→Render） 完整的生命周期（onInit/update/onDestroy等） 不同频率的
2026-06-29 13:58:34
115
原创 Agent Runtime：HarmonyOS PC 最值得关注的新架构
过去四十年，操作系统始终围绕Process和Thread构建 Runtime。而 AI Native 软件第一次让成为了新的运行对象。这意味着，传统的 Resource Runtime 已经无法独立支撑下一代软件。因此，HarmonyOS PC 最值得关注的新架构，并不是某一个 AI 助手，也不是接入某个大模型，而是一套能够长期管理目标、规划任务、组织上下文、调度工具并持续执行的。│││其中，Agent Runtime 不会替代操作系统内核，而是在其之上建立一层全新的。
2026-06-29 13:42:01
47
原创 HarmonyOS PC 为什么需要无状态组件（Stateless Component）？
文章摘要 本文探讨了AI Native时代下UI框架状态管理的范式转变。传统组件（Component）与状态（State）绑定的设计在AI持续运行场景中面临挑战：当任务跨页面、跨设备执行时，组件销毁会导致状态丢失。作者提出状态应归属于运行时（Runtime），而非组件，并通过HarmonyOS案例说明无状态组件如何更好地配合Goal/Task/Context等长期运行实体。未来架构可能形成"Runtime驱动"模式，由Goal Graph、State Runtime等维护核心状态，组件仅作为观察者渲染数据，
2026-06-29 13:32:51
146
原创 Task Graph：HarmonyOS PC 为什么重新定义任务调度？
Thread 如何运行？Task 如何完成？因此，未来的 Runtime 不会只维护 Thread Queue，而会维护一张持续演化的Task Graph。Scheduler调度 Thread。Scheduler调度 Task。从到，看似只是调度对象发生了变化，实际上意味着操作系统开始从资源调度（Resource Scheduling）迈向目标调度（Goal Scheduling）。而这，也正是 HarmonyOS PC 在 AI Native 时代重新定义任务运行模型的重要一步。
2026-06-28 18:04:08
1537
3
原创 Goal Graph：HarmonyOS PC 为什么要重写整个任务运行模型？
摘要： 展菲是一位专注于人工智能和前沿技术分享的资深开发者，在移动端、鸿蒙开发、物联网等领域有深厚造诣。他指出，随着大模型和Agent技术的兴起，传统以进程（Process）为核心的操作系统模型正在被以目标（Goal）为中心的运行模式取代。在AI Native时代，用户更关注任务目标而非具体应用，导致操作系统需要管理复杂的Goal Graph（目标图谱），而非简单的进程和线程。HarmonyOS PC通过构建基于事件驱动的Goal Graph模型，将任务、上下文、工具等动态关联，成为新一代AI运行时（Run
2026-06-28 16:13:18
1667
原创 Context Cache：HarmonyOS PC 下一代上下文系统揭秘
摘要： 本文探讨了AI应用中**Context Cache（上下文缓存）**的关键作用。传统AI系统每次请求都需重新构建完整上下文，导致响应慢、Token消耗高。作者指出，应缓存运行时上下文（如当前任务、工作区状态等），而非仅Prompt文本，以实现增量更新而非全量重建。Context Cache作为AI运行时的“工作记忆”，能显著提升推理效率与准确性。HarmonyOS PC凭借对工作区、任务等状态的实时维护，成为实现Context Cache的理想平台，可优化AI助手的响应速度与决策质量，避免重复计算带
2026-06-28 15:41:20
1485
原创 HarmonyOS PC 正在诞生新的 Scheduler：Agent 如何接管系统
摘要： 随着AI技术的演进，传统操作系统以线程（Thread）为核心的调度器（Scheduler）已难以满足AI原生应用的需求。未来软件将围绕目标（Goal）、任务（Task）和工具（Tool）等更高层对象进行调度，形成Agent Scheduler。HarmonyOS PC有望成为首个实现这一变革的平台，其调度系统将包含目标队列（Goal Queue）、任务拆解器（Planner）、任务调度器（Task Scheduler）、工具调度中心（Tool Dispatcher）和执行监控（Execution M
2026-06-28 15:21:14
1542
原创 Context Engine：HarmonyOS PC 最容易被低估的一层
本文探讨了AI应用开发中常被忽视的关键要素——Context（上下文）的重要性。作者展菲指出，当前AI应用开发过度关注模型参数、推理能力等指标，而忽视了Context Engine的核心作用。文章通过七个方面分析：1）Context将成为AI Runtime的核心管理对象；2）聊天记录不等同于运行时上下文；3）Context Engine实质是运行时状态数据库；4）Context比Memory更能反映当前状态；5）Context应属于Runtime而非聊天会话；6）HarmonyOS PC的Workspac
2026-06-26 11:36:00
2830
19
原创 从 RNN 到 GPT：大模型架构演化史
如果回顾过去十几年的发展，会发现每一次架构升级，其实都是为了突破一个工程瓶颈。传统神经网络│▼RNN（解决上下文）│▼LSTM（解决长期依赖）│▼Transformer（解决并行计算）│▼GPT（解决规模扩展）│▼MoE（解决推理成本）│▼Agent（解决任务执行）换句话说，AI 架构的发展从来不是简单的技术迭代，而是一场围绕记忆、计算、扩展、成本和执行能力展开的持续演进。谁的模型更大。谁的智能系统效率更高。因为对于下一代 AI 来说，
2026-06-26 11:05:26
286
4
原创 鸿蒙 App 如何实现 Multi-Agent 协同？一文讲透智能体团队架构设计
很多人以为：Multi-Agent = 多个 Agent。实际上：Multi-Agent = 一套面向复杂任务的分布式智能体系统。SupervisorAgent BusTask DAGRuntime未来 AI Native 鸿蒙应用的竞争，拼的也不再是谁接入了大模型。而是谁拥有更强的：Agent Runtime 与智能体协同能力。
2026-06-25 19:41:31
3799
4
原创 鸿蒙 App 如何设计 Memory Center？一文讲透 Agent 的长期记忆架构
AI Agent记忆中心架构解析 本文系统阐述了AI Agent中Memory Center的核心价值与设计方法。作者指出传统无状态系统无法满足AI Agent持续服务需求，提出四层记忆架构： 工作记忆（Working Memory）- 短期任务状态缓存 情景记忆（Episodic Memory）- 时间序列事件记录 语义记忆（Semantic Memory）- 用户画像向量存储 技能记忆（Procedural Memory）- 可复用工作流库 文章强调结构化记忆管理优于原始对话存储，建议采用向量数据库实现
2026-06-25 15:03:51
842
54
原创 为什么 GPU 利用率只有30%？揭秘大模型推理系统的真实瓶颈
大模型推理中GPU利用率低的系统瓶颈分析 本文从系统架构角度深入分析了大模型推理中GPU利用率低的本质原因。主要内容包括： GPU利用率的真实含义：反映SM忙碌程度而非工作时间占比 训练与推理的本质差异：推理面临小Batch、动态请求导致计算不连续 Decode阶段的瓶颈：Token逐个生成形成超小矩阵，GPU"吃不饱" Memory带宽限制：权重和KV Cache读取时间常超过计算时间 KV Cache的资源吞噬：大规模并发下显存管理成为主要挑战 Continuous Batching的价值：合并请求形成
2026-06-25 14:44:23
200
原创 鸿蒙 App 如何设计 Agent Runtime？一文讲透 AI Native Runtime 架构
展菲是资深人工智能研发专家，专注移动端与物联网开发，著有多本技术书籍。他在技术博客中深入分析了AI Native时代App架构的变革趋势，指出传统MVVM模式已无法满足AI Agent驱动的交互需求。文章系统阐述了Agent Runtime的七层架构（Intent/Planner/Scheduler/Memory/Tool/State/UI），强调其作为系统级运行时的核心价值——通过任务编排、记忆管理、工具调度等能力，实现从"事件驱动"到"目标驱动"的范式转换。这种新型运行时将成为AI原生应用的基础设施，如
2026-06-24 10:59:56
1832
32
原创 为什么 MoE 成为大模型降本增效的关键？
文章摘要：MoE——大模型降本增效的关键架构 本文深入分析了混合专家系统（MoE）如何解决大模型成本爆炸问题。传统密集模型（Dense Model）存在计算资源浪费的缺陷，所有参数必须全量参与计算。MoE通过引入路由器（Router）机制实现智能分流，每次推理仅激活少量专家模块（如总参数671B仅激活37B），在保持模型能力的同时大幅降低计算成本。文章详细阐述了MoE在训练成本优化、推理效率提升方面的优势，特别指出其天然适配Agent时代的特性。尽管存在跨节点通信等挑战，MoE仍代表了大模型发展的未来方向，
2026-06-24 10:14:13
182
3
原创 Goal Native OS：HarmonyOS PC 真正想重写什么？
摘要： 随着AI原生时代的到来，传统以"Process"为核心的OS架构面临变革。展菲（技术博主/图书作者）提出，用户关注的不再是具体应用（如微信或Chrome），而是目标（Goal）的完成（如"开发审批流"或"修复Bug"）。当前系统以进程（Process）和线程（Thread）为调度单元，而未来将转向Goal Native Runtime，通过上下文引擎（Context Engine）、任务规划（Goal Planner）和智能体调度（Agent Scheduler）等新层级，实现从"资源调度"到"目标
2026-06-23 10:40:36
1528
51
原创 HarmonyOS PC 为什么需要 Goal Planner？AI Native Runtime 的“大脑”到底是什么？
《Goal Planner：AI Native时代的操作系统核心》探讨了AI时代操作系统的范式转变。文章指出传统调度器(Scheduler)和流程引擎(Workflow Engine)的局限性，提出"目标规划器"(Goal Planner)将成为AI原生操作系统的关键组件。作者展菲（资深AI研发管理者）通过审批流测试案例，对比分析了三种技术方案的差异：传统调度器关注资源利用率但不懂业务目标；流程引擎能执行预设DAG但无法动态生成；而Goal Planner通过目标理解、上下文分析、任务拆解等步骤，实现从自然
2026-06-23 10:27:23
7056
原创 Task 正在取代 Thread：HarmonyOS PC 新执行模型
摘要 技术专家展菲提出，随着AI Native时代的到来，传统以线程（Thread）为核心的软件执行模型面临变革。在AI工作流（Workflow）、长任务（Long Task）等场景下，用户真正关心的执行单元已从线程转向任务（Task）。文章分析了Thread模型的局限性，指出其无法有效描述任务间的复杂依赖关系，而Task更适合作为跨应用、跨设备的执行对象。作者预测未来系统将形成"双执行系统"架构：底层保持Thread资源调度，上层由Task Runtime和Agent Runtime构建目标导向（Goal
2026-06-23 09:59:21
7062
1
原创 CPU Scheduler 不够了？HarmonyOS PC 新调度模型揭秘
HarmonyOS PC 预示操作系统调度模型的革命性转变 摘要：传统操作系统调度器（如Linux CFS）始终围绕CPU线程调度，但AI Native时代暴露出根本性缺陷——用户操作的是目标（Goal）而非线程。本文揭示： 调度范式转变：从CPU资源调度（Thread Scheduler）演进为目标驱动调度（Agent Scheduler），需处理任务依赖图（Task DAG）、上下文记忆等新维度 双层调度架构： 底层仍由Kernel Scheduler管理CPU/内存资源 新增Agent Schedul
2026-06-22 13:40:43
3756
33
原创 大模型训练中的网络瓶颈分析
摘要： 随着大模型规模突破千亿参数，训练瓶颈从单卡算力转向集群通信。本文从AI基础设施角度分析网络成为关键瓶颈的原因：1）模型参数量激增导致梯度同步通信量指数增长；2）AllReduce操作在分布式训练中引发通信风暴；3）PCIe带宽限制造成GPU等待；4）MoE架构加剧All-to-All通信压力；5）流水线并行受制于网络延迟。解决方案包括采用InfiniBand+RDMA实现μs级延迟、优化NCCL通信库，以及通过NVSwitch构建GPU直连架构。研究表明，当模型参数量达1T+时，网络性能直接决定训练
2026-06-22 13:24:19
193
1
原创 HarmonyOS 游戏 ECS 架构详解：为什么 Entity 不应该拥有逻辑？
ECS（Entity-Component-System）架构通过数据与行为分离解决游戏开发中的代码臃肿问题。核心思想是将传统OOP中耦合的逻辑拆解为：纯数据的Entity（仅ID标识）、存储状态的Component和执行业务的System。相比继承深、复用难的OOP方案，ECS通过组合式设计实现模块解耦——例如移动逻辑由MoveSystem统一处理所有带Transform+Speed组件的实体，而非分散在各对象类中。这种设计显著提升性能（连续内存访问优化CPU缓存命中率）与可维护性，成为Unity DOTS
2026-06-20 11:38:35
3864
33
原创 从0到1构建 HarmonyOS 游戏引擎
摘要：本文介绍了如何在HarmonyOS上从零构建轻量级游戏引擎。作者展菲作为资深开发者，提出传统UI框架无法满足复杂游戏需求，需要基于ECS架构（实体-组件-系统）设计独立游戏Runtime。核心模块包括World（游戏宇宙）、Entity（实体容器）、Component（数据载体）、System（逻辑处理）、Scene（场景管理）等，通过主循环驱动各系统协同工作。相比直接使用页面驱动，该方案具有状态隔离、多端适配、资源统一管理等优势，尤其适合中小型游戏和互动应用开发。文章提供了ArkTS实现的关键代码片
2026-06-20 11:00:15
10492
10
原创 HarmonyOS App × AI：从功能调用到任务执行的架构升级
摘要： AI Native App正在推动软件架构从"功能驱动"向"任务驱动"演进，用户意图取代UI成为新入口。传统App围绕页面和功能调用设计，而AI系统通过Agent理解意图、规划任务并调用工具（如HarmonyOS的Ability能力容器）自动完成跨模块操作。HarmonyOS的声明式状态管理天然适配Agent运行时，其多设备协同能力更可构建分布式Agent系统。未来App将围绕Skill（技能）而非页面组织，形成Skill Runtime生态，页面仅作为结果展示层。这一变革标志着从Function
2026-06-19 20:45:37
8184
2
原创 State 正在失效？HarmonyOS PC 新状态模型深度揭秘
本文探讨了传统状态管理模型在AI时代面临的边界问题。作者指出，过去二十年软件开发默认"状态属于页面"的前提正在被颠覆，随着多窗口、Workspace、Agent、长任务等场景的普及，真正持续存在的对象已从Page转变为Task/Context/Workspace。传统以页面生命周期管理状态的方式导致状态生命周期过短，无法满足AI时代"目标驱动"的软件需求。文章提出未来状态管理将向Workspace State、Context State演进，呈现图状结构（State Graph），并由UI、Agent、To
2026-06-19 15:02:19
11002
10
原创 组件正在失效？鸿蒙 PC 为什么要重写整个 Component 模型
摘要 本文探讨了传统前端组件模型在新时代面临的挑战与革新方向。作者指出，过去基于"Component=View"的假设已无法适应以Workspace、Task、Agent为核心的现代应用场景。传统组件生命周期与业务生命周期脱节，状态管理日益复杂，多窗口协作困难。随着AI驱动的交互模式兴起，组件需要从单纯UI元素进化为Runtime Node，支持双驱动模式（Human+AI）和持久化Context。文章特别分析了鸿蒙PC系统重构组件模型的必要性，提出未来组件将演变为系统模块（如AI Module、Task
2026-06-18 18:59:15
10066
1
原创 HarmonyOS PC 真正想重写的，不是桌面，而是 Runtime
《HarmonyOS PC的深层革命：从资源运行时到任务运行时》揭示了鸿蒙系统的真正野心——重构操作系统运行时架构。作者展菲（技术专家/图书作者）指出，传统OS围绕Process Runtime管理CPU/内存等硬件资源，而AI时代需要Workspace Runtime来管理跨应用/跨设备的任务上下文，以及Agent Runtime来调度以目标为导向的智能任务。这场变革的本质是从"Resource OS"升级为"Goal OS"，重构状态组织、任务调度等核心运行时能力，其竞争维度已超越Windows的桌面替
2026-06-18 18:58:45
10484
原创 从Store到Agent：鸿蒙游戏逻辑与渲染分层架构设计
本文由技术专家展菲分享鸿蒙游戏开发的架构演进路径。文章从新手常见的UI驱动架构问题入手，逐步剖析Store模式、System分层、Engine调度等核心架构思想。重点讨论了现代游戏开发中逻辑层与渲染层分离的必要性，并深入分析Agent时代下行为驱动架构的设计要点，提出基于Action的统一事件机制。全文通过典型代码示例，系统性地呈现了从简单状态管理到复杂Agent Runtime的完整演进过程，为鸿蒙大型游戏开发提供了清晰的架构设计指南。
2026-06-17 13:51:04
10236
3
原创 HarmonyOS 游戏 × Agent：NPC首次拥有自主意识
文章摘要：本文探讨了游戏AI从传统状态机到智能Agent系统的演进。作者展菲（企业AI研发管理者、技术博主）分析了传统NPC基于if-else规则的局限性，指出Agent系统通过感知、规划、记忆和行动模块实现自主决策。文章重点介绍了HarmonyOS中的Agent架构设计，包括World Model概念和分布式设备协同优势，并展望了未来游戏将由Agent动态生成剧情和任务的趋势。本文为开发者提供了游戏AI升级的技术思路，特别适合关注鸿蒙生态和前沿游戏技术的读者。
2026-06-17 12:09:10
10262
2
原创 鸿蒙游戏加载慢的根源是什么？ResourceSystem架构设计实战
文章摘要： 本文针对鸿蒙游戏开发中资源加载导致的性能瓶颈问题，提出系统化解决方案。通过分析典型卡顿案例（如场景切换黑屏、Boss战掉帧），指出75%的耗时源于资源处理而非渲染。作者构建了ResourceSystem架构，集成缓存管理、对象池和预加载机制，实现资源统一生命周期管理。该方案通过避免重复加载、GPU上传和内存碎片化，显著提升大型游戏性能。核心观点：完善的资源管理系统比单纯优化素材更能决定游戏性能上限，是复杂项目开发的必备基础设施。
2026-06-17 11:40:35
10223
原创 HarmonyOS App 接入大模型后，架构为什么必须重构？
《HarmonyOS App架构革新：从页面驱动到AI Native的Runtime时代》 摘要： 随着大模型技术融入HarmonyOS应用开发，传统"Page First"架构面临根本性挑战。本文揭示了当前AI接入模式的三大困境：业务边界模糊、状态管理失效和上下文割裂，并提出向"Runtime First"架构演进的四层体系。通过Workspace Runtime统一任务空间、Context Runtime聚合多维数据、Agent Runtime实现智能调度、Capability Runtime整合基础能
2026-06-16 18:58:19
10398
2
原创 为什么未来鸿蒙游戏的核心不再是渲染，而是 Runtime？
游戏引擎的未来：从渲染优先到运行时优先 随着AI技术发展，游戏引擎的核心正从传统渲染技术转向以Runtime（运行时）为中心的架构。过去引擎围绕Scene（场景）构建，关注GPU渲染效率；而AI驱动的NPC具备记忆、目标和社会关系，要求世界持续运行而非随玩家进出启停。鸿蒙等分布式系统更需World Runtime统一管理跨设备状态，推动架构演变为：System Runtime（调度Agent/任务/事件）→World Runtime（维护全局状态）→Render Runtime（投影显示）。未来引擎的竞争力
2026-06-16 18:40:21
10356
原创 当 AI 接管游戏世界：鸿蒙游戏 Workspace Runtime 架构揭秘
过去二十年，游戏行业一直在解决：如何让世界看起来更真实。未来十年，游戏行业将开始解决：如何让世界真正活起来。Scene↓Object↓RenderWorkspace↓↓↓Render这不仅仅是一次技术升级，而是一次游戏架构范式的变化。当 Agent 开始接管 NPC、当 Workspace 开始管理世界状态、当 Runtime 开始驱动任务流。真正的下一代鸿蒙游戏，可能已经不再是一个“场景集合”。持续运行的智能世界。
2026-06-16 16:03:50
5671
30
原创 AI 接管操作系统：鸿蒙 PC AI Native OS 架构揭秘
如果一句话总结：AI Native OS 到底是什么？操作系统里加一个 AI让 AI 成为操作系统的一部分进程文件设备目标任务上下文Agent用户操作软件用户描述目标AI 操作软件而鸿蒙 PC 的 Workspace、分布式协同、多设备能力以及 Runtime 架构，正在为这种系统形态提供天然土壤。从这个角度看：未来鸿蒙 PC 最大的机会，可能不是新的 App。一个真正能够理解目标、理解上下文、理解工作空间的新一代操作系统。
2026-06-15 19:03:52
1983
54
原创 为什么未来鸿蒙 PC 的核心不再是 App，而是 Workspace Runtime？
本文探讨了软件行业从App时代向Workspace时代的转型趋势。作者指出，传统以应用为中心的操作系统模型正在被打破，用户更关注任务能否自动完成而非具体使用哪个App。文章分析了Workspace Runtime的核心价值，包括整合碎片化应用状态、维护任务上下文、支持多设备协同工作流等。特别强调鸿蒙系统天然适合构建Workspace Runtime，因其多设备协同能力可实现工作空间的持续迁移。最后给出了基于ArkTS的Runtime架构设计和代码示例，展示如何管理任务状态、窗口状态等关键要素。这代表着人机交
2026-06-15 18:48:14
10450
原创 鸿蒙 PC 正在诞生“第二操作系统”：Agent Runtime 架构揭秘
不就是 AI SDK 吗？实际上完全不是。系统级运行时CPUMemoryFileNetworkTaskContextMemoryToolWorkspace你会发现，二者职责已经非常接近。如果一句话总结：为什么说鸿蒙 PC 正在诞生“第二操作系统”？因为未来真正重要的管理对象已经发生变化。进程文件设备网络任务上下文记忆工具工作区用户操作 App用户描述目标Agent 调度 App。
2026-06-15 18:24:46
10467
2
原创 AI Native 鸿蒙 App：从页面驱动到智能驱动的架构革命
摘要：本文探讨了AI Native App的架构演进趋势，指出传统以页面为中心的App架构正转向以智能体（Agent）为核心的新模式。作者提出四层AI Native架构（Presentation、AI Runtime、Domain Runtime、System Runtime），并通过鸿蒙开发实例演示了AI Runtime的实现。文章认为未来App的核心将从ViewModel转向Agent Runtime，最终形态将围绕用户目标而非页面操作构建。作者展菲作为资深技术专家，结合前沿技术实践，为开发者提供了AI
2026-06-13 20:11:59
11670
12
原创 鸿蒙游戏为什么掉帧？60FPS性能优化实战指南
鸿蒙游戏性能优化指南：稳定60FPS的关键策略 本文针对鸿蒙游戏开发中常见的性能问题，系统性地分析了影响帧率的核心因素及优化方案。主要内容包括： 60FPS的本质：每帧16.67ms的预算要求，需统筹逻辑计算、状态更新和渲染流程 典型掉帧原因： 高频状态更新触发无效渲染 全局Store设计导致的连锁更新 组件重复构建和过度嵌套问题 资源加载阻塞主线程 关键优化策略： 分离运行时状态与UI状态 按领域拆分Store管理 采用组件缓存(@Reusable) 预加载资源与对象池技术 构建分层架构（逻辑/状态/渲染
2026-06-13 19:47:31
11395
原创 鸿蒙游戏Runtime解析：Store如何驱动整个游戏世界？
《鸿蒙游戏开发：从状态管理到世界模型的架构演进》文章摘要： 本文探讨了鸿蒙游戏开发中状态管理的核心问题与架构演进。作者指出，小型游戏初期常因直接操作数据导致状态失控，而大型游戏需通过Store实现状态流向管理，统一状态修改入口以解耦系统。游戏Store不同于前端Store，需管理更复杂的"世界状态"，并驱动整个游戏运行。文章提出鸿蒙游戏实现方案：采用Observed和ObjectLink实现状态驱动，建议通过领域拆分避免"上帝对象"。最后指出AI时代Store正升级为World Model，为Agent提供
2026-06-13 19:27:12
11396
原创 AI + 鸿蒙游戏：下一代游戏架构正在形成吗？
FSM↓↓GOAP↓Agent↓↓规则驱动智能体驱动又恰好补齐了 Agent 所需的多设备协同能力。因此真正值得关注的或许不是：AI 能不能让 NPC 更聪明。而是：Agent Runtime、World Model 与 Harmony Distributed Runtime 结合后，会不会诞生一种全新的游戏操作系统。
2026-06-12 12:02:12
2212
34
原创 鸿蒙 App 图片加载优化：实现原理 + Demo实现
摘要 本文深入探讨了鸿蒙应用开发中的图片性能优化策略。作者展菲作为资深技术专家，从实际工程痛点出发，剖析图片加载成为性能瓶颈的根本原因：一张1080P图片从300KB解码到8MB的内存占用问题。文章系统性地提出了多级缓存架构（内存+磁盘+网络）、预加载机制、尺寸适配优化、列表懒加载、异步解码等解决方案，并给出具体代码实现。通过对比错误实践与优化方案，揭示了电商/社交类应用图片系统的设计要点，帮助开发者避免常见性能陷阱，提升应用流畅度与内存效率。
2026-06-12 11:31:31
11346
FBYBankCardRecognition-iOS-master.zip
2020-05-28
FBYFaceRecognitionDemo_iOS-master.zip
2020-04-28
LeetCode - #3 最长未重复子字符串
2021-11-16
TA创建的收藏夹 TA关注的收藏夹
TA关注的人