先说明范围
这篇是可行性分析，不是设备适配实战。作者没有在 LiteOS、OpenHarmony mini 或 small 设备上编译、运行或测量 Flutter；本文不提供可直接使用的 Embedder 代码、内存阈值或性能数据。
OpenHarmony 官方资料区分 mini、small 和 standard 系统类型。它们面向的设备形态和资源档位不同，文档给出的参考最低内存分别为 128 KiB、1 MiB 和 128 MiB。这个分类参考值不是 Flutter 的最低运行内存，也不能直接推导某个 LiteOS 产品能够运行 Flutter。
LiteOS、OpenHarmony 系统类型和 HarmonyOS 商用产品不是可互换的名称。适配评估应先查明具体芯片、内核/系统发行版、API、内存配置和设备 SDK，再谈运行时支持。
当前 Flutter OHOS 社区工具链的边界
OpenHarmony SIG 的 Flutter 社区仓库提供面向 OHOS 工程的 Flutter 工具链、HAP 构建和 Samples。其 README 描述的是对应分支支持的开发环境和平台产物；不能据此推断它已覆盖所有 mini/small 系统、Cortex-M 板卡或 LiteOS 产品。
因此，当前可得出的结论是：仅凭“OpenHarmony 支持轻量设备”或“Flutter 有 OHOS 适配仓”，不足以声称 Flutter LiteOS 已经适配。应在所选目标的官方支持矩阵中找到明确设备、系统和 SDK 依据；没有依据时把方案标记为待验证。
如果要评估自研移植，需要回答的问题
Flutter 在新平台运行不仅需要渲染代码。至少要评估以下组成部分是否存在、由谁维护，以及对应资源预算：
| 领域 | 需要核对的问题 |
|---|---|
| Dart Runtime / Engine | 目标 CPU、ABI 和系统是否在所选 Flutter Engine 分支的支持范围内？ |
| Embedder | 是否具备线程调度、时钟、任务投递、窗口与平台生命周期实现？ |
| 渲染 | 目标设备是否提供兼容的 GPU / 图形接口；若使用软件渲染，CPU 和帧缓冲是否满足产品需求？ |
| 输入与文本 | 触摸/按键、字体、文本输入、剪贴板和无障碍能力由哪一层提供？ |
| 平台通道与插件 | 每个插件是否有该目标系统的实现，还是需要替换或自行维护？ |
| 资源预算 | Engine、Dart AOT 产物、图片纹理、字体和应用代码的实测峰值分别是多少？ |
| 工程与更新 | 编译链、签名、升级、崩溃诊断和安全更新由什么工具支持？ |
如果没有可运行的 Engine/Embedder 和目标设备资料，示例性的 GN 参数或 C++ TaskRunner 片段不能构成可编译的 Flutter 方案。本文旧稿中的引擎裁剪、TaskRunner、Skia Framebuffer 和设备验收代码已经移除，避免被误认为可复制实现。
方案选择
- 需求是轻量界面、传感器和本地控制：先核对目标 OpenHarmony 发行版提供的原生应用框架和示例。
- 目标必须复用 Flutter：先寻找该具体设备和系统 API 的社区/厂商适配仓、维护者和可验证的构建记录。
- 找不到匹配的支持证据：先做小规模移植评估，记录每个 Engine/Embedder 子系统的状态，再决定预算和路线；不要直接承诺 Flutter 可用。
- 产品量产依赖持续维护：将社区分支维护、系统升级适配、测试设备和安全更新成本纳入决策。
鸿蒙化系列目录
本文是系列中的轻量设备可行性分析篇。前四篇讨论 OpenHarmony/HarmonyOS 相关生态和社区 Flutter 工具链；它们不意味着本篇的 LiteOS/mini/small 方案已经实机验证。