在两个月前，我们就聊过 3.29 上《Platform 和 UI 线程合并》的具体原因和实现方式，而事实上 Platform 和 UI 线程合并，确实为后续原生语言和 Dart 的直接同步调用打了一个

最近我上班的公司提出一个新需求，要求把公司产品的移动端APP的所有查看功能在半个月内移植到小程序上，涉及几十个页面和很多复杂业务逻辑，于是开始了下面的故事。

业务层 业务层我采取的是借助MVVM（Model-View-ViewModel）模式 ，定义抽象类BaseViewModel帮我统一管理ViewModel，定义抽象类BaseWidgetPage帮我统

前言 Flutter打包不同于RN，Flutter可以在Android Studio里编写Flutter代码并最终打包为APK，本篇主要阐述涉及到的几种打包方式。 通过本篇文章，你将了解到： 1. A

起因 每隔一段时间，都会出现一个新的状态管理框架，最近在YouTube上也发现了有人在推signals, 一个起源于React的状态管理框架，人们总是乐此不疲的发明各种好用或者为了解决特定问题而产生的

在上一篇《Riverpod 的注解模和发展方向》里就有很多人提到 signals ，对比 riverpod 部分人更喜欢 signals 的 “简单”和“直接”，那 signals 真的简单吗？再加上

三年前我们通过 《Flutter Riverpod 全面深入解析》 深入理解了 riverpod 的内部实现，而时隔三年之后，如今Riverpod 的主流模式已经是注解，那今天就让我们来聊聊 rive

在 Flutter 3.29 版本里官方正式移除了 Flutter Gradle Apply 插件，其实该插件自 3.19 起已被弃用，同时 Flutter 团队后续也打算把 Flutter Grad

在 Flutter 里，Key 对象存在的目的主要是区分和维持 Widget 的状态，它是控件在渲染树里的「复用」标识之一，这一点在之前的《深入 Flutter 和 Compose 在 UI 渲染刷新