代码 > 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.中文环境稳定性存疑

留个记录,看最后怎么选的。

代码 > 使用musl代替gcc进行go语言的cgo编译

2022-07-29

最近在发布go代码的时候遇到一些问题

主要是集中在linux版本的gcc上的。

总的来说,gcc的问题有以下几点

1.协议问题,mit协议的代码静态编译gpl的库总觉得有点问题

2.libnss问题,由于gcc本身的特殊性,libnss不能静态编译进去,不然会有各种报错(比如dns解析时panic)

3.glibc版本不匹配问题。

所以换使用musl进行编译。

总体来说,musl提供了一个musl-gcc协议,总体更新跟着不多的文档还是很方便的。

就是各种dev包里一般提供的是glibc编译的版本,之间使用会报错

需要用aptitude source下载代码包

然后通过CC="musl=gcc" ./configure的方式手动编译,得到.a文件,再通过编译脚本以的LDFLAGS中 以-L指定进来。

其他没啥问题,接下去就要进行稳定性测试了。

代码 > Godot到导出wasm过大问题

2022-05-04

研究了下,这个基本无解。

标准是20mb左右

进行功能裁剪后重新打包也有16mb+

通过预压缩可以到4mb左右。

所以,还是只适合大型场景,不适合小场景。

毕竟 Godot功能太强大了吧。

在网络流量和带宽大幅度提速下降之前。

应用godot还是有一定的成本的。