Flutter for OpenHarmony:Flutter 三方库 stack 轻量级实现 LIFO 栈数据结构(基础算法引擎)(适配鸿蒙 HarmonyOS Next ohos)

Flutter for OpenHarmony:Flutter 三方库 stack 轻量级实现 LIFO 栈数据结构(基础算法引擎)(适配鸿蒙 HarmonyOS Next ohos)

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net

Flutter for OpenHarmony:Flutter 三方库 stack 轻量级实现 LIFO 栈数据结构(基础算法引擎)(适配鸿蒙 HarmonyOS Next ohos)

请添加图片描述

前言

在鸿蒙(OpenHarmony)应用的基础逻辑中,后进先出(LIFO)模型常用于浏览器历史回退、撤销重做或表达式解析等场景。stack 库提供了一个纯粹、语义明确且具备类型保护的封装,是追求代码可读性时的理想选择。

一、核心价值

1.1 基础概念

栈(Stack)就像是一个“窄长的桶”,你只能从顶部放入或取出物品。

数据入口/出口

栈顶 TOP

最新放入: Element C

Element B

最先放入: Element A

栈底 BOTTOM

1.2 进阶概念

  • Push (入栈):向栈顶压入一条数据。
  • Pop (出栈):从栈顶弹回并移除一条数据。
  • Top/Peek (察看):只看一眼栈顶是什么,不破坏栈的结构。
  • Empty Check:极其高效地判断当前鸿蒙业务流是否已溯源到头。

二、核心 API / 组件详解

2.1 创建并操作栈

import'package:stack/stack.dart'as stack_lib;// ✅ 推荐做法:使用别名防止命名冲突voidharmonyStackDemo(){final historyStack =stack_lib.Stack<String>();// 1. 压入操作记录 historyStack.push('首页'); historyStack.push('详情页');// 2. 查看当前位置print('📍 鸿蒙当前所在页面: ${historyStack.top()}');// 3. 模拟“回退”if(historyStack.isNotEmpty){ historyStack.pop();print('🔙 退回到了: ${historyStack.top()}');}}
在这里插入图片描述

三、场景示例

3.1 场景一:鸿蒙级应用的“万能撤销”管理器

在绘图或便签应用中,记录用户的每一步操作。

import'package:stack/stack.dart'as s;classUndoManager<T>{final _undoStack =s.Stack<T>();// 💡 技巧:保存状态快照voidsaveState(T state)=> _undoStack.push(state);// 💡 技巧:执行撤销T?undo(){if(_undoStack.length >1){ _undoStack.pop();// 弹出当前状态return _undoStack.top();// 返回上一步}returnnull;}}
在这里插入图片描述

四、OpenHarmony 平台适配挑战

4.1 深度嵌套与 Stack Overflow(逻辑层面)

虽然该库操作的是堆内存,但在处理数万级深度的递归解析任务(如极其庞大的嵌套 JSON)时。

适配策略建议

  1. 长度监控:在鸿蒙侧的业务逻辑中,建议为栈设置一个“最大深度”阈值,防止极端的恶意循环导致内存占用失控。
  2. 序列化支持:该库本身不支持持久化。如果你希望鸿蒙应用重启后还能撤销,需要手动遍历栈的内容并存入数据库。

五、综合实战示例代码

这是一个包含了基础 UI 交互的“鸿蒙表达式括号匹配”检测器:

import'package:flutter/material.dart';import'package:stack/stack.dart'as s;classHarmonyBracketCheckerextendsStatefulWidget{constHarmonyBracketChecker({super.key});@override _HarmonyBracketCheckerState createState()=>_HarmonyBracketCheckerState();}class _HarmonyBracketCheckerState extendsState<HarmonyBracketChecker>{ bool? _isValid;final _controller =TextEditingController();void_check(String text){final stack =s.Stack<String>(); bool valid =true;// 💡 核心算法:经典的栈式括号匹配for(int i =0; i < text.length; i++){String char = text[i];if(char =='('){ stack.push(char);}elseif(char ==')'){if(stack.isEmpty){ valid =false;break;} stack.pop();}}setState(()=> _isValid = valid && stack.isEmpty);}@overrideWidgetbuild(BuildContext context){returnScaffold( appBar:AppBar(title:constText('stack 鸿蒙算法实战')), body:Padding( padding:constEdgeInsets.all(20), child:Column( children:[TextField(onChanged: _check, decoration:constInputDecoration(hintText:'输入带括号的表达式验证...')),constSizedBox(height:40),Text( _isValid ==null?'待验证':(_isValid!?'✅ 括号完整':'❌ 存在括号缺失'), style:constTextStyle(fontSize:22, fontWeight:FontWeight.bold),)],),),);}}

六、总结

stack 库以一种极其克制的 API 设计,为鸿蒙开发者提供了一个纯净的数据结构工具。它让你的代码在处理“溯源”、“递归”和“回退”逻辑时,比直接操作 List 更加稳重、专业。

核心建议

  1. 涉及简单的 LIFO 场景时,优先使用此库以提高代码语义。
  2. 在处理涉及算法竞赛或编译器原理的鸿蒙应用时,它是你的基石。

Read more

前端转型AI的“第一公里”:如何建立正确的AI心智模型?

前端转型AI的“第一公里”:如何建立正确的AI心智模型? 在过去的一年里,我见证了太多前端同行的焦虑与迷茫。AI浪潮袭来,很多人匆忙上阵,学会了调用OpenAI的API,甚至跑通了LangChain的Demo,但在实际落地时却频频踩坑。 我们习惯了确定性的世界:输入1 + 1,输出必然是2;写了display: flex,布局必然改变。然而,AI开发是一个概率性的世界:同样的Prompt,两次调用可能得到截然不同的结果。这种底层逻辑的冲突,是前端转型AI最大的“拦路虎”。 很多前端工程师把大模型仅仅当成一个“智能API接口”,试图用传统的硬编码逻辑去控制它,结果往往是Prompt越写越长,系统却越来越不稳定。这并非技术能力不足,而是心智模型尚未完成迁移。 从“函数思维”到“上下文思维” 传统前端开发的核心是“函数思维”:我们定义输入、处理逻辑和输出,追求的是精准控制。但在AI应用开发中,这种思维必须升级为“上下文思维”。 大模型本质上是一个“概率预测机”。它不像函数那样执行指令,而是像人一样理解语境。前端开发者转型AI的第一步,不是去学Python深度学习框架,而是学会如

By Ne0inhk
2025年广西网络与信息安全职业技能竞赛决赛 awd web部分 赛后WriteUP以及自我检讨

2025年广西网络与信息安全职业技能竞赛决赛 awd web部分 赛后WriteUP以及自我检讨

今天,广西省赛决赛,也是我第一次打awd线下赛。我搞砸了,彻彻底底。 直到最后比赛结束,大脑依旧一片空白,在断网环境下我就像被拔掉了个移动硬盘,手足无措,一道题也没做出来。 我的队伍只有我一个人,但是我不认为这是我失败的借口,一个人组队,意味着我要更清醒地意识到自己应该做怎样的准备,以及自己应该做什么。比赛一开始,我就因为过度紧张,犯了一个极其低级、愚蠢的错误:我完全没有仔细看裁判发的纸质密码文件信封还有第二张纸片(可能一开始也宣读过了,但是我因为紧张完全没听见),我像个二哔一样死盯着平台上的密码。在问了几个裁判,他们让我“重新登录平台”却依旧失败后,我才从另一位裁判那里得知,信封里的第二张纸片上写着ssh的正确密码。 就这一个错误,让我白白浪费了开局的十几分钟,选手防御时间就二十分钟。节奏彻底乱了。 登录上去之后,因为断网环境而手足无措。大脑一片空白像被灌满了浆糊。面对PHP的那个框架、Java的那个CMS,代码量都很乱很多,我明明知道它们肯定有漏洞,可我一个都找不到。那些在网上搜索复现、在AI辅助下看起来一目了然的漏洞点,在断网的时候,无比陌生。我像个无头苍蝇,

By Ne0inhk
API 设计的 7 个致命错误:为什么你的接口让前端想打人

API 设计的 7 个致命错误:为什么你的接口让前端想打人

凌晨一点,前端在群里 @了你 “后端大哥,为什么删除用户的接口是 POST?” “为什么获取用户列表要传 20 个参数?” “为什么同一个错误,有时返回 200,有时返回 500?” “能不能别再改接口了?这是这个月第三次了!” 你看着手机,心里一万头草泥马奔腾而过。 明明功能都实现了,为什么前端还是不满意? 因为你的 API 设计,可能犯了这 7 个致命错误。 今天,我们就来聊聊那些让前端抓狂、让自己背锅、让项目延期的 API 设计问题。 错误 1:把数据库表结构直接暴露成 API 灾难现场 // ❌ 直接暴露数据库结构GET/api/user_account_info?user_id=123// 返回{"user_id"

By Ne0inhk
全网最详细!!!Django+Vue3 全栈开发进阶:从后端接口到前端交互实战

全网最详细!!!Django+Vue3 全栈开发进阶:从后端接口到前端交互实战

引路者👇: 引言: 第一章:Django 视图与路由:构建灵活的后端入口 1.1 URL 路由进阶:精准匹配与模块化拆分 1.1.1 路径转换器:捕获动态 URL 参数 1.1.2 正则表达式:复杂 URL 模式匹配 1.1.3 命名空间与模块化路由:解决多 App 冲突 1. 根路由配置命名空间(project/urls.py) 2. App 内路由定义(blog/urls.py) 3. 反向解析路由(视图 / 模板中) 1.2 视图函数优化:

By Ne0inhk