标签 Flutter 下的文章

大家好，我是老刘

最近TIOBE在2026年一月的编程语言排名出来了。

不出意外的，Dart又排在25名之后了。

为啥作为跨平台一哥Flutter的编程语言，Dart的排名如此落后？除了Flutter，Dart还有哪些应用场景？

本文我们来讨论一下这些问题。

1. Dart 语言近半年排名趋势

老刘统计了 Dart 语言在 TIOBE 索引中的近半年排名趋势，发现 Dart 语言的排名一直保持在 25 名之后，而其 Ratings 也始终保持在 0.60% 左右。

日期Dart在TIOBE的排名Ratings
2025-07280.61%
2025-08280.59%
2025-09280.62%
2025-10270.62%
2025-11260.69%
2025-12260.64%
2026-01260.63%

数据来源：https://www.tiobe.com/tiobe-index/

2. TIOBE并非根据语言使用量进行排名

TIOBE 索引是一个衡量编程语言 popularity 的指标，它根据每个月的搜索量来计算每个语言的排名。

每个月，TIOBE 会发布一个排名，该排名是根据搜索量的百分比来计算的。

它聚合了全球主流搜索引擎和网站的数据，包括 Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube, Baidu 等25个以上的平台。

计算Ratings逻辑大致如下：

  • 首先计算每种语言在各个搜索引擎上的“命中数”（hits）。
  • 对这些数据进行归一化处理（消除不同搜索引擎总量差异的影响）。
  • 最后计算出该语言在所有被统计语言总搜索量中的 占比（即 Ratings） 。

所以TIOBE的排名只能代表Dart语言在众多编程语言中的受关注程度，而非其在实际开发中的使用数量。

3. 为啥Dart语言排名始终不高？

与 2025 年大幅攀升的语言（如 C# 成为 2025 年度语言、 Perl 从 32 名冲回 11 名、 Zig 冲到 42 名）相比，Dart 的排名非常稳定，没有出现剧烈的排名跳跃。

根本原因是Dart语言的排名是与Flutter深度绑定的。

和大多数编程语言不通，比如Java用于服务端开发、Android开发的多个不同的领域。

而Dart的主要应用场景只有Flutter。

如果Dart在未来没有脱离Flutter用于其它方向，那么它的排名就会继续保持在20名之后。

4. Dart排名稳定代表了什么？

我们来看一下Dart排名波动最大的时间点。

可以看到Dart语言最受关注的时间是在2017年Flutter刚发布的时候。

之后是Flutter的高速扩张然后成为客户端跨平台开发的首选框架。

最近这几年，Flutter逐步进入了稳定期，Dart语言的关注度也开始稳定下来。

所以Dart语言的排名稳定从某种程度上代表了Flutter生态相对比较稳定。

这对我们这些Flutter开发者来说是一个好消息。

毕竟没有一个程序员喜欢自己吃饭的语言框架三天两头出现大的变动。

而且语言和框架的稳定带来的另一个好处就是AI友好度的提升。

因为AI模型通常是基于某个语言或框架训练的，而如果这些语言或框架经常变化，那么在日常开发中就需要程序员不停的去修正AI生成的代码。

5. 希望Dart语言能有更多领域的应用

之前老刘就专门写过文章，之前我喜欢Kotlin的强大，现在更喜欢Dart的简洁。

[Kotlin vs Dart：当“优雅”变成心智负担，我选择了更简单的 Dart
](https://mp.weixin.qq.com/s/KyqmMXTE4GyAJU2NjJYtUg)

随着编程风格越来越趋向于简洁、稳健。

我也越来越喜欢Dart这种既能同时支持面向对象和函数式编程两种编程范式，同时又能在日常开发中保持语法简洁的编程语言。

所以老刘还是希望能有更多的领域可以应用到Dart语言。

老刘觉得在以下一些领域Dart还是有用武之地的：

服务端开发 (Backend)：

如果能用 Dart 写后端，实现**前后端同构**，复用同一套 Model 和 业务逻辑，将极大地降低全栈开发的门槛。像 Serverpod 和 Dart Frog 这样的框架已经开了个好头，但还需要更完善的生态。

命令行工具 (CLI)：

Dart 优秀的 AOT 编译能力，使其生成的二进制文件启动极快且无需依赖环境。编写跨平台的脚本工具，Dart 其实比 Python 或 Node.js 更具部署优势。

WebAssembly (Wasm)：

随着 Dart 对 WasmGC 的支持日益完善，未来 Dart 代码将能以近乎原生的性能运行在浏览器中，这为高性能 Web 应用提供了新的可能。
当然这部分可能还是和Flutter有很大的绑定关系。

总结

如果Dart能像JavaScript从浏览器走向Node.js那样，成功在服务端或CLI领域突围，那么对于我们这些Flutter开发者来说，将是一个好消息。

因为这意味着我们掌握的这门语言，将拥有更广阔的舞台，而不仅仅局限于画UI。

那么作为开发者，我们不妨在日常的小工具、脚本或者简单的后端服务中，多给 Dart 一些机会。

毕竟，生态的繁荣，离不开每一个开发者的尝试与贡献。

🤝 如果看到这里的同学对客户端开发或者Flutter开发感兴趣，欢迎联系老刘，我们互相学习。

🎁 点击免费领老刘整理的《Flutter开发手册》，覆盖90%应用开发场景。可以作为Flutter学习的知识地图。

🚀 覆盖90%开发场景的《Flutter开发手册》

📂 老刘也把自己历史文章整理在GitHub仓库里，方便大家查阅。
🔗 https://github.com/lzt-code/blog

大家好，我是《交易学徒》的作者。

简单介绍下背景：我现在的核心身份是带两个孩子的全职奶爸，副业才是趁着孩子睡着后，在键盘上敲敲打打的独立开发者。

对于我这种“碎片化时间”开发者来说，运维复杂度就是最大的敌人。

几年前写后端，我也迷信“标准答案”：做个服务，起手就是 Docker 编排，Redis 做缓存，Kafka 做解耦，微服务先分几个出来。结果往往是，功能没写几个，光是调网络、修连接超时、查中间件报错，就把孩子午睡的那宝贵两小时耗光了（那时候还没孩子）。

在开发后端时，我陷入了深思：

“对于一个追求极致性能、但只有一个人维护的系统，所谓的‘工业级架构’真的是解药吗？还是毒药？”

最终，我做了一个违背祖宗的决定：做减法。 我删除了 Redis ，移除了 Kafka ，把整个微服务集群塌缩成了一个 Rust 单体应用。

今天想聊聊这背后的思考过程。

一、 复杂度的守恒与转移
我的业务场景看似简单，实则牵一发而动全身。一个简单的“用户平仓”动作，就像推倒了第一块多米诺骨牌：

核心域：结算盈亏，改余额，写数据库。（必须马上做）

通知域：给前端发个弹窗通知“平仓成功”。（晚 0.1 秒没关系）

营销域：判断有没有触发“五连胜”、“以小博大”成就，发奖励。（晚 1 秒没关系）

统计域：计算交易评分，统计分数或者更新等级与交易报表。（晚几秒都行）

在“标准架构”里，我们需要引入 消息队列 (MQ) 来解耦这些逻辑。 但引入 MQ 本质上并没有消除复杂度，只是将“代码复杂度”转移成了“运维复杂度”。

对于团队，运维复杂度可以分摊给同事；但对于我，这意味着我不仅要写代码，还得修服务器。

Rust 给了我另一个选择：利用它极高的性能，把“运维复杂度”重新压回“架构设计”里，用最朴素的方式解决问题。

二、 内存即总线：构建“喊一嗓子”的架构
我利用 Rust 的内存通道特性，构建了一个“超光速大喇叭”。 我不请求数据，我只发布事实。

这个过程，可以用一个生活化的场景来描述：

  1. 定义世界的真相 (The Truth)
    我不写复杂的 XML 或 JSON 定义，我只是在代码里列了一张“事实清单”：

📄 事实 A：有人平仓了（包含：是谁、赚了多少、单号是多少）

📄 事实 B：有人购买商品了

📄 事实 C：AI 分析完成了

编译器会盯着这张清单，保证我发出的每一个“事实”都是格式正确、童叟无欺的。

  1. 极简的生产者 (Fire and Forget)
    在核心交易逻辑里，当数据库事务提交成功后，我只需要做一件事：拿着大喇叭喊一嗓子。

传统架构 (Kafka) 是这样的：

交易模块 -> 打包数据 -> 建立 TCP 连接 -> 三次握手 -> 发送给 Kafka 集群 -> 等待 ACK -> 结束 (这中间任何一步网络抖动，都得处理异常)

我的单体架构是这样的：

交易模块 -> 喊：“老王平仓赚了 100 块！” -> 结束 (纯内存操作，纳秒级完成，快到像是没有发生过)

  1. 静默的消费者 (Sidequest Logic)
    我把原本分散在微服务里的逻辑，变成了几个坐在角落里的“隐形工人”。

比如 “营销服务”，它就像一个在角落里旁听的记分员：

它平时不说话，只听大喇叭。

一听到 “老王平仓赚了 100 块”，它立马翻开小本本查历史。

发现老王已经连赢 4 把了，加上这把正好 5 把。

于是它默默地给老王发了一个“五连绝世”的徽章。

整个过程，核心交易模块完全不知情，也完全不用等待，它喊完那一嗓子就去服务下一个用户了。

三、 深度思考：关于“不可靠”的权衡
很多朋友可能会问：“没有 Kafka 把消息存到硬盘里，万一服务器断电了，你喊的那一嗓子不就丢了吗？”

是的，这是整个架构思考中最痛苦，也是最关键的取舍。 我问了自己两个问题：

Q1：我的程序崩溃概率有多大？ Rust 以安全著称，只要代码写得不离谱，它极难崩溃（ Panic ）。这比 Java 的内存溢出或 Python 的运行时错误要稳健得多。

Q2：丢失数据的代价是什么？

我们可以把数据分成两类：

💰 钱（核心数据）： 余额、订单状态。

处理方式： 必须落袋为安。 直接写死在数据库里，绝不依赖“大喇叭”。

🎁 气氛（衍生数据）： 弹窗通知、成就徽章、达标奖励、统计报表。

处理方式： 听天由命。 如果真的赶上万年不遇的服务器着火，用户少收到了一个“五连胜”的弹窗，或者报表少统计了一笔，天会塌吗？不会。

结论： 为了 0.001% 的极端掉电风险，去让 99.99% 的时间里的系统背负沉重的中间件包袱，对于独立开发者来说，这是一笔亏本买卖。

四、 结语
当我们谈论“高性能”时，往往想到的是复杂的集群、昂贵的服务器。 但 Simple is fast. （简单即快）

现在的《交易学徒》后端，就是一个 20MB 的小文件。

❌ 没有 Docker 容器编排

❌ 没有 虚拟机调优

❌ 没有 Redis 维护

❌ 没有 服务间通讯

✅ 只有一个跑在单机上的进程，CPU 占用极低，响应速度极快。

这省下来的不仅仅是每年的服务器费用，更是我作为父亲陪伴孩子的宝贵时间。

技术服务于生活，这大概就是独立开发的魅力吧。

关于《交易学徒》
这是我用这套“极简架构”打磨的作品，前端是 Flutter ，后端 Rust 。 希望能给交易员朋友们提供一个干净、流畅、无延迟的练习环境。

官网: https://www.zgjiazu.top

Google Play: https://play.google.com/store/apps/details?id=com.zengkai.jyxtclient

欢迎 V 友们指正。如果你的孩子也吵着要抱抱，那我们就是异父异母的亲兄弟了。😄

[Flutter 独立开发] 挑战千元机极限：纯客户端计算 K 线+指标，三星 A53 实测 70 FPS

大家好，我是《交易学徒》的独立开发者，祝大家周末愉快！

做过金融类 App 的朋友都知道，移动端的 K 线图（ Candlestick Chart ） 渲染一直是性能优化的“深水区”。

为了降低服务器成本和网络延迟，我做了一个“违背祖宗”的决定：完全依赖客户端算力。 所有的技术指标（ MA, BOLL, MACD 等）计算，全部在移动端本地实时完成，不依赖后端返回计算结果。

这意味着，一台三星 A53 （ Exynos 1280 处理器，典型的千元机性能）不仅要负责 UI 绘制，还要在主线程实时遍历数组计算指标。

在这种“地狱模式”下，优化成果如何？

📉 性能实测：A53 跑分数据

测试设备：三星 Galaxy A53 (Exynos 1280)
测试场景：

  • GOLD 平均每秒 2.5 次报价
  • 加载 500 根 K 线数据
  • 同时开启 MA (移动平均线) + BOLL (布林带) + MACD 三组指标 + 图表网格
  • 所有指标数据均为 本地实时计算
  • 进行高频拖拽、缩放操作

实测结果：

1. 三星 A53 (低端机代表)

A53 帧率测试图

70 FPS ！
在这种重负载下，UI 线程依然保持极高的流畅度，超过 60Hz 的及格线。对于一款千元机来说，这个渲染性能我已经非常满意了。

2. 三星 S25+ (旗舰机代表)

S25+ 帧率图

旗舰机毫无压力，贵的还是好哇。

🏛️ 技术挑战：为何 Dart 能抗住？

很多人对 Flutter 的印象还停留在“套壳性能差”。但实际上，通过合理的架构，Dart 的性能完全够用。我的优化核心思路是：UI 渲染与数据计算分离，用空间换时间。

1. 极致的分层渲染 (Layered Rendering)

我利用 Stack 将视图拆解为三个独立的渲染层级：

  • **Layer A (底层)**：静态 K 线与网格。这是最“重”的层（包含数千个顶点），只有在缩放或平移时才重绘。
  • **Layer B (中间层)**：技术指标 (MA, BOLL)。与 K 线同步，但逻辑分离。
  • Layer C (交互层)：这是优化的关键。包含当前的 Bid/Ask 价格线、十字光标。这一层极其轻量，且更新频率最高（每秒数次）。

通过 Stack + RepaintBoundary，实现了：价格跳动时，底层的几百根 K 线完全不需要参与重绘，GPU 只需要绘制那几条横线。

2. 动态 LOD (Level of Detail) 策略

在手机屏幕上展示 500 根 K 线时，GPU 光栅化压力巨大。
我在代码中加入了 LOD 策略：

  • Zoom In：渲染完整的 Candlestick（蜡烛图）。
  • Zoom Out：当可视区域数据点过多时，自动切换为 LineChart（收盘价连线）。

这极大地降低了 GPU 的顶点绘制数量，解决了缩放时的“卡顿感”。

📱 软件界面预览

目前的 UI 风格偏向现代扁平，针对移动端操作做了很多适配。

软件界面截图

🔗 下载与体验

软件目前已上架 Google Play ，名为“交易学徒”。如果你对高性能 Flutter 开发或者交易感兴趣，欢迎下载体验。

🎁 V 友专属福利

感谢大家看完这么枯燥的技术分析。
人肉送 VIP：在评论区留下你的 用户 ID（在“我的”页面可以看到），我会手动为你开通 1 个月的 VIP 会员。

欢迎大家对 UI 、交互或者技术实现提出建议，每一条我都会认真看！

Fuwari Studio 是一个基于 Flutter v3 开发的 Astro Fuwari 静态博客文章编辑软件。

好吧没词了反正好用就对了 (

Fuwari Studio - 开源的 Astro Fuwari 文章管理器2

📌 转载信息
原作者：
Lazy_Craft
转载时间：
2026/1/23 09:00:00

[软件推荐] AllLive (C# 版) + Simple Live：打造全平台直播观看双保险

大家好，之前论坛里也有不少朋友推荐过 Simple Live，它确实是一款非常优秀的开源全平台直播聚合工具。

今天我想特别介绍一下同一位作者（逍遥橙子）的另一个项目：AllLive。虽然两者功能相似，但它们的底层实现不同（Simple Live 是 Flutter，AllLive 是 C#），且在不同场景下各有优势。

为什么选择 AllLive？

  1. 多端支持：AllLive 是基于 C# 开发的，拥有 Windows 客户端，并且已上架 Microsoft Store，安装和更新非常方便。
  2. 试用友好：软件提供永久免费的试用版（付费版仅用于支持作者，功能完全一致）。
  3. 数据同步：虽然 Simple Live 早就支持多设备同步和 WebDAV 备份，但 AllLive 在 Windows 端的表现更加原生流畅。

我的使用场景与解决方案

平时我喜欢看 B 站 和 抖音 的唱歌主播：

  • B 站：两者适配都很完美。
  • 抖音：这里有个小痛点，AllLive 的搜索功能在抖音上目前是失效的。

我的 “骚操作”：
利用 Simple Live 强大的链接解析能力来 “助攻” AllLive。

  1. 在手机端（Simple Live）中打开抖音直播间，复制链接。
  2. 在电脑端（AllLive）中通过链接解析进入直播间。
  3. 关注该主播，这样数据就会同步到 AllLive 的电脑端，方便后续观看。

总结

如果你更喜欢 Windows 原生应用，或者想体验 C# 实现的流畅度，AllLive 是个不错的选择。
配合 Simple Live 解析链接，两者互补，体验极佳。

界面预览

图一：在 Simple Live 中解析抖音链接并关注主播

【直播聚合】simple live 搭配 AllLive 的使用，尤其是抖音～2

图二：数据同步后，在 AllLive (Windows) 端的观看界面

【直播聚合】simple live 搭配 AllLive 的使用，尤其是抖音～1

📌 转载信息
原作者：
kerokero
转载时间：
2026/1/21 22:39:31

哈喽，我是老刘

2025年已成过往。随着iOS、Android、桌面端、Web与各类小程序的持续发展，原生开发的高墙已难以维系，成本与效率的矛盾达到顶峰。

跨平台不再只是备选项，而是个人和团队的必选项。但面对Flutter的全平台一致体验、React Native的新架构性能突破、uni-app x的原生编译能力、KMP的Compose全栈统一，究竟谁才是2026年的最优解？

如何在这个AI重塑代码的时代，把有限的资源发挥出最大的效率？

老刘每个月为大家画出最新的跨平台技术选型地图，帮你快速做决策。

本月，各大框架在“原生体验”与“AI提效”上都有重磅更新。

1. 2025年跨平台技术简单总结

  • 性能仍是核心

2025年，各个框架都在寻找性能的突破点。

Flutter全面普及Impeller引擎，解决了最后一公里的卡顿问题。

uni-app x和KMP则选择了另外一条路，通过编译为原生代码（Native Compilation），直接从物理层面消除了性能鸿沟。

RN则全面切换到新架构来实现性能的突破。

性能上向原生看齐是2025年跨平台技术的一个重要趋势。

  • 平台拼图补全

框架们不再满足于能跑，而是追求各个平台的完美适配。

Flutter在桌面端和Web端（Wasm）持续发力，真正实现六端同源。

KMP推出了Kotlin-to-Swift导出功能，让iOS开发者也能优雅地接入，填补了跨平台在iOS原生生态上的最后一块拼图。

  • AI与框架深度融合

AI不再只是外部辅助，而是开始进入框架内部。

Flutter推出的Dart MCP Server让AI能直接理解项目结构和组件树。

MAUI也在不断完善其AI功能，如Copilot Agent，试图通过AI赋能来改善开发者体验。

应该说我们离描述即应用的时代不远了。

2. 最新技术动态

2.1 React Native 新架构全面启用

React Native 0.83 发布日志: https://reactnative.dev/blog

React Native 0.83 版本随 Expo SDK 55 正式到来。新架构（New Architecture）已成为默认标准，遗留架构代码正在被加速移除。新版本集成了 React 19.2，并在构建时间和应用体积上取得了显著优化。开发者现在可以享受到更接近原生的性能体验，以及更强大的 DevTools 支持。

2.2 Kotlin Multiplatform 生态成熟加速

Kotlin 2.3.20-Beta1 新特性: https://kotlinlang.org/docs/whatsnew-eap.html

Kotlin 2.3.20-Beta1 于本月发布，标志着 KMP 生态的进一步成熟。

Compose Multiplatform for iOS 已经稳定，越来越多的团队开始从原生转向 KMP。

K2 编译器的全面普及以及 JetBrains 在 AI 辅助开发（如 Koog 和 Mellum）上的投入，使得 KMP 的开发效率达到了新高度。

2.3 .NET MAUI 企业级发展

.NET MAUI Roadmap: https://github.com/dotnet/maui/wiki/Roadmap

.NET 11的规划和早期迭代正在进行中。当前重点依然是提升产品质量和性能稳定性。微软正在深度集成 GitHub Copilot 和 Copilot Agent，试图通过 AI 赋能来改善 MAUI 的开发者体验。尽管社区仍有关于稳定性的讨论，但其在企业级市场的地位依然稳固。

2.4 Flutter 平台更新

Flutter 最新动态: https://docs.flutter.dev/release/whats-new

虽然社区对 Flutter 4.0 充满期待，但截止 2026 年 1 月，Flutter 3.38 仍是官方维护的最新稳定版本。目前的更新重点在于 Impeller 渲染引擎 的进一步优化与稳定性提升，该引擎现已在 iOS 和 Android 上默认启用，彻底解决了 shader 编译造成的卡顿问题。此外，Flutter 团队修复了 Android 端 Activity 销毁时的内存泄漏问题，并对 Android 15 的 16KB Page Size 提供了完整支持，继续巩固其在跨平台渲染一致性上的优势。

2.5 uni-app x 进展

uni-app x 更新日志: https://uniapp.dcloud.net.cn/release.html

近期 uni-app x 迎来了一系列重要更新（v4.87）。核心亮点包括：

  • 多线程能力增强
    新增 uni.createWorker API，正式支持 Worker 线程，显著提升复杂计算场景下的性能表现。
  • 鸿蒙生态深度适配
    将逻辑层 JSVM 迁移至独立子线程，彻底解决主线程阻塞问题；新增微信登录、分享及屏幕亮度调节等原生能力。
  • 新设备与系统兼容
    修复 Android 16KB 页大小模式下的录音问题，并提前适配 iPhone 17 系列机型。

2.6 Valdi 进展

Valdi GitHub 仓库: https://github.com/Snapchat/Valdi

本月Valdi框架没有新的进展，最新发布版本仍然是beta-0.0.1

接下来老刘按照跨平台技术框架的三种路线，分别介绍一下目前主流的跨平台技术。

3. 自渲染类框架

简单来说，就是框架自己携带渲染引擎，自己画界面，不用系统提供的组件。

这样做有什么好处？

  • 界面完全一致
    UI渲染不依赖系统组件，多端展示效果完全统一。
  • 性能媲美原生
    跳过系统UI层直接操作GPU绘制，架构与原生一致。
  • 无兼容性Bug
    不调用系统原生组件，规避了因系统差异导致的兼容性问题。

3.1 Flutter

2024年Stack Overflow调查显示，Flutter是最受欢迎的跨平台框架。

全球有超过500万开发者在使用。

连阿里巴巴、腾讯、字节跳动都在使用Flutter。

为什么这么多大厂选择Flutter？

  • 性能强劲
    切换Impeller引擎后，Flutter性能已与原生应用一致。
  • 开发高效
    热重载实现秒级预览，Dart语言在功能性与复杂度间达成完美平衡。
  • 生态成熟
    pub.dev拥有超4万插件，涵盖地图、支付等各类功能，开箱即用。
  • 测试友好
    拥有客户端领域最佳的单元测试支持，是TDD及敏捷团队的最优选择。

  • 拥抱AI

    • AI Toolkit

    集成Gemini API，快速实现聊天、识别等功能。

    • 本地部署

    支持TensorFlow Lite/ONNX，保障隐私安全。

    • Dart MCP Server

    让AI助手直接理解项目，辅助编码与调试。

4. 中间层类框架

简单来说，就是在你的代码和系统原生组件之间，加了一个"翻译官"。

比如你用JavaScript写界面逻辑，框架帮你翻译成原生的Button、TextView。

核心特点：

  • 成熟的开发体验
    复用React/Vue/C#等生态成熟的开发思路，上手快，学习成本低。
  • 原生组件渲染
    最终映射为系统原生组件，UI符合平台规范，质感原生。
  • 桥接性能损耗
    通过中间层与原生通信存在"翻译"开销，交互密集场景性能稍弱，常规界面无感知。

4.1 React Native

React Native是第二受欢迎的跨平台框架，是Facebook开源的项目。

为什么这么多人选择React Native？

核心优势：

  • 零门槛上手
    React开发者可直接复用JSX、组件化及状态管理经验，一周即可转型。
  • 生态庞大
    npm拥有超15万相关包，共享Web生态，导航、支付等库应有尽有。
  • 动态热更新
    支持不发布新版本App直接在线更新，无需发版即可修复Bug或上线新功能，迭代极快。
  • 架构升级
    Meta持续投入，新架构引入Fabric和TurboModules，性能提升30%，旧架构已退役。

4.2 .NET MAUI

2024年5月，微软正式停止了Xamarin的支持，.NET MAUI（Multi-platform App UI）成为微软官方的跨平台解决方案。

核心优势：

  • 企业级保障
    微软提供长期技术支持（LTS），确保企业应用所需的稳定性。
  • 数据处理强
    C#擅长处理复杂业务逻辑，特别适合金融、ERP等数据密集型应用。
  • 生态深度集成
    与Azure、SQL Server等微软全家桶无缝对接，集成体验最佳。

5. 转译类框架

简单来说，就是把你写的高级语言代码，"翻译"成目标平台的原生代码。

比如你用Kotlin写业务逻辑，框架帮你"翻译"成iOS的Swift代码。

或者你用类TypeScript的语法写界面，框架帮你"翻译"成Android的Kotlin和iOS的Swift。

核心特点：

  • 性能接近原生

因为最终运行的就是原生代码，没有任何中间层损耗。

就像你直接用Swift写iOS应用，用Kotlin写Android应用一样。

  • 能享受原生生态

转译后的代码可以直接调用平台的所有API。

  • 转译效果可能不完美

毕竟是机器"翻译"的代码，有时候可能不如手写的原生代码优雅。

特别是复杂的业务逻辑，转译后的代码可能需要人工优化。

但这个问题随着AI技术的发展，正在快速改善。

5.1 Kotlin Multiplatform (KMP)

KMP的核心用法：业务逻辑用KMP共享，UI用Compose Multiplatform统一开发

这是KMP的最新发展方向，结合了Compose Multiplatform的强大能力。

一套Compose代码可以运行在Android、iOS、Desktop、Web等所有平台。

KMP的特点

  • 真正的一套代码多平台

不仅业务逻辑共享，UI也可以共享，开发效率大幅提升。

  • 保持原生性能

    Compose Multiplatform在各平台都编译为原生代码，性能接近原生应用。

  • 技术栈统一

全部使用Kotlin生态，学习成本更低，团队协作更高效。

  • 渐进式迁移

你不需要重写整个应用，可以先从一个模块开始。

比如先把网络层用KMP重写，然后逐步迁移UI到Compose Multiplatform。

  • 生态仍需完善

生态仍在加速建设，注意版本兼容与插件成熟度，第三方库相对较少，但发展很快。

5.2 uni-app / uni-app x

传统uni-app
基于Vue.js + JavaScript，更适用于小程序开发

uni-app x
全新架构，使用UTS语言，性能达到原生级别

uni-app x的技术特点

  • 平台支持最全

一套代码可以发布到：iOS、Android、Web、各种小程序、快应用、鸿蒙...

总共支持14+个平台，这是其他框架做不到的。

  • 小程序优先的设计理念

如果你的产品需要同时支持App和小程序，uni-app几乎是唯一的选择。

其他框架都是App优先。

  • 国产化支持

对鸿蒙、信创等国产化平台支持最好。

这对国内企业来说非常重要。

  • uni-app的局限

    生态相对封闭
    主要依赖DCloud的生态
    国际化程度低
    海外开发者使用较少
    技术栈绑定
    主要适合Vue技术栈

5.3 Valdi

Valdi的核心思路属于转译方案的范畴，但是并发代码级转译。

它采用了介于转译和中间层之间的混合架构，将UI组件树编译为原生组件并交由C++引擎管理生命周期，同时保留业务逻辑在TS层（Worker）运行，从而实现无JS Bridge的高性能渲染。

这样的好处是在一定程度上避免了转译类方案代码翻译不到位造成的一些问题。

但是仍然会有中间层方案在高UI交互场景下的性能问题，这部分就需要把处理逻辑放到C++/Swift/Kotlin编写的Polyglot模块解决。

站在纯粹客户端跨平台开发的角度，转译类方案老刘目前更推荐KMP。

Valdi可以作为一个有潜力的备选，等生态更加成熟后再重新考虑。

6. 技术选型指南

看了这么多技术栈，是不是更晕了？老刘把复杂的选型逻辑浓缩成一份实战决策指南，帮你快速拍板。

6.1 核心推荐：Flutter (通用首选)

对于 90% 的新启动 App 项目，Flutter 是当前版本的最优解。

  • 性能强悍
    自带 Impeller 渲染引擎，不依赖系统组件，体验无限接近原生。无论是复杂的动画还是高性能列表，都能轻松驾驭。
  • 效率极高
    Hot Reload (热重载) 让改代码像刷新网页一样快。一套代码覆盖 Android、iOS、Web 甚至桌面端，研发成本降低 40% 以上。
  • AI 友好
    作为 Google 亲儿子，Cursor、Claude 等 AI 工具对 Dart/Flutter 的支持极为成熟，能自动生成高质量 UI 代码。

⚠️ 避坑提示
如果你的应用极度依赖原生比如有大量历史遗留的原生代码，或对包体积有苛刻要求 (<10MB)，需谨慎评估。

6.2 潜力观察：Kotlin Multiplatform (KMP)

极度依赖原生的最佳选择。

  • 核心定位
    逻辑共享，UI 原生。
    它不强求 UI 统一，而是让 Android 和 iOS 共享数据层、网络层和业务逻辑代码。

  • 适用场景

    • 已经在原生层面积累了大量的UI组件和功能模块，可以逐步把业务逻辑切换到KMP。
    • 应用强依赖系统底层能力 (蓝牙、NFC、深度硬件交互)，同时又希望保持跨平台的优势。
  • 现状判断
    技术理念先进，但第三方生态仍在爬坡期。2026 谨慎全量 All-in。

6.3 谨慎评估需求：App + 小程序 ≠ 一套代码

一个产品有App和小程序不代表他们的业务逻辑是完全一致的，小程序在产品定位上不应该是App的简化版。

  • 最佳实践：App和小程序承担不同的产品职责

    • App (Flutter/原生)
      负责沉浸式体验、复杂交互、高粘性留存 (如阅读、创作、社交)。
    • 小程序 (原生/Uni-app)
      负责营销裂变、即用即走、低成本获客 (如分享落地页、简单工具)。
  • 决策依据
    只有当功能重叠度 > 80% 且交互极其简单 (如纯展示类新闻、简单电商) 时，才推荐使用 Uni-app/Taro 等方案同时生成 App 和小程序。

6.4 决策速查表

你的项目场景推荐技术栈理由
从 0 到 1 新项目Flutter效率与体验的最佳平衡点
原生项目转型跨平台Flutter可以增量迁移，混合开发风险低
重度依赖原生底层KMP风险低，渐进式重构
App与小程序功能重叠Uni-app小程序支持好
系统级工具纯原生 (Swift/Kotlin)无中间层损耗，完全掌控硬件
团队 Web 背景React Native学习曲线平滑，社区资源丰富

7. 总结与建议

写了这么多，老刘最后给你一个终极建议。

2026年跨平台开发，记住这三个关键词：务实、聚焦、长期主义。

7.1 务实

软件开发没有银弹。

Flutter性能好但包体积大，React Native动态性好但有桥接损耗，KMP接近原生但生态不成熟。

选择技术的核心是：在当前约束条件下，哪个方案的收益最大。

7.2 聚焦

没有项目需要超过2种跨平台框架同时使用。

同样也不推荐团队同时在多个不同的跨平台框架上投入时间和精力。

建议：选定一个主力技术栈，最多再备一个备选方案。

7.3 长期主义

真正决定项目生死的，是你选定技术栈之后做的那些事。

  • 架构设计够不够清晰？
  • 开发流程够不够规范？
  • 代码规范够不够严格？
  • 技术债务管理够不够及时？

选定技术栈不是终点，而是起点。

做好这些基础建设，才是项目能持续健康演进的根本。

否则，再好的技术栈也救不了你。

最后，希望这篇跨平台开发地图能帮你避开那些坑，找到最适合你的路。

如果看到这里的同学对客户端开发或者Flutter开发感兴趣，欢迎联系老刘，我们互相学习。

点击免费领老刘整理的《Flutter开发手册》，覆盖90%应用开发场景。

可以作为Flutter学习的知识地图。

覆盖90%开发场景的《Flutter开发手册》

大家好，我是个兼职独立开发者，也是个老韭菜。

之前做交易亏麻了，痛定思痛，决定写个软件来练手。为了追求极致性能（也为了炫技），后端是用 Rust 写的，前端用的 Flutter 。

这个 App 解决了什么痛点？ 市面上的模拟盘大多只是简单的记录。我加入了一个 AI 分析师，针对每一笔交易，它可以复盘你的操作，告诉你这波是因为“追涨杀跌”还是“扛单”导致的。还有个段位系统，像打王者一样打交易。

目前进度：

Google Play 已上架（交易学徒）。

App Store 待上架。

官网： https://www.zgjiazu.top

Google Play: https://play.google.com/store/apps/details?id=com.zengkai.jyxtclient

福利：V 友下载体验，回帖“交易学徒”，我后台人肉送一年 VIP （请附上 App 内的 ID ）。

欢迎各位大佬提 Bug ，关于 Flutter 和 Rust 的坑也可以在评论区交流。

自己写的基于 Flutter 开发的跨平台音乐播放器，支持账号登录，从多个平台导入歌单。支持播放本地音乐，跨端续播。
支持平台：windows/android/ios/macos/linux，仅在 windows 与 android 进行了测试，因此其他平台可能存在部分 bug。
目前还处于测试阶段，欢迎大家体验测试，期待佬友们的建议与反馈。

应用需要导入自定义音源，支持 OmniParse，洛雪音源以及 Tunhub 音源 [分享] 自写了一个聚合音乐 API (TuneHub)，统一网易 / 酷我 / QQ 接口，免费开放 - 开发调优 / 开发调优，Lv1 - LINUX DO
桌面端使用 fluent ui，移动端支持 material design 和 cupertino 两种风格

仓库地址：
moraxs/CyreneMusic: flutter 开发的第三方音乐播放器
点点 star​

应用截图：

[Github 开源] 跨平台音乐播放器1


[Github 开源] 跨平台音乐播放器2


[Github 开源] 跨平台音乐播放器3


[Github 开源] 跨平台音乐播放器4


[Github 开源] 跨平台音乐播放器5


[Github 开源] 跨平台音乐播放器6


[Github 开源] 跨平台音乐播放器7


[Github 开源] 跨平台音乐播放器8

📌 转载信息
转载时间：
2026/1/20 10:08:33

各位佬友好！

最近几年每次过年 / 结婚季 / 满月酒都被人情账搞得头大：

  • 这次随了谁多少？
  • 上次谁给了我红包要记得回？
  • 到底谁欠我钱 / 我欠谁钱？
    手机备忘录记一记就乱，Excel 又嫌麻烦……

于是花了点时间用 Flutter Vibe Conding 了个小工具：随礼记

项目地址

下载体验地址

只做最核心的三件事，不臃肿：

  • 收礼 / 随礼 快速记录（自定义数字键盘 + 常见金额快捷）
  • 按人自动算往来余额（谁欠谁，一眼看清）
  • 本地存储 + 一键导出 CSV/Excel（不上云，数据安全）

其他：

  • 按事由分类（婚礼 / 满月 / 乔迁 / 升学 / 生日 / 葬礼 / 其他）
  • 简单联系人管理（姓名 + 备注）
  • Android/iOS/Web 都能跑

欢迎有类似痛点的佬友试用一下～

觉得好用就 star 一下，觉得可以更简洁 / 有 bug 就直接 issue/PR

📌 转载信息
原作者：
user_tz
转载时间：
2026/1/14 10:45:06

为什么做这个？

备考的日子里，我总是很难准确知道自己每天到底学了多少时间。

手动计时太麻烦，番茄钟又总是忘记开。坐在电脑前一整天，感觉学了很久，但实际有效学习时间可能只有几个小时。

于是我想：能不能让电脑自动帮我记录学习时间？

就像运动手环自动记录步数一样 —— 打开网课页面就自动开始计时，关掉就停止。不需要任何操作，专注学习就好。

快学点儿吧 就这样诞生了

功能亮点

功能说明
桌面程序基于 Tauri 的轻量应用，安静地待在系统托盘
浏览器扩展Chrome 扩展自动检测学习页面，无需手动操作
手机 APPFlutter 开发的 Android 应用，随时随地查看学习数据
云同步多设备数据无缝同步，电脑手机数据互通
数据统计直观的图表展示学习轨迹，日 / 周 / 月维度分析
目标管理设定每日目标，倒计时考试日期
智能通知学习里程碑提醒（可关闭，不打扰你）
开机启动随系统自动运行，打开电脑就开始守护

工作原理

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│   Chrome 浏览器  │────▶│     桌面程序     │────▶│    手机 APP     │
│    (扩展程序)    │     │   (时间记录器)   │     │   (查看统计)    │
└─────────────────┘     └─────────────────┘     └─────────────────┘
  1. Chrome 扩展 监控你的浏览器标签页
  2. 当你访问的 URL 匹配某个课程时，通知桌面程序
  3. 桌面程序 开始计时，数据存储在本地 SQLite 数据库
  4. 可选同步 到云端，在手机上查看统计数据

演示图：

桌面程序

【开源自荐】快学点儿吧（Study-Monitor） 自动追踪学习时间工具2
【开源自荐】快学点儿吧（Study-Monitor） 自动追踪学习时间工具3
【开源自荐】快学点儿吧（Study-Monitor） 自动追踪学习时间工具4
【开源自荐】快学点儿吧（Study-Monitor） 自动追踪学习时间工具5
【开源自荐】快学点儿吧（Study-Monitor） 自动追踪学习时间工具6
【开源自荐】快学点儿吧（Study-Monitor） 自动追踪学习时间工具7
【开源自荐】快学点儿吧（Study-Monitor） 自动追踪学习时间工具8
【开源自荐】快学点儿吧（Study-Monitor） 自动追踪学习时间工具9
【开源自荐】快学点儿吧（Study-Monitor） 自动追踪学习时间工具10
【开源自荐】快学点儿吧（Study-Monitor） 自动追踪学习时间工具11

移动 APP：

【开源自荐】快学点儿吧（Study-Monitor） 自动追踪学习时间工具12
【开源自荐】快学点儿吧（Study-Monitor） 自动追踪学习时间工具13

📌 转载信息
原作者：
Ar3s
转载时间：
2026/1/12 10:39:05

之前我每个月都会有一篇周记来总结当月的下载量和收入，也就是不管怎么流水账，每个月总有一篇是有内容的，内容就是下载量和收入的分析和总结。但是今年四月份的时候参加了一次独立开发者线下聚会活动，当时有人劝我不要再公开产品的下载量和收入，因为这确实带了一些小麻烦，从那以后我就没再写月度的数据总结，这回趁着年终总结，就写一个总体数字吧，以后每年就公布这一次。

本文虽然写于 2026 年，但是会用“今年”来代指 2025 年，“去年”代指 2024 年。

下载量（只统计极简时钟）

  • App Store ，363330 ，相较于去年提高 8.44%
  • Google Play ，182655 ，相较于去年下降 57.32%
  • 国内安卓市场，185007 ，相较于去年下降 33.77%

App Store 终于止住了连续四年的下降，小幅提升了一下。Google Play 连续两年超过 50% 的下降，虽然总下载量突破了 400 万，但也快完犊子了。国内安卓市场也是连续两年下降，幅度只比 GP 小一点点。

App 收入

  • App Store ，提高 40%
  • Google Play ，下降 45.71%
  • Admob ，下降 59%
  • 国内安卓市场，提高 45.63%

App Store 的提高可能归功于年初时的一个改动，就是 App 在下载后第一次打开走完 Onboarding 流程后立刻展示 Paywall ，这个策略让收入短时间大幅上涨，甚至达到了 RevenueCat 的收费门槛，但是好景不长，收入趋势很快就下降到了之前的水平。

Google Play 和 Admob 是绑在一起的，下载量的大幅下降也必然导致收入的大幅下降。虽热新 App 也接入了 Admob ，但是那部分收入完全可以忽略不计。

国内安卓市场今年收入的上涨完全依赖于极简日记，极简日记在 3 月份被大 V 带了一下流量，收入猛增，从那以后就立刻改变了国内安卓市场的收入结构，原来大部分都是极简时钟，现在改成了极简日记。问题是极简日记的下载量太少了，和极简时钟差了一个数量级，如果下载量能提高一些就好了。

2025 年的第一季度收入暴涨让我开心了半个多月，但是从那以后就一直下降，这一年也不怎么开心，我一直以为 2025 的总收入会不及 2024 年，可没想到年终一求和，居然比 2024 年还多，总体提高了 20%。扣除各种分成，到手的收入居然还突破 20 万，但也只突破了一丢丢，21 万左右。

瞎折腾

除了迭代已有的 App 外，今年还开发了几个新产品（但是都不赚钱），也拓展了新渠道（也不赚钱）。

  • 做了个 Web 应用，FlowFocus，就是用来保持心流的计时器，完全通过 AI 开发，没有任何流量。刚刚收到邮件通知，域名马上要过期了，续费要 30 多美元，算了。
  • 花了四个月写了个游戏 App ，Word Hack，没有内购，只有激励广告，第一次接入国内的广告平台，但是没有人玩，自然也没有收入。这个 App 从头到尾只有我一个人，所以也算一个独立游戏了，我也算是一个独立游戏开发者了。
  • 极简时钟成为 BYD Pad 的预装 App ，但是极简时钟的使用场景和车载 Pad 说实话不太搭，所以目前也没有任何的支付记录。不得不说，方程豹钛 7 这款车的销量真的很好。年底两个月有些天，来自比亚迪渠道的下载量居然不比国内其他安卓市场要差，有很多天甚至成为了日下载量第一的渠道。
  • 睡眠 App ，想要结合 HealthKit 和 MapKit 做一个睡眠习惯养成的 App ，写了一个多月的 demo 最后搁置了。为了开发这个 App 还特意买了 Apple Watch S10 ，参考很多了睡眠 App 的功能和设计，睡眠数据的读取和展示都搞通了，但是如何利用这些数据来做一些有趣的交互和没太想清楚。等到 WWDC25 之后，发现系统的睡眠 app 也有了很多新功能，我这个 App 感觉就没有继续开发的必要了。
  • 将极简时钟通过 Flutter 重写了一遍，尝试上架鸿蒙，失败了。

广开财路

除了来自于 APP 的直接收入，今年又多了几个收入来源，虽然不多，但是也是看到了其他赚钱的方法。
这些收入来自于 Youtube 广告、知乎致知计划、公众号流量主，可以看出来，这些都属于内容创作。与 APP 的被动收入不同，这些收入必须持续投入，不断产出新内容才可以维持收入。

YouTube 我今年只发了一个视频，不过这个视频也没有对收入有多少贡献，主要的贡献还是好多年前的一个视频。我是去年才开通了 YPP ，今年唯一一次打款是攒了一年才达到了打款门槛。知乎和公众号发的都是我的周记，知乎的收益只能靠浏览量产生的盐粒来兑换，今年也只兑换了一次。公众号这边的收入主要靠广告还有零星的打赏（今年的打赏比去年少太多的），周记写了将近三年，订阅数终于突破了一万，广告收入多的时候这个公众号的收益就相当于一个 20 万左右的货币基金。

买买买

查了一下今年给自己的消费记录，没有什么大的开销，超过一千块的只有下面几个，而且感觉都很物有所值，没花什么冤枉钱。

  • Apple Watch S10 ，趁着国补在京东官方旗舰店 1800+拿下的，应该是史上最低价了。
  • 电纸书，汉王 Clear 7 Turbo+，蹲了几个月终于在双十一拿下，为了颜值还多花了一点钱买的白色版。今年狂看悬疑推理小说，纸质书要买要等，看完了还出给多抓鱼，读电子版最方便，但是用手机和平板看太容易分心，老旧的 kindle 已不堪重用，所以十分需要一个开放系统的国产电纸书。自打买了以后几乎天天都在读，已经读完十本小说了。

  • 德龙全自动咖啡机，这是一笔冲动消费，当时受朋友影响，他买了个 2800 的耳机，我就觉得我也该买点什么提高一下生活质量。买完几天一直都是懊悔的状态，不是机器有问题，是我心里有问题，感觉这笔钱完全没必要。大半年用下来也还不错，可以不断买新豆子来尝试，也算是不断给生活带来新鲜感。

  • 荣耀平板，原来的小米平板 5 被孩子爷爷征用了，于是就买了个 13.3 寸的 MagicPad3 ，大屏就是爽，中午吃饭的时候我看电子榨菜，晚上老婆刷剧刷抖音，孩子上网课的时候也不费眼睛。
  • PS5 游戏，羊蹄山+死亡搁浅 2+刺客信条影，三个加起来也 1500 左右了，都白金了，值了。
  • 云鲸洗地机，换掉了科沃斯的扫拖一体机器人。之前每次清扫前先要给家里地上的东西都捡起来，而且有时候扫不干净第二次扫的时候电池就没电了，需要充两小时电才能继续清扫，还要时不时被地毯和桌腿困住，再加上加水和清理，清扫一次就要花半天时间，还给我折腾够呛。洗地机就不一样了，完全是人为操控，全屋拖一遍最多 15 分钟，方便太多了。
  • 今年疯狂想要买一辆小汽车，从油车看到新能源，特别是在免购置税政策的诱惑下，非常想拥有一辆自己的移动载具。但是因为车位、充电桩等问题，一直没有实际更进一步，就连唯一一次进入 4S 店，还是因为想要去看极简时钟在车载 Pad 上的样子才去的。后来动了买摩托车的念头，去驾校交完钱，结果体检没过，摩托车梦也碎了。趁着双十一的活动，还是买了人生第一辆新能源，一线大品牌，名字最后也是个“迪”，各项性能都十分满意，完美解决了交通问题。花费也是今年最大的一项，花了 3300 多。

另外有一系列开销，可能加起来还不足一千，但却是我今年花费心力最多的，那就是养了仓鼠，一儿一女。养过仓鼠的人都知道，笼子里的东西七七八八，最便宜的就是仓鼠本身（除非是名贵的波利）。这一年里这两个小东西给我带来了很多快乐，白天自己一个人在家也不再孤单了。

年终对账

先来看一下去年年终总结里的 Flag：

  • 减重 15 斤！必须完成！
  • MRR 达到 600 美元。现在是 500 ，花一年时间提高 100 ，应该可以达到吧。
  • 出三个新 App ，一个健康类，一个效率类，一个学习类
  • 继续完善 Nut Goals ，并用这个 app 存下一笔钱
  • 尤克里里能够指弹一首歌

来对一下吧：

  • 今年花了三个多月来实施 18+6 的轻断食（比 16+8 更严格），但是体重一直不降。今年上半年在家还有点运动，下半年就完全懒得动了。一年下来的断食还不如一次肠胃炎，一晚就掉了 5 斤……整体来看，没胖没瘦。
  • MRR 在三月份就达到了 600 美元，并且在之后最高达到 699 ，差点就够到了 700 ，可惜从那以后就一直下降了。
  • 健康类 App 就是上面的睡眠 App ，只停留在 demo 阶段。效率类 App 完全没有动手写。学习类 App ，就是上面提到的 Word Hack ，本来是想做个背单词的游戏化 App ，但是最终做成了游戏，也是三个里唯一一个正式发布的。
  • Nut Goals 修了个小 bug ，之后就再没更新。后来尝试用 Flutter 重写来上架安卓，但是只写了两个页面就搁置了。不过我最近产生了一个绝妙的功能，可以完美契合 App 的主题。
  • 尤克里里从下半年开始学习指弹，目前能够弹下来的就是简化版的菊花台，也算是完成目标了。

看下来连 50% 都没有完成，这样也不好再立新目标了啊。这么一看，年度目标太遥远太笼统了，前半年拖一拖，后半年就会发现根本无法完成。有志者立长志，无志者常立志，于是每年都这样，立了也白立。年度目标应该拆解为月目标和周目标，再加上进度追踪、励志提醒和专家辅导。

嘿，又一个 App 点子产生了！

写在最后

总的来说，今年很焦虑，大部分时间里是那种无能为力的感觉。

今年上半年参加了独立开发者线下聚会，确实大开眼界。从那之后，我打算每周都找一个独立开发者进行线上聊天交流，但是只聊了五个人后就搁置了。希望 2026 年能够向更多的开发者请教，特别是岁数比我大的。

唉，马上就四十岁了，希望可以不惑。

最近在开发 Flutter，由于是新项目，就想使用 Freezed 格式的实体类，但是试了试 vscode 中一些已有的扩展，都不太好用，就决定自己编写一个扩展来满足要求，在 claude 和 codex 的帮助下实现的目前需要的主要功能。目前仅支持 Freezed 格式的实体类，就开放出来，有喜欢的佬友可以试试。(已上架 vscode 扩展商城)

用 AI 做了一个 vscode 的 JsonToDart 的扩展1


用 AI 做了一个 vscode 的 JsonToDart 的扩展2


用 AI 做了一个 vscode 的 JsonToDart 的扩展3

注意如果需要使用 Freezed 格式的实体类，仅在 Flutter 项目中支持，在 Flutter 项目中任意文件夹点击右键，选择 JsonToDart (Freezed) 选项就会出现配置界面，同时需要在依赖文件里面配置如下的类似内容，版本不一定需要一致。

dependencies: flutter: sdk: flutter freezed_annotation: ^3.1.0 json_annotation: ^4.9.0 # The following adds the Cupertino Icons font to your application. # Use with the CupertinoIcons class for iOS style icons. cupertino_icons: ^1.0.8 dev_dependencies: flutter_test: sdk: flutter flutter_lints: ^6.0.0 build_runner: ^2.10.4 freezed: ^3.2.4 json_serializable: ^6.11.3

点击生成后会自动生成如下的文件

用 AI 做了一个 vscode 的 JsonToDart 的扩展4


文件内容大概如下

用 AI 做了一个 vscode 的 JsonToDart 的扩展5

首次使用插件生成代码会自动生成如下文件
用 AI 做了一个 vscode 的 JsonToDart 的扩展6
内容预览如下，里面有几个基本类型的转换器。

用 AI 做了一个 vscode 的 JsonToDart 的扩展7

项目源码 github 地址：GitHub - wqjuser/GFDMFJFF

📌 转载信息
原作者：
wqjplayer
转载时间：
2026/1/7 19:26:54

Kelivo

━━━━━━━━━━━━━━━━━━━━

基于 Flutter 的 LLM 聊天客户端，支持多平台与多家模型 / 供应商

━━━━━━━━━━━━━━━━━━━━
开发者：@17Xtreme

官方 GitHub 地址

声明：本人非项目开发者，仅作推荐分享

━━━━━━━━━━━━━━━━━━━━

核心特性

① 界面与体验

Material You 风格
动态主题色（Android 12+）
深色模式
多语言（中 / 英）
Markdown 完整渲染：代码高亮、LaTeX、表格等
自定义字体（系统字体 / Google Fonts）

② 模型与供应商

支持多供应商：OpenAI、Google Gemini、Anthropic 等
支持创建 / 管理自定义助手
提示词变量：支持模型名称、时间等动态变量

③ 输入与多模态

支持图片、文本文档、PDF、Word 等多种输入格式

④ 工具与扩展

支持 MCP（Model Context Protocol），内置 fetch MCP 工具
网络搜索集成：Exa、Tavily、Brave、Bing、SearXNG、Jina、Perplexity、Bocha 等

⑤ 语音功能

内置系统 TTS
支持 OpenAI / Gemini / ElevenLabs 语音服务

⑥ 数据与配置

二维码分享：导出 / 导入供应商配置
聊天记录备份与恢复
自定义 HTTP 请求头与请求体

⑦ Android 特性

支持后台持续生成对话（可在设置中开启）

━━━━━━━━━━━━━━━━━━━━

平台支持

▸ Android
▸ iOS
▸ Windows / macOS / Linux

━━━━━━━━━━━━━━━━━━━━

📌 转载信息
原作者：
itwangyou
转载时间：
2026/1/5 15:57:59

首先是 Chrome ，默认不支持 Wayland, 强制使用后发现输入法不能用，搜索后得知需要使用 gtk4

--enable-features=UseOzonePlatform
--ozone-platform=wayland
--gtk-version=3

这样 fcitx5 能用了，不过候选词的那个框框位置不对，并且浏览器多了些毛病，不能右键下载图片，上传图片报错等等。Firefox 表现完美，可我的主力是 Chrome 。

Flutter 完美支持是意外之喜，除了 AndroidStuido 需要跑在 Xwaylany 上。
折腾好久尝鲜了 Hyprland，小问题一堆，但基本上属于能用了，遇到的一些问题供参考
vscode 和 Chrome 一样的毛病，使用相同的配置之后在我的机器上打开就 crash ， 暂时没找到解决方法。只能按照官方的建议跑在 Xwayland 上然后强制放大 UI,放大倍率只能是整数，在我这个分辨率上就很尴尬——原始的太小，2 倍又太大，显示不了多少东西。
折腾好久尝鲜了 Hyprland，小问题一堆，但基本上属于能用了，遇到的一些问题供参考1
一些软件多少有适配问题，有些可能永远都不会支持了，比如说 w3m 用不了，ranger 看不了图片。 我还发现 GLFW 有奇怪的问题，Wayland 上拿不到正确的 FrameBuffer 大小，官方的 issues 也没有明确的修复计划，导致 viewport 总是只有窗口的 1/4 。

折腾好久尝鲜了 Hyprland，小问题一堆，但基本上属于能用了，遇到的一些问题供参考2