看到这个标题，可能有人会觉得一个 BMI 计算器有什么好写的，不就是两个输入框加一个除法。但真动手在 OpenHarmony 上把这件事做顺，你会发现难点根本不在数学公式，而在状态管理、单位换算和边界值处理。我最近就用 ArkTS 做了这么一个小应用：OpenHarmony 简易 BMI 健康指数计算器，把身高体重填进去，一键算出 BMI 值，给出分类判断和健康建议，全程离线可用。这篇文章就把整个项目从思路、布局、计算逻辑到踩过的坑完整过一遍，适合刚开始接触 OpenHarmony 应用开发、想用一个小工具练手 ArkUI 的朋友。

1. 项目拆解：别急着写代码，先想清楚 BMI 计算器到底要做什么

1.1 一次健康自评背后的真实需求

很多人对 BMI 的计算停留在“体重除以身高的平方”，但真要把这个功能做成一个能让普通用户正常使用的应用，需求远比这句公式复杂。你得先回答几个问题：身高输入的是厘米还是米？体重输入的是千克还是斤？结果怎么显示才能让人一眼看懂？要不要给健康建议？

这个项目的核心场景是“健康自评”。用户打开应用，填两个数，拿到一个结果，并且希望这个结果是能读懂的。也就是说，BMI 计算器不只是算数，它要完成“数据输入、单位换算、公式计算、结果分类、建议输出”这样一条完整链路。OpenHarmony 上这类轻量工具应用很适合作为入门项目，界面简单、逻辑独立、不依赖复杂网络能力，跑在模拟器上就能完整体验。

我最初的想法更简单，以为只要写一个函数就行。实际搭完页面才发现，一个合格的自评工具至少要考虑三件事：输入要防呆，算出来要准，结果要人话。所谓“防呆”，就是用户填了空值、填了负数、填了明显不合理的身高体重，应用不能直接崩溃，更不能给出一个荒谬的 BMI。所谓“要准”，指的是单位换算统一后，再用标准公式计算。所谓“人话”，就是不能只显示一个数字，要告诉用户偏瘦、正常、超重还是肥胖，并给出对应的日常建议。

1.2 为什么选 OpenHarmony 和 ArkTS 做这种小工具

选 OpenHarmony 做 BMI 计算器，不是因为大而全的生态，恰恰是因为它足够贴近“轻量终端”的场景。健康自评这类功能，未来完全可能出现在智能手表、平板、带屏设备上。OpenHarmony 的 ArkUI 声明式写法，写一次界面代码，后续迁移到不同形态设备时不需要重写整套 UI 逻辑，这一点对工具类应用很友好。

ArkTS 的语言风格本身也适合这个项目。它基于 TypeScript 语法，要求类型清晰，禁止很多不规范的隐式转换。对这种小型计算逻辑来说，类型明确反而是一种保护。我在项目里用到了@State装饰器管理输入框的值，用到parseFloat解析数字，用到条件判断做分类，用到的都是非常基础的能力，却能把完整交互撑起来。换句话说，这个项目不需要碰网络请求、数据库、多线程这些重东西，它天然适合验证“从零到一”的 OpenHarmony 应用开发流程。

如果你以前写过 Android 的 XML 布局，再来看 ArkUI 会有一种很直接的感受：界面是写出来的，不是拉出来的。Column、Row、Text、TextInput、Button这些组件，组合方式跟搭积木一样，去掉了很多繁琐的布局嵌套。我建议新手从这种单一页面的计算器开始，而不是一上来就做多页面、列表、路由跳转，因为后者很容易让你在框架 API 里迷失方向。

1.3 BMI 计算规则：这不是数学题，是交互逻辑

BMI 的标准公式是体重（千克）除以身高（米）的平方。这个公式本身属于小学算术范围，但放到真实场景里就会衍生出一堆细节。用户输入习惯五花八门：身高大概率写厘米，比如 175，体重可能写斤，比如 130，性别、年龄也会影响健康评价，但基础版项目里不建议一开始就做复杂个性化。

我做的是中国成人参考标准，同时也保留了国际通用标准的扩展空间。成年人 BMI 分类大概分成四档：偏瘦、正常、超重、肥胖，具体边界值如下表：

注意：BMI 是一个健康自评参考指标，不构成医疗诊断。肌肉量高的人群、孕妇、未成年人等特殊情况下，BMI 的参考意义有限。

我在实现分类判断时，用的是分段式条件判断，而不是在界面上写死一段文字。这样后续如果要切换成不同地区的标准，只需要改阈值常量。把业务规则和界面显示拆开，算是这个小项目里最有价值的工程习惯之一。

2. 环境搭建与页面骨架：十分钟跑通一个 OpenHarmony 空白应用

2.1 开发工具能跑起来就不容易了

OpenHarmony 应用开发目前最常见的是通过 DevEco Studio 来完成工程创建。安装这块没什么捷径，把开发工具、SDK、模拟器配齐就是最花时间的环节。版本对齐特别重要，不同版本的工具链对应不同的 API Level，如果创建工程时选择的 SDK 版本和本地模拟器不匹配，后面编译会冒出各种奇怪的报错。

新建项目时我建议选Empty Ability模板，工程语言选择 ArkTS，模型选 Stage 模型。Stage 模型是当前主流，应用入口、页面管理、权限配置都更规范。包名可以写成一个示例域名，工程创建完成后会自动生成默认的EntryAbility入口和pages/Index.ets页面，我们只需要在这个页面里改造内容。

有个小建议：工程创建后先不要急着写代码，先跑一次空白模板，确认模拟器能启动、应用能安装。这一步看起来多余，但它能帮你把“环境问题”和“业务代码问题”区分开。我见过很多新人改了页面代码后，分不清是编译报错还是模拟器问题，最后越调越乱。先把基线跑通，后面写任何代码心里都有底。

2.2 页面结构：先画一个布局草图

BMI 计算器的界面不需要花哨，三块内容就够了：标题区、输入区、结果展示区。用 ArkUI 的布局组件来组合，最外层是一个垂直方向的Column，内部放两个输入模块，每个输入模块由一行数值输入框和单位切换按钮组成，最下方放一个计算按钮和一个结果卡片。

我当时先画了一个简单的布局草图：

• 顶部：大标题“BMI 健康指数计算器”
• 身高区：输入框 + 单位切换按钮（cm / 米）
• 体重区：输入框 + 单位切换按钮（kg / 斤）
• 计算按钮：“开始计算”
• 结果区：BMI 数值、分类结果、健康建议

对应到 ArkUI 代码，大概是这样：

@Entry @Component struct BmiPage { @State heightInput: string = '' @State weightInput: string = '' @State heightUnit: string = 'cm' @State weightUnit: string = 'kg' @State bmiResult: string = '--' @State category: string = '' @State advice: string = '' build() { Column({ space: 16 }) { Text('BMI 健康指数计算器') .fontSize(24) .fontWeight(FontWeight.Bold) Text('身高') .fontSize(16) Row({ space: 8 }) { TextInput({ placeholder: '请输入身高', text: this.heightInput }) .layoutWeight(1) .type(InputType.NUMBER) .onChange((value: string) => { this.heightInput = value }) Button(this.heightUnit === 'cm' ? 'cm' : '米') .onClick(() => { this.heightUnit = this.heightUnit === 'cm' ? 'm' : 'cm' this.heightInput = '' this.clearResult() }) } Text('体重') .fontSize(16) Row({ space: 8 }) { TextInput({ placeholder: '请输入体重', text: this.weightInput }) .layoutWeight(1) .type(InputType.NUMBER) .onChange((value: string) => { this.weightInput = value }) Button(this.weightUnit === 'kg' ? 'kg' : '斤') .onClick(() => { this.weightUnit = this.weightUnit === 'kg' ? '斤' : 'kg' this.weightInput = '' this.clearResult() }) } Button('开始计算') .width('100%') .onClick(() => { this.calculateBmi() }) Column({ space: 8 }) { Text(`BMI：${this.bmiResult}`) .fontSize(32) .fontWeight(FontWeight.Bold) Text(this.category) .fontSize(20) Text(this.advice) .fontSize(16) } .width('100%') .padding(16) .backgroundColor('#f5f5f5') .borderRadius(12) } .width('100%') .padding(16) } }

这段代码的阅读思路是：界面从上到下依次堆叠，Row解决输入框和单位按钮的横向排列，layoutWeight(1)让输入框自动撑满剩余宽度，.type(InputType.NUMBER)让弹出来的是数字键盘。布局本身不复杂，但它把 ArkUI 最基础的组件用了一遍，后续要扩展界面也是在这个基础上加东西。

2.3 运行到模拟器和真机的差别

跑模拟器时要注意，默认模拟器对中文输入法的支持不一定完整，但 BMI 计算器只需要数字输入，用数字键盘类型影响不大。预览器其实就是个快速看布局的工具，它适合静态检查 UI，不适合验证完整交互。我习惯把“快速 layout 检查”和“真机/模拟器运行验证”分开，这样定位问题更快。

单位切换按钮触发后清空输入框，是我在这个项目里特意加的。原因很简单：身高 175 在厘米单位下是合理值，如果切到米单位，175 就成了一个离谱的数值，不清空会让用户在不知情的情况下算出一个荒谬结果。这个设计虽然简单，但很影响体验。

3. 核心逻辑实现：状态管理、单位换算与基础数学

3.1 双向绑定与输入处理：@State 是 ArkTS 的“状态内存”

ArkUI 声明式开发的核心思路是“数据驱动界面”。页面里用@State修饰的变量，一旦值发生变化，UI 会自动重新渲染。对这个项目来说，heightInput、weightInput、bmiResult这些变量全部用@State管理，这样输入框每敲一个字符，状态就更新一次。

TextInput的onChange回调会持续触发，我们在回调里把最新字符串存进状态变量。这里有个关键点：输入框的text参数也绑定了同一个状态变量，看起来像双向绑定。但如果你在onChange里去修改输入值，可能会出现光标跳动或者用户输入被覆盖的情况。所以在这个项目里，我坚持“只存不改”：onChange只是把输入值存起来，真正的计算发生在点击按钮之后。

之所以不在输入过程中实时计算，是为了避免中间状态干扰体验。比如用户先填身高再填体重，中间过程数值不完整，实时算出来的结果也没意义。点击按钮再计算，逻辑更清晰，也方便将来扩展“实时计算”的开关。

3.2 单位统一：身高厘米转米，体重斤转千克

基础数学在这里体现得最明显。所有计算开始之前，必须先把用户输入的数据换算成标准单位：身高统一成米，体重统一成千克。否则公式用错单位，结果会错得非常离谱。

具体换算规则是：

• 如果身高单位是 cm，先除以 100 转成米；如果已经是米，就直接使用。
• 如果体重单位是斤，先除以 2 转成千克；如果已经是千克，就直接使用。

换算逻辑写成代码：

function parseHeight(value: string, unit: string): number { let height = Number.parseFloat(value) if (unit === 'cm') { return height / 100 } return height } function parseWeight(value: string, unit: string): number { let weight = Number.parseFloat(value) if (unit === '斤') { return weight / 2 } return weight }

这样处理之后，后续计算只需要一行公式：

let bmi = weightKg / (heightM * heightM)

可能有人会问，怎么不用Math.pow(heightM, 2)？两种写法都可以，heightM * heightM在数值简单时更直观，可读性也更好。对于 BMI 这个场景，平方运算用乘法就够了，没必要引入函数调用。

3.3 校验逻辑：程序防呆是体验的一部分

校验是这类小工具最容易忽略但最不能忽略的部分。直接在计算函数开头堆if判断，看起来很简单，但对用户来说，这些判断决定了工具是否“靠谱”。

我在项目里处理了四类非法输入：

• 输入为空：提示“请完整填写身高和体重”。
• 解析结果为非数字：提示“请输入有效数字”。
• 数值小于等于 0：提示“身高或体重不能为 0 或负数”。
• 数值明显异常：例如身高小于 20 或大于 250 厘米、体重小于 5 或大于 300 千克，直接说明合理范围。

加范围校验是我在实际使用后补上的。第一次做完只做了空值和正负判断，然后我发现填“身高 1 厘米、体重 1 千克”也能算出一个看似正常的结果，但没有任何实际意义。后来就加上了合理范围判断，并且在提示里写出可参考的范围，而不是干巴巴地说“输入非法”。

完整计算逻辑大致是这样：

calculateBmi() { let heightM = this.parseHeight(this.heightInput, this.heightUnit) let weightKg = this.parseWeight(this.weightInput, this.weightUnit) if (this.heightInput === '' || this.weightInput === '') { this.category = '请完整填写身高和体重' this.advice = '' return } if (isNaN(heightM) || isNaN(weightKg)) { this.category = '请输入有效数字' this.advice = '' return } if (heightM <= 0 || weightKg <= 0) { this.category = '身高或体重不能为 0 或负数' this.advice = '' return } let bmi = weightKg / (heightM * heightM) let roundedBmi = Math.round(bmi * 10) / 10 this.bmiResult = roundedBmi.toFixed(1) this.updateCategory(roundedBmi) }

保留一位小数时，我用的是Math.round(bmi * 10) / 10，而不是直接toFixed(1)。原因是toFixed存在四舍五入的不确定性，先通过Math.round得到数值结果，再转字符串展示，展示层就稳定很多。

3.4 结果分类与健康建议：边界值怎么归属

分类判断的代码并不复杂，难在各档位的边界归属。18.5、23.9、24、28 这些临界值，在判断时一定要用一致的比较方向。我写的是“上一档的下限包含，下一档的上限左开”，这样每个数值只会命中一个分类。

updateCategory(bmi: number) { if (bmi < 18.5) { this.category = '偏瘦' this.advice = '建议保证均衡营养，规律作息，适当增加蛋白质摄入。' } else if (bmi >= 18.5 && bmi < 24) { this.category = '正常' this.advice = '身体质量指数处于正常范围，继续保持良好生活习惯。' } else if (bmi >= 24 && bmi < 28) { this.category = '超重' this.advice = '建议控制高热量食物，增加日常活动量。' } else { this.category = '肥胖' this.advice = '建议制定科学的饮食与运动计划，必要时咨询专业人员。' } }

这里的bmi >= 18.5 && bmi < 24和表格里的 18.5 ~ 23.9 是一致的，只是代码里用了 24 作为开区间上界。如果将来参考标准调整，只需要改阈值，不用动整体逻辑。这也是我在前面强调的“规则与界面分离”，在这个项目里的实际落地。

建议文案我尽量写得口语化、可操作，但不会写具体药方和运动计划，一方面是项目定位就是自评参考，另一方面也避免把工具做成“医疗建议生成器”，这是内容和定位双重安全考虑。

4. 实操过程与避坑记录：这类小工具最容易翻车的点

4.1 输入框键盘和单位切换的兼容问题

项目里我直接给TextInput设置了数字键盘，实际跑起来发现不同模拟器对数字键盘的表现不一样。有的环境里InputType.NUMBER能弹出数字键盘，有的只弹出常规键盘。这不是我们代码能完全控制的，但可以在输入框上再加一层“只允许数字和小数点”的字符过滤。

单位切换按钮在 ArkUI 里我是用普通Button实现的，每次点击切换状态并清空输入值。这样做的好处是逻辑简单，坏处是按钮的选中态不够明显。如果做完这个版本还想优化，可以考虑引入Radio组件，用单选组来表达当前单位。但基础版不建议投入太多精力在控件外观上，先把状态切换逻辑跑通更重要。

我遇到的另一个问题是切换单位后，之前的 BMI 结果还显示在界面上。用户可能误以为这是新单位下的结果。于是我每次切换单位都调用clearResult()，把结果归位为初始状态。这种细节不写代码的时候很容易漏，但直接影响用户对数据的信任。

4.2 浮点精度和极端数据的处理

用浮点数做四则运算，迟早会遇到精度问题。BMI 计算虽然只是除法，但在某些数值组合上，结果会出现一长串小数位。我在结果展示前做了“四舍五入保留一位小数”，然后再显示，避免出现“24.999999999”这种让用户困惑的内容。

极端数据也要限制。比如用户输入身高 2.5 米、体重 200 千克，算出来的 BMI 是 32，看起来合理，但实际场景里这类数据还有待商榷。我加了一个合理范围判断，但不把范围限制得太死，毕竟不同人的体型差异很大。如果输入超出明显物理可能，比如身高 10 米、体重 1 千克，我会直接拦截而不是参与计算。

拦截时机放在单位换算之后、BMI 计算之前。因为单位换算后的数据才是统一标准下的数值，比如身高按厘米时 175 在范围内，按米时 175 就是超出范围了。这也是单位切换后清空输入框的另一个理由，避免用户沿用旧数值触发限值提示。

4.3 软键盘遮挡与布局重排

模拟器上测试时，点击输入框弹出软键盘，结果区可能被顶上去或者被遮挡。OpenHarmony 侧处理软键盘有一个基本思路，就是让页面整体能够滚动或避让。我这个项目页面上内容不多，但手机上屏幕高度有限，键盘弹起后结果区确实可能被挡住。

简单处理方法是把最外层Column放进Scroll，或者在页面配置里允许键盘避让。我选了Scroll方案，因为键盘避让在不同版本上的默认行为不一致，Scroll至少能保证用户滚动后看到底部内容。这里唯一的坑是Scroll和Column的嵌套写法要先理清楚，Scroll里放一个Column，再在Column里排内容，而不是让Scroll直接管理多个子组件。

4.4 常见问题速查表

把这次项目中可能遇到的问题整理成一个速查表，以后有人在这个项目基础上二次开发，排查效率会高很多。

4.5 我踩过的一个印象深刻的坑

这个项目里最让我印象深刻的问题，是“计算结果正确，但建议文案却不匹配”。排查了很久才发现，BMI 值和分类文字是分开的两个状态变量，计算函数里更新了bmiResult，但分类建议在另一个函数里异步更新，顺序没控制好，界面已经刷新了，分类还是旧值。后来我把计算和分类放在同一个同步流程里，在一个calculateBmi()方法里依次完成所有状态更新，问题就没了。

这个教训很基础，但很值得记下来：一个页面的多个状态变量更新，要尽量保持原子性，不让 UI 有机会渲染“中间状态”。尤其是这种几行代码就能完成的小计算逻辑，写成一个大流程反而比拆成多个异步函数更稳。

5. 从 BMI 计算器到健康自评：可以继续做的方向

5.1 如果让我重新做一遍，我会怎么调整

第一件事，我会把状态变量整理成一个数据模型。现在项目里heightInput、weightInput、heightUnit、weightUnit是四个分散的@State字符串，代码量小的时候没什么感觉，但等我要增加性别、年龄、记录历史这些功能时，分散管理就会变得混乱。定义成一个HealthMetricModel之类的对象，整体状态更新更清晰。

第二件事，我会把健康建议文案抽到单独的文件里，而不是写死在页面里。这个项目里建议就几行字，以后想根据性别、年龄段给出不同建议，如果还堆在updateCategory里会非常长。拆出去之后，维护文案的人可以完全不碰代码。

第三件事，我会增加“历史记录”和“趋势图”这两个扩展点。健康自评不应该是算完就扔，如果能把每次计算结果本地存下来，用一张简单的折线图展示 BMI 变化趋势，这个应用就从一个一次性计算工具变成了一个轻量健康管理工具。OpenHarmony 的 Canvas 组件可以实现简单的趋势图，不需要引入第三方图表库。

5.2 我在这个项目里学到的核心一课

这个小项目让我对 ArkTS 的最大感受，不是它有多强大的框架能力，而是它把“界面状态”和“业务计算”的边界逼得非常清楚。用@State管理视图数据，用纯函数处理单位换算和 BMI 计算，页面组件只负责展示和用户交互，数据逻辑只负责算数和校验，整个代码结构不需要复杂架构就能保持可读。

如果你也打算用 OpenHarmony 练手，我建议就从这种“单页、单功能、纯本地”的工具开始。它不需要网络、不需要数据库、不需要多页面跳转，却能把 ArkUI 最核心的状态管理、组件组合、事件回调全部覆盖一遍。做完以后，再往里面加特性就会顺很多。

现在你拿到这套代码和思路，完全可以自己动手复刻一版。先确认开发环境能跑通，再照着页面骨架把界面搭起来，然后实现校验与计算逻辑，最后自己多测几组边界数据。踩坑的过程本身就是这个项目最有价值的部分。