Flutter 和 OpenHarmony 这两个词放在一起懂的人已经知道分量了。说实话我在接触 OpenHarmony 生态之前一直觉得这类系统级适配离普通开发者很远直到自己动手把 言隅 这个灵感收集器完整跑通才发现这条路虽然坑不少但远比想象中值得走。这篇文章不做任何抽象的概念讲解就围绕我实际开发这款应用的全过程讲清楚 Flutter for OpenHarmony 到底能做什么、怎么落地、踩了哪些坑、最后产品长什么样。如果你正在纠结要不要入局 OpenHarmony 应用开发或者已经在用 Flutter 但不确定跨端适配的边界在哪这篇文章应该能给你一份足够真实的参考。言隅这个名字取自语言之隅定位很简单一个轻量、安静、有诗意的个人灵感收集器。不是备忘录也不是笔记软件而是专门用来捕捉那些转瞬即逝的念头——可能是半句突然冒出来的诗可能是地铁上看到的一个画面也可能是夜深人静时一个模糊的构想。和多数笔记类应用不同言隅不强调分类整理而是强调随手的记录和偶然的回顾让记录本身成为一件松弛的事情。1. 内容整体设计与思路拆解1.1 言隅的核心定位为什么是诗意灵感收集器而不是普通笔记应用市面上的笔记应用已经多到数不过来了Notion、Obsidian、语雀、flomo每个都有自己的用户群。但做言隅之前我仔细想过一个问题这类工具做得越强大使用门槛就越高而我们记录灵感时的心理状态恰恰是最轻的。灵感出现的时候往往就是几秒钟的事如果我还要想清楚放进哪个文件夹、加什么标签、用什么模板这个灵感估计已经跑没影了。所以言隅从一开始就确定了三个原则。第一是零门槛记录打开应用直接就是输入界面不需要任何前置操作一秒钟内能开始写字。第二是弱管理不强迫用户建目录、打标签标签系统完全可选搜索靠全文检索兜底。第三是强氛围感用字体、间距、色彩和动效营造出安静的文字空间让用户打开应用时先静下来再开始记录。这三点完全围绕灵感收集这个场景展开和普通笔记应用把效率放在第一位的思路有本质区别。这个定位直接影响了技术选型。不需要复杂的富文本编辑器不需要协同能力不需要云端同步核心功能就是文本记录、图片附加、标签、检索、随机回顾。这套功能用 Flutter 实现非常顺手因为 Flutter 在自定义 UI 和交互动效上的表达能力刚好是这类氛围感产品的刚需。同样一套逻辑如果采用 ArkTS 原生开发也能做但 UI 层的工作量会明显增加跨端复用更无从谈起。1.2 为什么选择 Flutter 来适配 OpenHarmony选 Flutter 作为言隅的跨端框架主要看中的是三条线。第一条是渲染一致性Flutter 自绘引擎不依赖系统原生控件同一套 Widget 树在不同平台上能保持几乎一致的渲染效果这意味着我在调试诗意感排版时只需要盯着一套视觉稿做不用分别调 Android 和 OHOS 两套控件细节。第二条是生态复用我在 Flutter 侧积累的组件、工具函数、状态管理方案都可以直接带过来学习成本集中在 OHOS 适配层而不是整个应用重写。第三条是单代码库维护后续如果要同步上架 Android 或 iOS 版本言隅主体代码不用动只需要处理平台差异。当然Flutter for OpenHarmony 目前还不是官方主推的一等公民方案社区版本依赖 OpenHarmony SDK 和 Flutter 引擎的持续适配。做这个选择之前我评估过风险如果做的是一个强依赖系统 API 的应用比如调用大量系统服务、复杂传感器那用底层适配不成熟的 Flutter 会很痛苦但言隅的核心能力集中在 UI 展示、本地存储和简单的文件读写上这些在 Flutter 的 OHOS 适配层已经有比较成熟的支撑风险可控。还有一个很实际的考虑OpenHarmony 生态当前处于应用爆发前夜原生应用开发资料在逐步丰富但 Flutter 作为一个成熟的跨端框架无论是社区讨论、问题排查还是第三方库积累都比新兴的原生方案更有优势。对独立开发者和小团队来说用更低的成本把产品形态验证跑通比一开始就押注某个特定技术栈更务实。1.3 言隅的技术架构与目录组织言隅的整体架构不复杂但每一层的选择都经过比较。状态管理采用 Riverpod选它而不是 Provider 的原因是言隅有多个异步数据流全文搜索、随机回顾、图片加载Riverpod 对异步状态和依赖注入的支持更干净写起来也更符合直觉。本地数据库存储方案直接影响了灵感记录应用的可靠性最终选了 Drift基于 SQLite 的 ORM。Drift 的响应式查询特性很适合做灵感列表的自动刷新并且它底层是 SQLiteOpenHarmony 的适配层对 SQLite 的支持比较成熟踩坑风险低。主题系统言隅的主题管理用自定义的 InheritedWidget 实现没有引入额外的包。因为诗意感本质上是一套精细的字体、颜色、间距组合我希望主题切换时的控制粒度足够细。目录结构按 feature-first 而不是 layer-first 组织每个功能模块record, explore, settings 等内部再拆 data / domain / presentation 三层这样单个功能的代码聚在一起改起来不需要跨目录来回跳。从最终开发体验看这套架构在 OpenHarmony 上的表现和 Android 上没有明显差异。真正的差异点在后面的适配章节细讲但至少从架构层面看Flutter 的跨端抽象做得足够好应用层代码不需要为 OHOS 单独做架构调整。2. 核心功能实现与诗意感交互背后的设计思考2.1 灵感记录流程零障碍输入是第一优先级记录流程是言隅的生命线所以我把所有精力都放在缩短从打开应用到完成记录的时间上。应用冷启动后直接进入主界面主界面中央是一个无边框的文本输入区轻触即输入。不需要先建文档不需要选分类输入的内容默认保存为一条普通灵感。如果用户想补充信息可以通过底部工具条加入图片、标签和心情标记但这些全部是可选操作不影响记录的即时性。实现上这个输入区不是普通的 TextField而是一个自绘的 CodeField 变体方案。原因在于 TextField 在 OHOS 适配层对文本缩放、字体特性比如连字、字间距的支持不完全可控而自绘输入区能精确控制光标颜色、间距、行高这些诗意感细节。具体做法是监听 RawKeyboard 事件维护一个字符串 buffer再通过 TextPainter 实时计算排版虽然工作量比直接调 TextField 大但换来的是对排版细节的绝对掌控。整个输入区按单行展开高度随内容自动增长输入超过一屏后上滚始终保持最新内容在视野内。图片附加走的是 image_picker 的 OHOS 适配分支调用系统相册选择图片后压缩到合适分辨率再存入本地存储。因为记录更强调文字本身图片在卡片上以缩略图形式展示点开才能看大图避免图片喧宾夺主。这个交互细节经过好几轮调整最终确认先文字后图片、图片从属于内容的展示层级最符合产品调性。2.2 检索与标签有弹性的管理不强迫分类前面说到言隅不做强分类管理但完全不管理也不行所以设计了一套弹性归类方案。用户在记录时可以在底部工具栏点选标签图标输入一个或多个标签比如写作灵感会议也可以完全不管。标签不是树状结构不做嵌套保持扁平。这样既保留了归类能力又不给用户增加操作负担。全文检索是整个应用最高频的功能之一我对检索体验的要求是边输入边出结果。Drift 的 LIKE 查询在数据量不大时性能很好但为了做到实时搜索我对每条记录建立了内部索引表把标题、正文、标签文本拼接成一个索引字符串搜索时对索引做 LIKE 匹配这样避免多字段联合查询带来的性能损耗。实测在存了 3000 多条灵感记录后输入关键词的搜索结果仍然能做到毫秒级返回完全满足随手找的场景。还有一个有诗意的功能是随机回顾。灵感记录不是为了存档而是为了在某一天重新遇见。言隅主界面下方有一枚小按钮点击后从全部记录中随机抽取一条以全屏卡片形式呈现。这个功能没有用简单的 random 函数——为了让回顾更有叙事感我先按日期分组再在随机选中的日期里随机选记录这样偶尔会翻出某个时间段的连续记录像打开时间胶囊一样。这纯粹是产品层面的小设计技术不复杂但给用户带来的情绪价值远超预期。2.3 诗意感 UI 的设计落地字体、间距、动效的具体处理诗意感这个词听起来虚落实起来全是细节。我在言隅里做了一套叫纸上的主题体系核心是把数字界面调得像纸面印刷一样安静。字体中文正文选用了思源宋体的开源版本标题用了一个定制的衬线变体西方文字用 Cormorant Garamond 系列中西文混排时通过独立的字体高度和基线调整保证视觉和谐。Flutter 的 fontFamilyFallback 机制在 OHOS 上表现稳定多字体回退没有出现问题。间距正文行高设置为 1.8 倍字号段间距是行间距的两倍标题与正文之间留出充足的空白让整个页面呼吸。在 Flutter 里通过自定义 ThemeData 的 textTheme 统一管理不逐页面写死数值。色彩默认是暖白纸色背景加炭黑文字暗色模式是深灰蓝背景加淡灰文字强调色是一种偏暗的朱砂红只在标签、日期等少量元素上出现整体饱和度刻意压低。动效页面切换使用淡入加轻微上移的过渡时长设为 400 毫秒比 Flutter 默认的 300 毫秒稍长让节奏更从容。灵感卡片的删除操作没有用 Material 的滑动删除而是做一个淡出然后缩小的动画匹配整体的安静气质。这些看似非技术的设计决策实际上对技术实现提出了不少要求。Flutter 在 OHOS 上的文本渲染对自定义字体的支持、Canvas 绘制的性能、动画帧率的稳定性都会直接影响最终观感。好在这部分 Flutter 的跨端一致性做得确实到位一套代码在 Android 模拟器和 OHOS 真机上的渲染结果几乎无差别。3. OpenHarmony 适配全过程从环境搭建到真机部署3.1 开发环境搭建的完整步骤与版本选择先说结论Flutter 开发 OpenHarmony 应用的成熟度已经到可以认真干活的阶段但前提是环境搭得对。官方推荐的路线是使用社区维护的 flutter_flutter 仓库的 ohos 分支版本配合 DevEco Studio 配置 OpenHarmony SDK。我在 macOS 上的完整搭建过程如下安装基础工具链确保 Xcode Command Line Tools、Git、Android SDKFlutter 本身依赖都就位。获取 Flutter SDK从社区维护仓库拉取 ohos 分支并切换到指定版本 tag。这一步不能用官方 flutter 稳定分支否则没有 ohos 平台支持。安装 OpenHarmony SDK通过 DevEco Studio 的 SDK Manager 下载包括ohos-sdk和openharmony工具链。之后在 shell 环境变量里配置OHOS_HOME指向 SDK 根目录并确保hdc命令OpenHarmony 的设备连接调试工具类似 ADB在当前 PATH 中。在 Flutter 侧配置local.properties写入ohos.sdk.dir指向 OHOS SDK 路径如果没有这一步创建项目时会提示找不到 SDK。运行flutter doctor -v确认 OHOS 工具链被正确识别如果有报错按提示补装对应组件。新建工程时选择flutter create --platforms ohos如果版本较新也可以用模板的.ohos目录初始化。提示版本匹配是最大的坑。Flutter ohos 分支的版本号和 OpenHarmony SDK 的版本号必须都在官方兼容表中否则编译时会出现莫名其妙的方法签名错误。比如我当时用的 Flutter 3.16.0-ohos 版本对应 OpenHarmony SDK 4.0 左右的 API版本对不上时编译报错信息根本不指向真实问题。整个环境搭建我前后花了一整天大部分时间浪费在路径没配全和版本不匹配上。如果你也在搭建建议把 DevEco Studio 自带的环境变量和 Flutter 的环境变量都输出检查一遍宁可多打几行echo也不要跳过检查。3.2 hdc 调试与真机部署RK3568 板子上的运行验证OpenHarmony 真机调试用 hdc 工具用法和 adb 很像。言隅主要在 RK3568 开发板上做了完整验证这块板子是 OpenHarmony 最常见的硬件平台之一性能介于中低端手机和嵌入式设备之间正好能验证 Flutter 应用在弱硬件上的表现。部署命令参考# 查看设备是否连接 hdc list targets # 查看设备系统版本对应热词中的 param get hdc shell param get const.product.name hdc shell param get const.product.version # 安装 HAP 包 hdc install com.wordcorner.anyu-1.0.0.hap # 启动应用 hdc shell aa start -b com.wordcorner.anyu -a MainAbility # 查看应用日志 hdc shell hilog | grep anyu这里有一个值得强调的细节OpenHarmony 的应用调试信息输出需要用hilog而不是logcat而且默认日志级别下 Flutter 的 console.log 输出可能会被淹没建议根据 tag 过滤。我在开发阶段养成了在关键流程加debugPrint并用 hilog 抓取的习惯效率会高很多。在 RK3568 上言隅的流畅度表现超出我的预期。页面滚动基本保持 60fps输入响应无明显延迟图片加载稍慢但可接受。真正的问题出现在内存上RK3568 的内存相对有限Flutter 引擎在 OHOS 上的开销略高于 Android所以我在应用里加了简单的内存监控在低内存时主动释放图片缓存实测连续高强度使用半小时没有触发系统杀进程。3.3 HAP 打包与版本发布要点OpenHarmony 应用的产物是 HAP 包类似 Android 的 APK。Flutter ohos 工程的 HAP 打包流程已经比较自动化但有几个注意点包名配置在ohos目录下的app.json5中修改bundleName格式需要反域名风格比如com.wordcorner.anyu。如果包名不一致安装和启动时会发生错位。签名与调试OpenHarmony 应用安装到真机需要签名。调试阶段可以用 DevEco Studio 生成的自动调试证书正式发布需要申请发布证书和 profile流程类似 Android 的签名配置。当时我在 RK3568 上报install signature error排查后确认是缺少 profile 文件加上就好。图标与名称入口 Activity 的图标和名称配置在module.json5的 abilities 节点下这里改完才能让桌面显示的图标和名称正确。构建命令在ohos目录下执行hvigorw assembleHap打包产物在build/default/outputs/default/下。如果只做 debug 验证也可以用 Flutter 侧的标准flutter run -d ohos完成编译和推送但正式发布还是建议走 hvigor 的 release 打包流程。这套流程走通之后后续的迭代效率明显提高。改代码、编译、部署、跑日志整个闭环在十分钟以内完成和 Android 开发的体验已经非常接近。4. 常见问题排查与避坑实录4.1 生命周期管理与后台恢复的问题Flutter 应用在 OpenHarmony 上的生命周期事件和 Android 略有差异。言隅开发中遇到最典型的问题是应用退到后台再恢复时界面出现短暂白屏甚至偶发状态丢失。排查过程从两个方向并行。先是检查 Flutter 侧的生命周期回调确认AppLifecycleState在 OHOS 上是否正确触发再看系统和引擎层的 relaunch 机制。最终定位是因为应用在后台被系统资源回收但任务栈没有彻底销毁恢复时机和 Flutter 引擎初始化产生竞争。解决方案是在入口处增加一个WidgetsBindingObserver监听onExitApplication和onResume事件在检测到引擎可能被重建时手动触发一次数据刷新和路由恢复保证用户回到界面时看到的是最新内容而不是空白。这个问题在很多 Flutter OHOS 应用里都会遇到如果你们团队也在做类似适配建议在应用开发早期就把生命周期测试纳入常规用例不要等到用户反馈。4.2 底部弹窗内输入框被键盘遮挡言隅的记录详情页有一个底部弹窗里面包含一个用于快速添加标签的 TextField。在 Android 上 Flutter 默认会通过resizeToAvoidBottomInset自动调整界面但在 OpenHarmony 的某些版本上键盘弹出时弹窗没有被正确上推输入框被遮挡得严严实实。原因在于 OHOS 的输入法窗口通知机制和 Android 不完全一致Flutter 引擎在部分场景下没有收到 keyboardInset 更新。解决方案是手写一段兼容代码监听viewInsets的变化当检测到底部插入高度增加时手动给弹窗加上一个等高的 padding并附带动画让弹窗平滑上移。这个问题的隐蔽之处在于它不是每次都复现和键盘类型、系统输入法版本有关所以必须在多个输入法上做回归测试。4.3 Flutter 插件在 OpenHarmony 上的兼容性排查Flutter 生态的第三方插件在 OpenHarmony 上并非全部可用。每个插件都需要在 OHOS 平台有对应的 platform implementation 才能跑起来。言隅用到的核心插件包括drift数据库、path_provider路径、image_picker选图、shared_preferences偏好设置、url_launcher打开链接。这些在社区适配度上差异很大drift底层依赖sqlite3的 dart 实现在 OHOS 上可以纯 Dart 方式运行兼容性较好我在使用中没有遇到阻塞问题。path_provider需要平台实现支持当前 OHOS 社区版本已经覆盖大部分路径接口注意getApplicationDocumentsDirectory和getTemporaryDirectory是正确返回值不会返回空路径。image_pickerOHOS 分支已经实现相册选图和拍照但接口行为和 Android 略有不同建议在真机上多测几次。url_launcher默认实现可以拉起系统浏览器但在部分 OHOS 版本上需要手动声明查询 intent 的权限否则会静默失败。排查插件问题的通用方法是先在纯 Dart 侧打印所有调用路径确认是插件本身的 platform channel 没实现还是系统侧权限问题。如果某个插件在 OHOS 上确实不可用可以用条件编译写一份 fallback 实现比如言隅里图片选择在 OHOS 上就做了一个直接用 FilePicker 的备用路径。4.4 常见问题速查表问题现象可能原因排查方向最终方案HAP 安装报 signature errorprofile 未配置或不匹配检查签名文件配置和 bundleName 一致性在 DevEco Studio 中生成并配置正确的调试证书和 profilehdc list targets 看不到设备hdc 工具版本不匹配或驱动未装对比 hdc 和系统要求的版本检查 USB 调试是否开启重新安装对应版本的 hdc确认设备端开启调试权限Flutter run 编译卡住OHOS SDK 版本和 Flutter 分支不匹配查看编译输出中的版本常量将 SDK 和 Flutter ohos 分支更新到官方兼容表对应版本界面白屏恢复引擎后台重建竞争观察生命周期和引擎初始化时序增加生命周期监听和手动恢复逻辑键盘遮挡输入框viewInsets 更新缺失在弹窗打开时监控 inset 变化手写键盘适配逻辑动态调整弹窗位置图片选择后空白image_picker 的 OHOS 实现路径异常打印选择文件的路径和大小换用备用 FilePicker 路径或直接走系统相册搜索卡顿数据量大时联合查询低效使用数据库执行计划分析引入索引表搜索改为单字段 LIKE 查询中文文本对齐异常字体度量在不同平台上不完全一致对比 Android 和 OHOS 渲染结果通过自定义 TextPainter 校准行高和基线这张表的最后一项中文对齐异常其实是很多 Flutter 开发者忽略的细节。Flutter 的文本渲染在跨端时不同平台默认字体的度量稍有差异会让中文行高、字距表现不一致。言隅通过显式设置字体的package和fontFamily参数并统一采用自定义富文本渲染消除了这类隐形差异。5. 构建过程中的工具链选择与效率心得5.1 Flutter 状态管理与路由管理的选型记录言隅在状态管理上选了 Riverpod这个决定经历过一次小的波折。最初用的 Provider写到标签管理模块时发现多个页面需要监听同一个异步数据源Provider 的状态更新广播逻辑分散在各处代码可读性下降得很明显。后来切到 Riverpod利用AsyncNotifier统管灵感列表和标签数据通过ref.watch在组件层自动订阅数据流一下清晰了。路由管理用的是 go_router因为言隅有一个从记录列表到随机回顾再到详情页的复杂跳转关系go_router 的声明式路由配置能把这些关系集中在一个文件里描述后续加深链、做登录跳转都方便。工具链选择的心得是Flutter 应用的复杂度往往会随着开发深入快速增加一开始就用大而全的状态管理方案比如 bloc可能反而拖慢速度。言隅这种中小型应用Riverpod 加 go_router 的轻量组合刚好够用既有清晰的依赖关系又不需要承接过于繁重的框架概念。5.2 数据库选型为什么是 Drift 而不是 Isar 或轻量键值对灵感记录场景需要存储的数据量级是个人级别的笔记单条记录几 KB 到几百 KB含图片路径一年下来也就几千条记录。这个数据量用什么方案都跑得动但言隅最终选了 Drift原因有三关系型数据适合灵感记录的查询模式按时间排序、按标签筛选、按关键词全文检索这几个核心查询用 SQL 表达最直接。Drift 的类型安全特性能在编译期帮我发现 SQL 错误对独立开发者来说省掉了很多低级调试。它底层是 SQLite在上面已经提到过 OHOS 对 SQLite 的支持相对成熟跨端风险明显低于 Isar 这种纯 Dart 实现的数据库引擎。与 Isar 相比Drift 的缺点是需要写原生 SQL但在开源社区中 Drift 的文档质量和对 Flutter 的适配广度都有优势。如果你的应用只需要简单的 KV 存储直接用shared_preferences或者hive就够了不需要为一个列表查询引入完整的 ORM。5.3 多人协作与版本管理经验虽然言隅目前是个人项目但我在工程上仍然按照多人协作的标准管理代码库。统一 dart format 和 analyze 规则所有功能分支合并前必须过一遍静态检查UI 相关内容提交时带上截图方便回溯视觉变更。OpenHarmony 和 Flutter 双端的依赖放在同一份pubspec.yaml里但 OHOS 特有的配置如签名文件、SDK 路径做了 gitignore 排除避免不同开发者的本地路径互相污染。这个做法在后续有协作者加入时能省掉大量环境对齐的时间。6. 内容安全与合规检查这个话题在开发过程中经常被忽略但发布应用时必须面对。言隅的内容安全主要做三层防护基础的敏感词过滤对用户输入内容在存储前做一轮过滤包含敏感字词即时提示并阻断。本地优先的隐私策略言隅默认完全离线存储用户数据只存在设备本地不上传任何云服务器。这个设计既保证了隐私安全也简化了合规审查的复杂度。图片内容不采集图片全部本地处理不接入任何云端审核接口避免用户私密内容外泄。这里要特别提一句做应用时安全和合规是两个层面的事。安全是技术问题确保数据不被非法访问合规是流程问题确保业务模式允许收集的内容合法收集。独立开发者最容易犯的错是把用户数据一律传到自己的服务器上既增加了成本又引入了不必要的合规风险。言隅选择本地优先 可选云同步后续做的模式本质上就是把这个风险前置规避掉了。从我个人的体会来说内容安全不能等应用做完了才补。开发初期就应该决定核心数据流的走向这直接影响技术架构——比如言隅的数据库和缓存设计从一开始就是为本地优先架构服务的后期如果需要云同步只需要在数据层加一层 export/import 接口不需要动 UI 层逻辑。7. 后续的扩展方向与维护规划言隅目前的版本已经能完整体验记录、管理、回顾的闭环但它在规划上还有很多可延伸的空间。首先是平台扩展言隅的 Flutter 代码天然支持 Android 和 iOS当前只需要对 package 名、权限声明和少量平台差异做适配理论上可以快速产出移动双端版本这也是当初选 Flutter 的回报。第二是数据互操作。受限于本地优先的设计言隅的数据目前是封闭的。后续计划为用户提供 Markdown 导出、JSON 备份、甚至通过系统分享面板把单条灵感发送到其他应用的能力。这样即便用户未来不再使用言隅数据也不会被锁死这是工具类应用获取信任的重要方式。第三是桌面端适配。Flutter 对桌面端的支持已经比较完善如果言隅能上架 Windows 或 macOS 桌面端结合大屏的文字编辑体验场景会进一步拓展——比如在电脑上摘录网页内容在手机上随手记录想法。当然这会带来输入源合并、多端同步等新问题属于二期工程。还有一个继续打磨的方向是随机回顾的智能算法。目前是按日期分组随机抽取下一步可以引入更丰富的信号比如根据用户当前时间判断晚上适合读诗或者根据历史回顾次数减少重复展示频率。这些东西不影响应用的核心功能但会实实在在地影响用户每次打开应用的心情。写在最后一点真实的心里话回到开头的问题Flutter for OpenHarmony 到底值不值得做我的判断是如果你本身是 Flutter 开发者想低成本进入 OpenHarmony 生态现在就是比较合适的窗口期。环境搭建确实有一些坑但集中花一两天时间完全可以解决第三方插件的 OHOS 适配还在追赶期但常见的场景基本都有覆盖。更关键的是OpenHarmony 的应用市场远没有 Android 和 iOS 那么拥挤一款在功能和体验上做得用心的小工具在早期生态里反而更容易被看见。言隅这个项目给我最大的收获不仅仅是把 Flutter 跑到了 OpenHarmony 真机上而是在这个过程中重新理解了跨端和适配的边界——哪些东西框架能帮我解决哪些东西必须我自己动手处理这个分寸感比任何现成的解决方案都更值钱。如果你也在做类似的尝试我的建议是别把所有期望压在框架的成熟度上而是在动手前就把产品边界想清楚用最强的框架能力去解决核心体验问题用足够的兜底方案去覆盖平台的差异地带。这样不管底层技术怎么演进产品本身都能站得住。