鸿蒙计算器应用模板实战：ArkTS 状态驱动与 AI Shell 查 ECS 占用

今天在鸿蒙开发实践中心浏览了“计算器应用模板”案例，并给它的 GitCode 代码仓 harmony-practice-center/HarmonyOS-APPTMPL-calculator 点了 Star；随后又在 AI DevSpace 的 AI Shell 里问了一个问题：一台运行中的 ECS 实例，怎么查看 CPU 和内存占用。这篇笔记把两件事合在一起写：一个是端侧小应用的状态管理，一个是云端实例的资源观测。看起来是两个方向，道理却是相通的——先把状态看清楚，再动手。

一、计算器模板：小应用里的状态机思维

计算器是几乎人人都会用的应用，功能却一点也不“简单”。案例页面把它拆成五类按键事件：输入数字、小数点、运算符、等号、清零，以及退格。整个应用的核心不是界面排版，而是一组状态：当前正在输入的数字、待执行的运算符、上一轮的计算结果，以及“刚按过等号”这个标志位。

ArkTS 的做法是状态驱动：每一次按键只做一件事——改状态，显示区域只是状态的投影。这样做的好处是逻辑集中，界面不会和计算纠缠在一起。例如按数字键，就是把字符追加到当前输入串；按运算符，先把上一轮算完，再把新运算符存起来；按等号，按保存的运算符做一次结算，把结果写回显示，并把“刚算完”标志置位。

案例里的实现要点大致是这几条：第一，显示区同时服务两种角色，既显示正在输入的数字，也显示上一次的结算结果，靠状态区分；第二，等号结算用分支处理加减乘除，运算前先做除零判断，除零时给出提示而不是直接崩掉；第三，退格只删最后一个字符，删空后回到 0；第四，清零把全部状态一次性归位，不留残留。

二、三个容易踩的坑

第一个坑是浮点误差。JavaScript 里 0.1 + 0.2 不等于 0.3，计算器如果直接用原生浮点运算，用户算 0.1 + 0.2 会看到 0.30000000000000004。案例引入了 decimal.js 做十进制运算，这一步很关键：凡是涉及钱和精确数值的场景，都不要直接用二进制浮点做加减。

第二个坑是连续按运算符。比如先按“+”又按“-”，应该以最后一次为准，而不是把两个运算符都存下来。处理办法是：后一次运算符直接覆盖前一次，输入串不变。

第三个坑是等号之后的输入。算出结果后再按数字，应该是开启一轮新算式，而不是把数字追加到结果后面；算出结果后直接按运算符，则是拿结果当作下一轮的第一个操作数。这两种行为由“刚算完”标志位区分，缺了它，体验会立刻变怪。

三、在 AI Shell 里问运行中 ECS 的 CPU 与内存占用

今天在 AI Shell 里提的问题是：“如何查看一台运行中的 ECS 实例的 CPU 和内存占用情况？请给出控制台和命令行两种方法，并说明占用过高时怎么定位原因。”AI Shell 给出的回答分三大块，我对照着记下来。

控制台方法是走云监控服务 CES：进 ECS 控制台选中实例，在监控页签看 CPU 使用率、内存使用率曲线；也可以直接进云监控服务的主机监控，选实例看指标。云监控默认按 5 分钟粒度采集，免费版只保留 5 分钟粒度的数据，1 分钟粒度需要开启企业版。建议同时看 1 小时和 1 天两个时间范围的曲线，判断占用是突发毛刺还是持续爬升。

命令行方法是在实例内执行：top 按 CPU 排序看最耗的进程，free -h 看内存总量、已用和可用，vmstat 1 看系统整体的 CPU 与内存变化，ps aux --sort=-%mem 看内存占用前几名的进程。排障时优先用 top 看单进程，再结合内存曲线看是不是某个进程在缓慢泄漏。

占用过高时的定位顺序是：先看指标趋势，判断是突发还是持续；再看进程排序，锁定最耗的进程；然后看业务日志和定时任务，确认是不是批量任务或异常请求导致；最后才决定是优化代码、加缓存，还是给实例升配。不要一上来就升配，先找到根因。

四、两个实践的共同点：先看状态，再动手

写计算器时，显示错了先查状态机；查 ECS 时，负载高了先看监控曲线。两边都在做同一件事：把“当前状态”变成看得见的东西，再基于它做决策。前端的 @State 是内存里的状态，CES 的指标是运行时的状态，差别只是存放位置不同。

今天的收获有两点。第一，别看计算器小，它把状态驱动、浮点精度、边界处理这几个基本功都练到了；第二，云上排障有一条固定顺序——趋势、进程、日志、根因，跳过任何一步都容易误判。接下来我打算照着计算器模板自己实现一遍，并把 CES 的 CPU 告警配起来，让占用超过阈值时第一时间收到提醒。