sujin190

那分享下之前做的项目吧： https://github.com/snower/jaslock-spring
有令牌限流 TokenBucketFlow 实现，性能肯定够用，我们自己项目也再用

非 spring 的原始 java driver: https://github.com/snower/jaslock

需要用服务端： https://github.com/snower/slock 也支持高可用部署，支持多核，性能不够加内存加机器 cpu 核心就好了

@SeaTac #47 时间直接就变了啊？！！我还以为只是修改作息，时间不变，比如夏令时 9 点上班，冬令时 10 点上班，直接调时间感觉好坑好难受

互联网公司用的很少，ToB 商业项目还是有不少人用的，总的开发者和企业用户群都小很多，而且很多客户端需求也可以用网页平替，撑个 15 年肯定没问题，ToB 业务不是那么容易消亡的

其实这种还是使用 long polling 轮询实现更简单快捷，搞个异步 IO 的框架，挂起实现不要太简单

@janus77 #50 而且 avalonia 也完全支持和 wpf 一样的 await 调度逻辑，搞过 wpf 就知道，c#的这个 await 调度逻辑相比安卓 kotlin 什么的好用太多了，不过就是.net 这个 await 底层的线程调度器设计的是有点坑的，也不知道微软是咋想的，顺便说也不知道哪个大聪明设计的这个 kotlin 协程语法，写起来麻烦不说还破坏代码逻辑而且还不能自动处理和 UI 线程的交互

@shunia #55 移动端页面层级简单交互逻辑很浅，xml 确实没啥优势，不过 PC 端层级复杂，交互逻辑更深的情况下，还是 xml 布局更清楚有优势

@janus77 #50 是的，出发点本来就是开源替换 wpf ，wpf toB 用的人还是很多的，qt 虽然出了很多年了，但是说实话如果搞 toB 大型项目真是天坑，这么多年了，虽然搞了 qml 但是还是没办法和 c++代码直接双向绑定，而且国产话龙芯什么的 qt6 问题真不少，electron 之类的我们好像之前搞过，但是 toB 项目操作复杂，处理的数据量非常大，直接卡死，否则就要弄 native 扩展优化性能也是天坑，而且 c#商业项目其实有不少专做商业组件的公司的，也大多都选择了支持 avalonia

手机端的话毕竟用户群和社区还不行，而且现有的大部分 ui 组件都是客户端的，原生 API 的支持估计也不完善，确实有待发展，不过绘图毕竟统一又直接调用 opengl 绘制不适用原生组件，UI 的一致性和性能估计也有保证

avalonia 相比 flutter 还有就是.net 语言更完善了生态更好，非 UI 相关的大量第三方库是可以直接用而且也被验证过了，毕竟大微软搞了这么多年，以后估计也不大可能放弃

@janus77 #38 差别很大，Xamarin 看下底层还是使用各平台的原生组件，这种问题太多了，性能也不行，一致性也很差，ui 原生组件的差异会引入更多问题，开发大型项目就是天坑

avalonia 则是和 flutter 一样的完全是使用 skia 自绘制的，性能更好，问题更少，开发更方便，安卓和 ios 和 flutter 一样同样是单 activity 自绘制，web 则是整个页面一个 canvas 完全自己绘制组件，直接使用 skia 调用 opengl 自绘制所有组件一致性、性能 flutter 大家相比都知道了，avalonia 在这一点上从设计结构、代码质量、性能上来说一点不差

而且受益于.net 的语言支持，数据绑定、样式处理都很方便，而且相比 pdf 说，虽然界面样式仍然追随 wpf 一样使用 axaml 来编写，但是 avalonia 自己编写了编译时插件，完全在编译时把 axaml 中的 xml 编写的界面样式文件编译为了 c#代码最后在编译为了 clr ，运行时性能完全不比 flutter 的代码构建的界面样式差

@twig #14 avalonia PC 端确实完成度很不错，整体设计也很可以，我们项目算是比较大了迁移也还算顺利，性能超出预期，win macos uos kylinos 表现可以说完全一样，现在完成 win11 和 win10 x86 架构，macos arm 架构，uos 龙芯架构，kylinos 海思 x86 架构测试，win7 的话安装了也正常运行了，而且.net8 支持打包 publish 的时候自包含运行时，所以打包发布安装的时候并不要去必需先安装.net 运行时，所以有搞 tob 业务有客户端又有跨平台需求首选 avalonia 肯定可以