摘要：本文介绍一个运行在 ESP32 上的小型应用平台。平台将稳定的系统能力与经常变化的应用功能分开，通过 WebAssembly 运行应用，并使用在线静态目录分发应用包。本文先讲整体思路、架构和当前进度，具体实现将在后续文章中逐步拆解。

一、问题从“每次都要重新烧录”开始

大多数 ESP32 项目采用的是整包固件模式：界面、网络、传感器驱动和业务功能一起编译，最后生成一份固件并烧录到开发板。

这种方式对于功能明确、后续变化不大的设备非常合适。它直接、稳定，也容易调试。

问题出现在功能需要持续扩展的时候。假设同一块硬件今天是触摸画板，明天要加入小游戏，后天又要增加信息看板。按照普通做法，每次增加功能都需要修改完整工程、重新编译，再烧录整份固件。

随着项目变大，会逐渐遇到几个问题：

• 系统能力与业务功能紧密耦合；
• 不同设备功能组合不同，固件版本越来越多；
• 小功能更新也要替换整套固件；
• 某个业务功能出错，可能影响整个设备；
• 设备交付后，升级和维护成本升高。

因此，我开始尝试把“稳定的系统”和“经常变化的应用”拆开。

二、项目目标：让应用脱离整份固件

项目暂定名为 ESP32 Mini App Platform。

它的目标不是把 ESP32 变成手机，而是在资源有限的微控制器上建立一种“小系统 + 小应用”的运行方式。

系统固件负责比较稳定的公共能力：

• 屏幕与触摸输入；
• Wi-Fi 和网络请求；
• 文件与键值存储；
• 应用安装、启动、停止和删除；
• 权限检查；
• 系统升级与异常恢复。

小应用负责具体功能，例如画板、小游戏和信息展示。应用可以单独安装、更新和删除，不需要跟随整套系统固件一起重新烧录。

可以用一句话概括：

系统提供稳定的运行环境，应用负责不断变化的具体功能。

三、为什么它不只是一个“应用启动器”

在屏幕上放几个图标，再根据点击跳转到不同页面，并不等于真正的应用平台。

一个完整的平台还需要回答以下问题：

1. 应用从哪里获取？
2. 应用包如何描述名称、版本、入口和图标？
3. 下载中断或文件损坏时怎样处理？
4. 应用怎样使用屏幕、触摸、网络和存储？
5. 不同应用的数据如何隔离？
6. 应用异常后，系统能否继续运行？
7. 平台自身怎样升级，升级失败如何恢复？

这些问题决定了系统必须具备应用格式、运行环境、设备接口、存储结构、生命周期管理和更新机制，而不是简单地在一个大工程中切换界面。

四、三个演示应用验证三种能力

目前平台准备了三个演示应用。

4.1 Hello：验证加载链路

Hello 负责验证平台能否发现应用、解析应用信息、创建运行环境、启动程序并把结果显示到屏幕上。

它相当于平台版本的“点亮 LED”。功能很简单，但可以快速判断最基本的应用加载链路是否正常。

4.2 Touch Paint：验证设备能力调用

Touch Paint 是一个触摸画板。应用接收触摸坐标，再调用平台提供的绘图接口显示轨迹。

应用本身不直接操作屏幕和触摸驱动，而是通过系统暴露的受控接口获得对应能力。这为后续权限限制和硬件差异适配留下了空间。

4.3 Snake：验证持续运行和状态保存

Snake 需要处理输入、更新游戏状态、刷新画面，并保存最高分等应用数据。

它验证了比“一次加载并显示内容”更完整的运行过程：持续事件循环、状态更新和独立数据空间。

三个应用的意义不在功能复杂度，而在于同一套系统可以装载三种不同应用，不需要为每种功能准备一份独立固件。

五、整体架构：应用层、平台层、云端层

平台分为三层。

┌──────────────────────────────────┐
│ 应用层：Hello / Touch Paint / Snake │
│ 统一应用格式：WebAssembly           │
└────────────────┬─────────────────┘
                 │ 系统 API
┌────────────────▼─────────────────┐
│ 平台层：应用管理、运行时、权限、存储  │
│        屏幕、触摸、网络、系统升级     │
└────────────────┬─────────────────┘
                 │ HTTPS
┌────────────────▼─────────────────┐
│ 云端层：应用目录、应用包、更新文件     │
│        当前使用腾讯云 COS            │
└──────────────────────────────────┘

5.1 应用层

应用完成后会被转换为统一的小型程序格式。当前选择 WebAssembly（WASM） 作为应用载体。

这里可以先把 WASM 理解为应用与硬件之间的一层通用格式。应用不能随意控制整块开发板，需要屏幕、触摸或存储时，要调用平台提供的接口。

WASM 的运行机制、内存模型和 ESP32 上的资源开销将在后续文章单独讨论。

5.2 平台层

平台层常驻 ESP32，负责：

• 扫描和登记本地应用；
• 校验、安装、启动、停止和删除应用；
• 创建 WASM 运行环境；
• 向应用提供有限的系统 API；
• 管理应用数据目录和运行状态；
• 提供系统界面、网络与升级能力。

这层的核心目标是建立边界：应用可以使用被允许的能力，但不应该轻易破坏系统或其他应用。

5.3 云端层

当前使用腾讯云 COS 保存静态应用目录、应用安装包和系统更新文件。

设备通过 HTTPS 获取目录文件，根据版本和下载地址找到目标应用包，再完成下载和安装。

第一版采用静态目录，是为了以较低复杂度跑通完整链路。账号系统、后台管理和图形化应用商店会在核心流程稳定以后再考虑。

六、应用安装流程

一个应用从开发完成到出现在 ESP32 上，大致经历以下步骤：

1. 开发者编写应用功能；
2. 将应用转换为平台支持的格式；
3. 加入名称、版本、入口和图标等元数据并打包；
4. 把应用包和目录文件上传到在线存储；
5. ESP32 获取最新目录；
6. 用户选择应用后，设备下载对应文件；
7. 平台检查文件完整性并完成安装；
8. 应用进入本地列表，等待用户启动。

从用户角度看，它接近“选择并安装一个应用”；从系统内部看，则是一组下载、检查、登记和启动操作。

关键变化在于：更新对象从整套固件变成了单个应用。

七、这种架构带来了什么

7.1 一套硬件支持不同功能组合

设备可以根据实际需求安装不同应用，减少为每种用途维护不同固件的压力。

7.2 系统与应用分别升级

增加一个小游戏，不需要同时修改触摸驱动和网络模块。系统升级时，也可以尽量保留已有应用及其数据。

7.3 设备交付后仍能增加功能

设备不必每次接回电脑重新烧录，可以通过网络获得新的应用和功能。

7.4 软件边界更清晰

系统负责稳定和资源管理，应用专注具体功能。清楚的边界有利于测试、维护和长期演进。

八、当前进度与后续计划

目前已经形成的部分包括：

• Hello、Touch Paint 和 Snake 三个演示应用；
• 应用安装、启动和本地管理基础链路；
• 腾讯云 COS 在线静态应用目录；
• 系统更新与失败回滚基础框架。

项目仍在持续完善。应用签名、细粒度权限、图形化应用商店、应用开发工具和远程设备管理尚未完全稳定，本文不展开这些部分，后续完成实机验证后再分别记录。

计划中的技术拆解包括：

1. WebAssembly 是什么，为什么适合做小应用载体；
2. ESP32 上的 WASM 运行时如何工作；
3. 应用包、清单文件和在线目录如何设计；
4. 系统 API 与设备能力怎样暴露给应用；
5. 应用存储、权限和隔离如何实现；
6. OTA 更新与失败回滚怎样保证设备可恢复。

九、结语

这个项目真正重要的变化，不是 ESP32 上多了三个 Demo，而是应用不再等同于整份固件。

当系统和具体功能拥有各自的边界，一块已经交付的设备也开始具备持续增加能力的可能。

下一篇将从 WebAssembly 开始，介绍它是什么、为什么不只属于浏览器，以及为什么选择它作为 ESP32 小应用的运行方式。