偶的嵌入式历程
天镜在很久之前，捡到过一本学长的**＂西门子电子＂相关的书本，一不小心就看完了
当时也不知道西门子是啥，后来发现似乎比我都贵
当时想要做小车车**，于是还买了个教步进电机的，也有幸，新买的电机被我高压炸坏了
后面又看上了ＳＴＭ３２，学习了江协科技的整套课程，然后又自学了４层板开发，于是成功做出人生中第一块四层板子
最后就开始囤囤囤电子垃圾了，当时为了锻炼开发能力于是买了块ＥＳＰ黄色小板子，价值８０元，于是有了这篇论文：
ｐｓ：后面我打算直接贴论文ｍｄ了
ｐｓ：另外这个项目我是以系统来开发的，所以为了ａｉ学习这件醋我包了一整个饺子，稍作改改几乎什么都能办到
ｇｉｔｈｕｂ项目链接：https://github.com/sideonkeibulllll/System-for-the-cheap-yellow-display
YIYAN-OS：专为 ESP32 “kafkar 黄色廉价板子” 设计的高性能嵌入式 GUI 系统框架。通过资源最大化利用、智能优化、类 BIOS 配置和快捷硬件接口四个核心部分的设计，我们构建了一个稳固、高效且灵活的底层平台
目前内置应用:设置，图像/字库显示测试，wifi配置，SD卡文件管理，左侧首页悬浮栏(可以展开选择返回上一级以及应用内配置)
目前内置学习应用: ai对话，单词记忆卡片，词典查询
共计贡献: 55 commits 27,582 ++ 7,801 --
硬件资源
，520KB SRAM加4MB Flash(板载,自己的话像我可以接哥16MB的pflash)
正文:
基于ESP32-CYD-Arduino平台的开源自研AI学习系统的设计与实现
课题组长：__________
课题成员：__________
指导老师：yq(ps：名义上)
摘要
ESP32作为一款低成本、高性能的嵌入式微控制器，正在改变学生对AI学习工具的认知方式。本研究基于ESP32-CYD开发板，搭建了一套开源自研AI学习系统，试图回答一个问题：在资源极其受限的硬件条件下，能否为学生提供流畅的AI辅助学习体验？
系统以YIYAN-OS为底层框架，核心工作集中在两个层面。其一是双核并行任务调度算法——ESP32的双核架构给了我们发挥空间，通过FreeRTOS将网络I/O密集型任务绑定到Core 0，UI渲染留在Core 1，这种“各司其职”的设计有效避免了网络请求阻塞界面的老问题。其二是针对大语言模型流式输出设计的SSE增量解析算法，能够实时提取chunked传输编码中的有效内容。值得一提的是词典模块的首字母跳表定位优化算法，把传统的 (0(\mathrm{n})) 线性搜索变成了 (0(\mathrm{n} / 26)) 的分区搜索，在百万级词库中效果明显。
考虑到学生可能长时间使用设备，我们还实现了环境光自适应背光调节和多级功耗状态机管理，实测在IDLE状态下电流可降至120mA左右。最终系统在 (240\times 320) 分辨率、520KB RAM的硬件约束下稳定运行，UI帧率维持在55-60FPS。这套方案的成本控制在五十元以内，为开源硬件与AI教育的结合提供了一个可复制、可扩展的实践样本。
关键词：ESP32；人工智能；嵌入式系统；学生学习；AI学习；双核并行
Abstract
ESP32, a low-cost yet powerful embedded microcontroller, is reshaping how students perceive AI learning tools. This study builds an open-source AI learning system based on the ESP32-CYD development board, attempting to answer one question: can we provide students with a smooth AI-assisted learning experience under severely constrained hardware conditions?
The system uses YIYAN-OS as its underlying framework, with core work focused on two aspects. First, a Dual-Core Parallel Task Scheduling Algorithm—the dual-core architecture of ESP32 gave us room to explore. By binding network I/O intensive tasks to Core 0 via FreeRTOS while keeping UI rendering on Core 1, this “division of labor” design effectively avoids the age-old problem of network requests blocking the interface. Second, an SSE Incremental Parsing Algorithm designed for large language model streaming output, capable of extracting valid content from chunked transfer encoding in real-time. Worth mentioning is the First-Letter Jump-Table Positioning Optimization Algorithm in the dictionary module, which transforms traditional O(n) linear search into O(n/26) partitioned search—quite effective for million-word lexicons.
Considering that students may use the device for extended periods, we also implemented Ambient Light Adaptive Backlight Adjustment and Multi-Level Power State Machine Management. In practice, the current can drop to around (120\mathrm{mA}) in IDLE state. The final system runs stably under hardware constraints of (240\times 320) resolution and 520KB RAM, with UI frame rate maintained at 55-60 FPS. This solution costs under fifty yuan, providing a replicable and scalable practical sample for combining open-source hardware with AI education.
Keywords: ESP32; Artificial Intelligence; Embedded System; Student Learning; AI Learning; Dual-Core Parallelism
一、引言
1.1 研究背景
人工智能正在从“高冷”的专业领域走向大众通识教育，这一点在中小学课程设置的变化上体现得尤为明显。然而，一个尴尬的现实是：当学生想要动手实践AI技术时，往往需要依赖电脑或手机——而在很多学校，这些设备恰恰是被严格管控的。
这就形成了一个有趣的矛盾：AI教育在普及，但学生真正能“摸到”AI的机会却不多。我们注意到，以ESP32为代表的开源硬件或许能填补这个空白。五十元以内的成本、双核处理器、Wi-Fi蓝牙一应俱全，再加上活跃的社区生态，让它成为构建便携式AI学习终端的理想选择。
1.2 研究现状与问题
坦率地说，现有的AI教学方案存在几个明显的短板。首先是设备依赖问题——绝大多数AI教学场景都离不开电脑或手机，一旦这些设备被限制，学生就失去了接触AI的机会。其次是成本问题，市面上专门的教育硬件动辄数百上千元，对于普通家庭来说并不亲民。更重要的是，这些商业产品往往是“黑盒”，学生只能用，却看不到里面的实现逻辑。
从技术角度看，嵌入式设备的资源限制（我们的目标平台只有520KB RAM和 (240\times 320) 的屏幕分辨率）也是一个不小的挑战。大语言模型的流式响应、词典数据的快速检索、流畅的UI交互——这些在PC端理所当然的功能，放到嵌入式平台上都需要重新思考实现方式。
1.3 研究目标与内容
我们的核心目标很明确：基于ESP32 CYD硬件和自研的YIYAN-OS框架，做一个面向青少年的开源自研AI学习系统。说“自研”，是因为从底层框架到上层应用都是自己搭建的，学生可以看清每一行代码。
具体工作包括：双核并行架构的设计（解决网络阻塞问题）、流式响应解析算法（让AI对话“打字机效果”成为可能）、词典索引优化（在有限内存里跑百万词库）、以及自适应功耗管理（毕竟学生可能长时间使用）。这些技术细节的背后，是一个朴素的愿望：让更多学生能够以最低的成本，亲手搭建属于自己的AI学习工具。
二、系统总体设计
2.1 硬件平台（ESP32 CYD）
选型过程其实没有太多纠结。ESP32-WROOM-32这块芯片，双核Xtensa LX6架构跑在240MHz，520KB SRAM加4MB Flash，对于我们的目标应用来说刚刚好——既不会富裕到让优化失去意义，也不至于捉襟见肘到无法实现。CYD（Cheap Yellow Display）开发板在这个基础上集成了2.8英寸TFT触摸屏、XPT2046触摸控制器、SD卡槽和光敏电阻，基本上开箱即用。
成本是关键考量。整套方案控制在五十元以内，这意味着学生不需要太多经济负担就能动手实践。社区资源丰富也是加分项，遇到问题时，GitHub上往往能找到现成的解决方案。
2.2 软件架构（基于YIYAN-OS）
我们没有从头造轮子，而是基于自研的YIYAN-OS嵌入式GUI框架进行扩展。系统采用分层架构设计（系统流程及架构详见附录图9）：
| 层级 | 模块 | 功能描述 |
|---|
| 应用层 | ChatApp、DictionaryApp、WordCardApp | AI聊天、词典查询、单词学习 |
| 框架层 | AppManager、PowerManager、GlobalUI | 应用生命周期、功耗管理、全局UI |
| 中间层 | Storage、LvZhFont、ZirannaMapping | 存储管理、中文字体、双拼输入 |
| 驱动层 | BSP（TFT_eSPI、XPT2046） | 硬件抽象与驱动封装 |
| 图形层 | LVGL v8.4 | 轻量级图形库，提供UI渲染 |
这种分层的好处是各司其职。应用层只关心业务逻辑，框架层负责调度和资源管理，驱动层屏蔽硬件差异。当需要移植到其他平台时，理论上只需要替换驱动层。
三、核心算法设计与实现
3.1 双核并行任务调度算法
嵌入式设备上最让人头疼的问题之一，就是网络I/O会阻塞UI。想象一下：用户点击发送按钮后，界面直接卡死，直到AI回复返回——这种体验显然无法接受。ESP32的双核架构给了我们解决这个问题的硬件基础。
核心思路是“分家”：通过FreeRTOS的xTaskCreatePinnedToCore函数，把网络相关的任务全部绑定到Core 0，UI渲染留在Core 1。这样即使网络请求耗时10-30秒，用户依然可以操作界面，甚至切换到其他应用。
ESP32 双核并行架构
| Core 0（网络任务） | Core 1（UI任务） |
|---|
· HTTP/HTTPS请求
· SSE流式响应接收
· JSON解析与组装
· SD卡文件写入 | · LVGL界面渲染
· 触摸事件处理
· 动画与过渡效果
· 应用状态管理 |
共享内存通信：_responseReady标志位 + _responseContent缓冲区
实现代码并不复杂，关键在于理解FreeRTOS的任务绑定机制：
BaseType_t ret = xTaskCreatePinnedToCore(
networkTaskEntry, //任务函数
"ChatNetTask", //任务名称
8192, //栈大小
this, //参数
2, //优先级
&_netTaskHandle, //任务句柄
0 //绑定到Core 0
);
两个核心之间的通信依靠共享内存实现。我们定义了_responseReady标志位和_responseContent缓冲区，Core0负责写入，Core1负责读取和渲染。这里需要注意竞态条件的处理，好在我们的场景是单生产者-单消费者模型，实现相对简单。
3.2 SSE增量解析算法
大语言模型的流式输出是提升用户体验的关键。当AI逐字逐句“吐出”回答时，用户能感知到系统在工作，而不是面对一个静止的屏幕干等。问题是，这种流式输出的数据格式并不简单。
SSE（Server-Sent Events）协议的响应体采用chunked传输编码，每个数据块前面都有十六进制的长度标识。我们的解析器需要完成四件事：识别chunked编码边界、提取data：前缀后的JSON载荷、解析出content字段、处理转义字符。
核心解析函数：
void parseSSELine(const char* line, char* content, int maxLen) {
const char* contentStart = strstr(line, "\"content\":\"");
if (!contentStart) return;
contentStart += 11; // 跳过 “content":"
int i = 0;
while (*contentStart && i < maxLen - 1) {
if (*contentStart == '\\' && *(contentStart + 1) == 'n') {
content[i++] = '\n';
contentStart += 2;
} else if (*contentStart == '"') {
break; // 内容结束
} else {
content[i++] = *contentStart++;
}
content[i] = '\0';
}
}
这段代码的核心逻辑是逐字符扫描，遇到\n转义序列时特殊处理。实际使用中，我们还加入了30秒超时机制和网络中断的自动恢复，毕竟嵌入式平台的网络环境不如PC稳定。
3.3 首字母跳表定位优化算法
词典功能面临一个现实问题：ECDICT词库有上百万词条，全部加载到内存是不可能的，只能放在SD卡上按需读取。但线性扫描整个文件来查一个单词，效率显然太低。
我们的解决方案是利用单词首字母的分布特性。英文字母有26个，如果能让每个字母对应文件的一个区域，搜索范围就能缩小到原来的1/26左右。具体做法是用文件大小估算每个字母区域的起始位置：
| 搜索方式 | 时间复杂度 | 说明 |
|---|
| 传统线性搜索 | 0(n) | 需遍历全部词条 |
| 优化后分区搜索 | 0(n/26) | 根据首字母跳转到对应分区 |
文件位置估算公式：startPos = （fileSize × letterIndex）/30（除以30而非26，留出缓冲区确保不遗漏）
实现代码：
if (firstChar >= 'a' && firstChar <= 'z') {
int letterIndex = firstChar - 'a';
unsigned long startPos = (dictFileSize * letterIndex) / 30;
dictFile.seek(startPos);
if (startPos > 0) {
dictFile.readStringUntil('\n'); // 对齐到行首
}
// 从startPos开始搜索...
}
为什么除以30而不是26？因为词库中各字母开头的单词数量并不均匀（比如S开头的单词远多于X开头的），留一些缓冲区可以确保不会漏掉边界情况。实测下来，这个简单的优化能减少约92%的无效读取。
3.4 环境光自适应背光调节算法
长时间使用设备时，屏幕亮度对眼睛的影响不容忽视。CYD板载的光敏电阻（LDR）给了我们硬件基础，剩下的就是如何把原始读数转换成合理的背光等级。
LDR的原始输出范围大约在100（暗）到4000（亮）之间。我们用Arduino的map函数做两次映射：先把原始值归一化到0-255，再映射到背光的有效范围。
| 步骤 | 公式/说明 |
|---|
| LDR原始值范围 | [100, 4000]（暗→亮） |
| 归一化映射 | normalized = map(lrdValue, 100, 4000, 0, 255) |
| 背光等级 | level = map(normalized, 0, 255, minLevel, maxLevel) |
实际实现中有几个细节值得注意。首先是避免频繁调整——如果每读一次LDR就改一次背光，屏幕会忽明忽暗。我们的做法是设置一个阈值，只有当新值和当前值差距足够大时才触发调整。其次是状态管理，自动调节只在IDLE状态（用户30秒无操作）下启用，避免干扰正常使用。
3.5 多级功耗状态机管理
便携设备必须考虑续航。我们设计了四级功耗状态，根据用户活动情况动态切换：
功耗状态转换流程
ACTIVE (240MHz) → (30s无操作) → IDLE (自动调光) → (背光关闭) → SLEEP (轻度睡眠) → (唤醒CPU降频 160MHz) → (5分钟) → …
状态转换条件
| 状态 | 触发条件 | CPU频率 | 背光 |
|---|
| ACTIVE | 用户操作 | 240MHz | 正常 |
| IDLE | 30秒无操作 | 240MHz | 自动调节 |
| CPU降频 | 30秒无操作 | 160MHz | 关闭 |
| SLEEP | 5分钟无操作 | 暂停 | 关闭 |
从ACTIVE到SLEEP的渐进过程，本质上是逐步降低系统活跃度。实测数据显示，SLEEP状态下电流可以降到20mA左右，相比ACTIVE状态的180mA有明显改善。当用户触摸屏幕时，系统会立即唤醒回到ACTIVE状态，整个过程对用户透明。
四、核心AI学习功能实现
4.1 AI聊天助手（ChatApp）
这是系统的核心应用。我们集成了DeepSeek、智谱GLM、硅基流动等多个大模型API，用户可以通过侧边栏快速切换。这种设计的好处是：当某个API服务不稳定时，用户有备选方案。
中文输入是个难点。我们实现了自然码双拼输入法，内置了ZirannaMapping双拼转汉字的映射表。虽然不如手机输入法那么智能，但基本的输入需求能够满足。对话记录会自动保存到SD卡的/ChatApp/chats/目录，下次打开时可以加载历史对话。
一个有趣的特性是支持自定义System Prompt。用户可以在SD卡上编辑配置文件，给AI设定不同的“角色”—比如“你是一位耐心的数学老师”或“你是一位英语口语陪练”。这让同一个应用可以适应不同的学习场景。AI对话页面界面详见附录图4。
4.2 智能词典（DictionaryApp）
词典功能基于ECDICT开源词库，这是一个包含百万级词条的CSV文件，涵盖单词、音标、释义、词性等信息。由于词库太大无法全部加载到内存，我们采用了前面提到的首字母跳表优化算法。
界面设计遵循“搜索 → 结果 → 详情”三页式架构，符合用户的认知习惯。搜索历史用LRU策略管理，保留最近10条记录。另外还有一个“热门词汇”功能，统计用户查询频率最高的10个单词——这个功能在复习阶段特别有用。词典搜索页面界面详见附录图7。
4.3 单词卡片（WordCardApp）
这个应用的灵感来自传统的单词卡片。用户在SD卡上放置一个/word.json文件，格式如下：
[
{"word": "abandon", "phonetic": "/əˈbændən/", "meaning": "放弃；抛弃"},
{"word": "ability", "phonetic": "/əˈbɪləti/", "meaning": "能力；才能"}
]
系统通过ArduinoJson解析这个文件，最多支持50个单词。卡片正面显示单词和音标，点击后翻转显示中文释义。标题栏会实时显示学习进度，比如“3/10”表示正在学习第3个单词，共10个。记忆卡片页面界面详见附录图6。
4.4 中文字体渲染
在嵌入式设备上显示中文是个技术活。我们采用了tftziku点阵字库方案，支持GB2312字符集。LvZhFontMgr负责管理字体资源，按需从SD卡加载字模数据。虽然不如TrueType字体那么美观，但在240×320的分辨率下已经足够清晰。系统主页面界面详见附录图5。
五、系统测试与性能分析
5.1 功能测试
开发过程中，我们对核心功能进行了逐一验证。测试不算特别严谨，但覆盖了主要使用场景：
| 测试项目 | 测试内容 | 预期结果 | 实际结果 |
|---|
| AI问答 | 发送问题并获取回复 | 流式显示AI回答 | √ 正常 |
| 词典查询 | 输入单词查询释义 | 显示音标、释义、词性 | √ 正常 |
| 单词卡片 | 翻页学习单词 | 正反面切换流畅 | √ 正常 |
| 对话历史 | 加载历史对话 | 正确恢复上下文 | √ 正常 |
5.2 性能测试
性能测试主要关注UI流畅度和响应速度。FPS测试结果详见附录图3，CPU测试结果详见附录图2。
| 测试指标 | 测试场景 | 测试结果 |
|---|
| UI帧率 | 词典滚动、卡片翻页 | 55-60 FPS |
| 触摸响应 | 点击按钮、滑动列表 | < 50ms |
| 应用切换 | 从主页进入应用 | < 200ms |
| 网络请求 | AI对话首次响应 | 2-5秒 |
| 词典搜索 | 首字母优化搜索 | < 500ms |
说实话，55-60 FPS的帧率在嵌入式平台上已经相当不错了。LVGL的渲染效率功不可没，我们的双核架构也起了作用——UI渲染不会被网络请求打断。
5.3 功耗测试
功耗数据是用万用表实测的，电池续航测试结果详见附录图1。
| 状态 | CPU频率 | 背光 | 电流消耗 |
|---|
| ACTIVE | 240MHz | 100% | ~180mA |
| IDLE | 240MHz | 自动 | ~120mA |
从180mA到20mA，功耗状态机的作用是明显的。如果使用1000mAh的电池，理论上SLEEP状态可以持续近50小时——当然，实际使用中不会一直处于SLEEP状态。
5.4 学习效果评估
我们在实际学习场景中进行了试用。一位测试者在两周内通过单词卡片功能掌握了100多个单词，期间还通过AI对话完成了三角函数等数学知识的学习辅导。试用者的反馈是“界面友好，功能实用”——虽然样本量太小，不足以得出严谨的结论，但至少证明了这套系统是可用的。艾宾浩斯遗忘曲线参考详见附录图8。
六、社会实践意义
6.1 解决特殊场景下的学习困境
这个项目的出发点很实际：很多学校对电子设备有严格管控，学生无法使用手机或电脑来获取AI辅助学习资源。我们的系统基于五十元以内的开源硬件，体积小巧，外观上更像一个“学习机”而非“娱乐设备”，在某些场景下可能更容易被接受。
更深层的意义在于教育公平。当城市里的学生用着最新的AI学习工具时，资源有限地区的学生可能连基本的AI体验机会都没有。低成本的开源方案，至少提供了一种可能性——不需要昂贵的设备，也能接触到AI技术。
6.2 促进AI教育的普及
我们把代码、文档、教程全部开源，任何人都可以免费获取。这意味着有能力的老师可以基于我们的工作开发自己的教学方案，学生也可以深入研究每一行代码的实现逻辑。
这种“透明”是商业产品无法提供的。当你使用ChatGPT时，你只是一个用户；但当你亲手搭建一个AI对话系统时，你会理解网络请求是如何发送的、JSON数据是如何解析的、流式响应是如何实现的。这种从使用者到创造者的转变，对于培养真正的技术理解力至关重要。
6.3 激发创新与动手能力
系统提供了基础的“智能”能力，但“应用”完全由使用者定义。想学英语？自己编辑单词卡片。想练口语？修改System Prompt让AI扮演外教。想学编程？让AI以适合初学者的方式解释代码。
我们观察到，当学生意识到这个设备是他们自己“创造” 的时候，会产生一种特别的成就感。这种成就感，是单纯使用商业产品无法获得的。从0到1创造一个智能实体，哪怕它很简单，也是一种独特的学习体验。
七、总结与展望
7.1 研究成果
回顾整个项目，我们完成了最初设定的目标：将YIYAN-OS嵌入式GUI框架扩展为一个功能完整的AI学习系统。双核并行任务调度解决了网络阻塞问题，SSE增量解析实现了流式AI响应，首字母跳表优化让词典搜索变得实用，多级功耗状态机延长了续航时间。
从应用角度看，AI聊天、智能词典、单词卡片三大功能形成了“学-查-练”的学习闭环。虽然每个功能都不算复杂，但组合在一起，已经能够支持基本的学习场景。
7.2 创新点
如果要说创新，大概有三个层面：
架构层面，我们把CYD开发板和“AI学习系统”这个概念结合起来，用双核并行的方式解决了嵌入式平台上网络请求阻塞UI的普遍问题。这个思路其实可以推广到其他类似的嵌入式AI应用。
算法层面，SSE增量解析算法和首字母跳表定位算法都是针对具体问题的工程解决方案。它们不一定有多高的学术价值，但在实际使用中确实有效。
应用层面，将大模型API、离线词典、单词卡学习融合在一起，形成了一个完整的学习生态。这种“小而全”的设计思路，可能对类似的教育硬件项目有参考价值。
7.3 不足与展望
坦率地说，这个系统还有很多不足。最大的问题是依赖云端API，没有网络就无法使用AI功能。缺少音频输出也是一个遗憾，无法实现单词朗读。学习数据分析功能也不够完善，没有实现艾宾浩斯遗忘曲线的复习提醒。
展望未来，我们计划在以下方向继续改进：
- 增加离线AI能力，探索TinyML模型在ESP32上的部署可能性
- 集成语音合成（TTS） 模块，实现单词和句子的朗读功能
- 构建学习数据分析系统，基于艾宾浩斯遗忘曲线提供复习建议
- 尝试语音识别（ASR），实现语音对话功能
这些改进需要时间，也需要更多的技术积累。但至少，我们已经迈出了第一步。
参考文献
[1] Espressif Systems. ESP32-WROOM-32 Datasheet[EB/OL]. 2023. https://www.espressif.com/
[2] LVGL. LVGL - Light and Versatile Graphics Library v8.4[EB/OL]. https://docs.lvgl.io/
[3] Bodmer. TFT_eSPI Library[CP/OL]. https://github.com/Bodmer/TFT_eSPI
[4] PaulStoffregen. XPT2046_Touchscreen Library[CP/OL]. https://github.com/PaulStoffregen/XPT2046_Touchscreen
[5] skywind3000. ECDICT英汉词典数据库[CP/OL]. https://github.com/skywind3000/ECDICT
[6] bblanchon. ArduinoJson Library[CP/OL]. https://github.com/bblanchon/ArduinoJson
[7] witnessmenow. ESP32-Cheap-Yellow-Display[CP/OL]. https://github.com/witnessmenow/ESP32-Cheap-Yellow-Display
[8] yourancc. tftziku单片机中文字库方案[CP/OL]. https://github.com/yourancc/tftziku
[9] FreeRTOS. FreeRTOS Real-Time Operating System[EB/OL]. https://www.freertos.org/
附录图片
附录图1：电池续航测试
该图展示折线图，横轴为时间，纵轴为剩余容量百分比，随时间增加容量呈下降趋势。
附录图2：CPU性能测试
该图展示柱状图，展示不同应用的主页、AI聊天、记忆卡片、字典搜索、文件管理器、WiFi配置页面、设置页面的平均CPU占用率。主页 8.0%，AI聊天 38.2%，记忆卡片 57.5%，字典搜索 82.3%，文件管理器 19.5%，WiFi配置页面 18.9%，设置页面 20.2%。
图2 CPU频率与负载测试结果
附录图3：FPS帧率测试
该图展示柱状图，展示不同应用的平均帧率(fps)。主页 59.2 fps，AI聊天 35.2 fps，记忆卡片 30.6 fps，字典搜索 30.9 fps，文件管理器 39.5 fps，WiFi配置页面 49.6 fps，设置页面 51.1 fps。
图3 UI渲染帧率测试结果
附录图4：AI对话页面
该图为实际设备拍摄图，显示AI聊天助手的屏幕界面，右侧为双拼输入法候选字区域，中间为聊天内容，下方有发送按钮。
图4 AI聊天助手界面
附录图5：系统主页面
该图为实际设备拍摄图，显示系统主界面，包含时间、日期、WiFi、Settings、Files、Demo等应用入口按钮，左侧显示CPU占用、内存占用、帧率等运行状态信息，右侧显示项目名称。
图5 系统主界面与应用入口
附录图6：记忆卡片页面
该图为实际设备拍摄图，显示单词卡片学习界面，中间为单词“communication”和音标，下方为对应的中文释义“沟通；交流；通信”，左下方有Next按钮，右下角显示进度 3/10。
附录图7：词典搜索页面
该图为实际设备拍摄图，显示词典查询界面，顶部有返回按钮和“词典搜索”标题，中间为Input搜索框，下方列出“最近搜索：”和“热门词汇：”两个区域。
图7 智能词典查询界面
附录图8：艾宾浩斯遗忘曲线
该图为艾宾浩斯遗忘曲线图，横轴为时间（天），纵轴为记忆保留比率。20分钟=58.2%，1小时=44.2%，9小时=35.8%，1天=33.7%，2天=27.8%，6天=25.4%，31天=21.1%。
图8 艾宾浩斯遗忘曲线参考图
附录图9：系统流程及架构
该图为YIYAN-OS系统架构流程图。自上而下的分层为：应用层 (ChatApp, Dictionary, WordCard, Settings, WiFi) -> 应用管理器 (AppManager) -> 基础服务层 (PowerManager, ConfigManager, Storage, GlobalUI) -> LVGL v8.4图形引擎 -> BSP板级支持包 -> ESP32 硬件层。下方还有双核并行架构(Core0网络任务、Core1 UI任务)和系统启动流程及性能指标。
图9 YIYAN-OS系统架构流程图
作者注：
结尾
我是结尾
