一、为什么做饭的人不看屏幕
菜谱应用有个天然矛盾：做法是文字，做饭时两只手是脏的、眼睛在锅上。1.0.4 版本我把"朗读文章"做成了首页一级入口，用 Core Speech Kit 的 textToSpeech 把健康饮食文章读出来——边做饭边听。本文记录这套朗读能力的接入过程和几个关键取舍。
二、引擎创建：一次创建，随页销毁
朗读的核心是 TextToSpeechEngine。工程里的创建代码：
import { textToSpeech } from '@kit.CoreSpeechKit'
async createSpeechEngine(): Promise<textToSpeech.TextToSpeechEngine | undefined> {
return await textToSpeech.createEngine({ /* 配置 */ })
}
第一个取舍是引擎的生命周期：跟页面走。ReadingPage 的 aboutToAppear 里 createEngine，aboutToDisappear 里 shutdown——不在全局常驻。理由是朗读是低频场景（用户一天点开一两次），常驻引擎白白占资源；页面级创建的启动延迟在可接受范围。
三、状态机：三种文案背后的三件事
页面上有个 @State speechStatus，用户看到的文案是"点击朗读，收听当前文章 → 正在朗读 → 已停止朗读"，出错时显示"朗读不可用：errorCode"。这三态背后是三件必须处理的事：
开始：speakCurrentSection(article) 把当前小节送进引擎。按小节切分而不是整篇送入——整篇长文一次性合成，中途停止和续播都难做；按小节粒度，"读下一段"就是换个入参再 speak。
完成回调：onComplete(response) 里把状态归位。回调驱动是 TTS 的关键——不能假设 speak 之后朗读"应该"结束了，只有回调说了算。
错误回调：错误码直接透给用户（朗读不可用：errorCode）。TTS 在部分设备/语言包缺失时会失败，与其静默失败让用户以为按钮坏了，不如把错误码亮出来——至少知道是能力不可用而不是应用 bug。
四、和菜谱场景的两个细节
朗读起点跟随阅读进度。用户滚到哪一段，点击朗读就从那一段开始——用当前可见小节作 speakCurrentSection 的入参，而不是死板的从头读。
朗读入口放在首页而不是文章页内。首页卡片显示第一篇文章标题，点击直达朗读页。这个入口设计来自场景推演：用户站在灶台前打开应用时，最短路径是"一个动作开始听"，任何多一层的选择都会让做饭的人烦。
五、总结
Core Speech Kit 的接入本身不难（createEngine → speak → 回调三件套），难的是把能力嵌进真实场景：引擎生命周期跟页面、按小节切分合成、三态状态机、错误码亮给用户。当用户手上沾着面粉还能"读完"一篇健康文章时，这个功能才算真的可用。
参考资料
- Core Speech Kit 文档（textToSpeech）
- 工程源码：ReadingPage.ets
#鸿蒙 #HarmonyOS 7（API 26）
