代码 > 修正flutter升级3.10升级到3.22后渲染出的问题
2024-05-22
具体来说，由于我的代码是按文字行渲染然后缓存的，发现部分行在linux桌面会随机丢失，统一版本mac os x 无此问题。
目测是异步没及时渲染成功的问题。于是调整了下代码。成功修复。
从
await recorder.endRecording().toImage()
调整为
recorder.endRecording().toImageSync()
问题解决。
基本是这个异步方法的问题。不知道是渲染问题，还是库的问题。
代码 > 使用了下清华开源的ChatGLM2-6B
2024-03-25
作了些简单的修正，轻松的架上了。
不得不说，还是有点东西的。
至少简单的文案能高个框架出来，感觉还是能解放点生产力的。
实际效果肯定不能和chatgpt比，但chatgpt肯定也不能在我的3060上跑阿。
不知道能否继续定制和学习，如果能方便的定制和学习的话，的确是非常不错的生产力工具。
代码 > flutter中强制Statefull子元素更新
2023-11-22
为了效率，flutter的setState是只更新依赖当前State的Widget的，维护自己独立Widget，通过listen event独立更新的子Widget是不会因为setState更新的。
但有时候整个Widget的刷新是必须的，一层层向下Bind Event是不可接受的。
这时候可以通过setState更新父元素的key来实现。不同的key的父元素代表不同的组件，自然会重建了。
元素添加一个属性
var _refreshKey = UniqueKey();
build时指定key
return RawKeyboardListener(
key: _refreshKey,
需要时重设key
setState(() {
_refreshKey = UniqueKey();
});
就能替换整个组件树了。
代码 > flutter中自适应缩放窗口
2023-11-21
做网页有个常见的偷懒方法，网页中设置一个最小宽度，这样手机浏览器小于这个宽度时会自动缩放。
flutter里用FittedBox实现这个功能
minWitdh是最小宽度。
height可选，不填写根据父元素约束的maxHeight计算
import 'package:flutter/material.dart';
class Fullscreen extends StatelessWidget {
const Fullscreen(
{super.key, required this.child, required this.minWidth, this.height});
final Widget child;
//fixed raw widget height
//Use constraints.maxHeight if null.
final double? height;
final double minWidth;
@override
Widget build(BuildContext context) {
return LayoutBuilder(builder: (cotext, constraints) {
Widget body = child;
final widgetHeight =
height jQuery33100915512005582535_1700544202060 constraints.maxHeight / constraints.maxWidth * minWidth;
if (constraints.maxWidth < minWidth) {
body = FittedBox(
fit: BoxFit.fitWidth,
child: SizedBox(
width: minWidth,
height: widgetHeight,
child: child,
));
}
return body;
});
}
}
代码 > flutter 感受4
2023-11-17
昨天折腾到3点，才把app架构理顺了。
flutter刚建立好的代码很有诱惑性，似乎一个app应该是树状结构。
实际并不是。
Widget本质不是树，只是一片叶子。负责渲染部分。
state更只是 当前页面的 显示用数据，只是一个vm。
APP本身必须组件一个自己的业务系统。
业务系统是全局的静态对象，随着应用进入进入，随着应用退出退出。
提供各种Listenable供Widget绑定接受数据(ViewModel)。
调用服务器数据更新自己的业务内容(Model)
本来说runApp就是buidui,不该当作入口，而应该是业务系统负责调起的一个显示子系统。
代码 > flutter感受3
2023-11-14
初步把界面渲染做出来了。怎么说呢，感受比较复杂。
第一，最大的优点是dart的语法/思路与js比较一致，很多代码可以直接复制。
第二，太过mvvm。对于要直接渲染界面并不友好。
第三，asyn/await的异步其实有点没那么好用，加起锁来相对比较复杂，异步编程还是比go废脑筋一点。
第四，语法糖太多。
目前界面渲染是按行把文字渲染成canvas,转picture再转Image
把所有image都缓存着，需要更新时paint到一个picture里，进行全局缓存。
这样能提升不少性能。
然后async/await再这里遇到了些小问题，直接暴力加锁解决。
毕竟加锁的代价的数量级，和渲染差了无数个数量级，遇事不决，直接加锁。我就是阳光菜鸟大男孩。
代码 > flutter感受2
2023-11-13
尝试用Fluttter给Hellclient做桌面/安卓的UI端。
怎么说呢。
flutter感觉挺像react。
用来做mvvm的数据<=>界面映射很不错。
真的要动手在canvas上渲染还是挺蛋疼和麻烦的。
代码 > flutter 感受
2023-08-08
1.和Javascript的Mvvm框架比较接近的开发体验，上手不难。搞清了下state归属，多写几个组件import以后，也没啥嵌套地狱
2.比较蛋疼的语法，特别是字符串里的${}，梦回shell
3.组件非常丰富。
暂时感觉还ok,继续使用，看看效果
代码 > 还是决定选择flutter Desktop了
2023-08-04
上一篇日志还在犹豫。
现在基本定下来了。
AvaloniaUI说来说去还是一个缝合技术。
引擎上依赖于被Google收购的skia。
语言上依赖于微软的.net，还和微软的maui竞争。
框架基本上很难在任何一家有话语权。
同时，提供的开发插件仅有jb的rider和vs的。
对于flutter的 VSC和Android Studio支持，对非win平台的模式和技术能力的限制可以说跃然纸上。
最大的有点是.net。
如果有大量.net核心代码的话肯定不错。
但我有吗？并没有。
所以就很简单了。
用Fluttter desktop,学dart。
尽可能学的浅，当vue用。
真的有啥专注性能和系统的需求，说不定号直接上QT了呢？
浅学，易学，才是王道。
代码 > 选型:flutter Desktop or AvaloniaUI?
2023-08-02
面临一个自己的玩具项目的选型。
需要做一个跨平台(Windows/Linux/Android/Ios)的应用程序。
根据实际情况排除的七七吧吧，无非剩下了 Flutter Desktop或者 AvaloniaUI
Fltter Desktop做过一个简单的试手Demo。
优势:
1.大厂支持
2.不少成功案例(企业微信桌面版？)
3.Linux开发工具优秀(android studio/vscode)
缺点:
Dart
AvaloniaUI用过Lunacy。
优势:
1. c#,更好的代码复用
2.桌面方案更稳定
缺点:
1.微软的砍技术恶习
2.中文环境稳定性存疑
留个记录，看最后怎么选的。