关于MewUI的跨平台测试（windows、linux；X86、ARM）
最近碰到几次推荐MewUI，本着试一试心态，在多个软硬件环境中做了下测试。
MewUI是一个轻量的跨平台UI框架，支持AOT，（相比Avlonia声称更加轻量，使用Markup形式，不支持XAML之类的描述和可视化UI，生产体积会更小）。
这个项目目前一直在更新，在使用的时候，有些比较低级的坑需要踩。
首先下载发布版本中最新版（0.15.2）进行尝试，主要考虑Release会更稳定。
第一个坑开始，就是运行官方示例“MewUI.Gallery”报错方法缺失。（Slider().Range()）
刚开始以为自己问题，反复编译尝试，还是不对。
于是乎直接下载master分支的最新代码，再次尝试，这次正常了。对比了下代码，主要是0.15.2中有代码缺失。
（补上上述代码后，就会正常。考虑可能有其他问题，还是直接用Master代码）
这个是默认运行效果，整个demo效果确实不错。
windows下支持三种Backend，包括Direct2D，GDI，NanoGV；这边用了Driect2D界面很流畅；GDI也能正常工作，但是帧数会略低；使用NanoVG(基于OpenGL)时，帧率比Direct2D低一些，而且查看GPU占用明显要高于Direct2D，可能是OpenGL优化略差导致的。
也试了下AOT，Gallery这个demo大概AOT后的体积在7M左右，这个大小确实比Avalonia要小不少，Avalonia之前最简单的一个测试程序体积也来到了20M的样子（单窗体只有单个Botton，没有MewUI的demo复杂）
AOT编译命令：
这里AOT后，native目录下程序是不能直接启动的，双击后无响应。
后台查看日志
看日志，明显就是文件缺失了，缺失“Rescouces”目录和里面的图片文件，这个需要手动从native外部拷贝进来。
至此，windows平台AOT算是正常完成。
这边有x86的linux的主机（测试大模型的PC），也顺带试了一下，又出现了第二个小问题。
编译命令：
dotnet publish samples/MewUI.Gallery/MewUI.Gallery.csproj -c Release -p:PublishProfile=linux-x64-trimmed
报错：
经过一番细看，是Master分支下“MewVGGlOffscreenSurfaceProvider.cs”文件命名问题。
“MewVGGlOffscreenSurfaceProvider.cs”这里面的l是用的小写，但是项目中使用的是大写，包括代码中也是大写。
windows不报错主要是文件名大小写不敏感，但是linux下就会因为大小写敏感编译不过，提示找不到文件。
修改文件命名后，linux下也编译正常，后续相对顺利不少。
PC上运行这些桌面Demo没有什么性能挑战，干脆就直接看下嵌入式方面能不能工作。
拿出了自己之前咸鱼淘的RK3568的Arm板卡，进行测试验证。
（商家图）
这个板卡应该是希沃录播机的主板废案，一些板卡就通过二手市场流通出来了，主控Rk3568，2G内存，32G ROM。
AOT不能直接跨环境进行编译输出，需要对应的框架硬件、系统上编译。
（编译后的程序也会受GLIBC的版本限制，其他同架构不同系统版本生成的程序拷贝到其他环境也会出现版本不匹配报错，这边在DGX Spark上编译的demo拷贝到这个板卡上运行就有这个问题，但是spark编译确实快。可以通过docker或chroot解决编译环境导致的libc版本依赖问题）
代码拷贝到板卡上面后，进行编译。
（直接拖拽拷入，比较方便）
编译命令：
dotnet publish ~/projects/MewUI-main# dotnet publish samples/MewUI.Gallery/MewUI.Gallery.csproj -c Release -p:PublishProfile=linux-arm64-trimmed
编译过程十分缓慢（4核A55的编译性能实际很一般）
漫长10多分钟过去后，总算编译完成。
运行使用了板卡的显示器输出（使用最右的第三个hdmi，其他接口暂时好像不能用），这边直接使用了绕开桌面的终端直接运行。
运行命令：
xinit ~/projects/MewUI-main/samples/MewUI.Gallery/bin/Release/net10.0/linux-arm64/native/Aprillz.MewUI.Gallery -pos 0,0 1920,1080 -- :1
发现运行后显示器只有中间区域显示，无法铺满显示屏。
需要修改代码改变界面的显示大小来适配1080P的显示器
代码修改：
最终显示器被点亮，显示界面如下：
插入鼠标后，可以与UI进行正常交互。但是这种启动模式绕开linux桌面后，Demo中系统弹窗部分菜单不会工作，而且打开文件浏览窗口也不会生效（也应该是调用的系统桌面的功能）
简单体验了下，操作还是没有pc那么跟手，不知道是cpu太弱，还是这个板卡GPU驱动不完善。回退到默认1356*720大小后（未铺满屏幕情况下），反而流畅度能较大提升。
用来做一些简单的HMI之类的功能，这些默认组件功能应该是绰绰有余了。
如果涉及一些录入问题，可能就比较麻烦，特别是要支持触摸录入，没有对应的软键盘适配，应该还是比较麻烦的。
.net Aot实际拓宽了.net在很多场景的应用，如果用来做嵌入式交互，感觉开发效率应该能胜出QT。
另外近期也看到有个老哥在nuttx系统+.net Aot实现MCU上的运行（ST M7方案），这个有空看能不能搞个板卡也体验下。
----------------------20260520----------------------
附带补充下Win7测试
win7默认直接运行windows编译的程序，运行起来会是空白，应该是Direct2D渲染在win7下不能兼容。摸索了下，需要加参数启动来指定兼容的后端。
指定运行在GDI、MewVG（opengl）后端上。
GDI模式启动：Aprillz.MewUI.Gallery.exe --gdi
MewVG模式启动：Aprillz.MewUI.Gallery.exe --vg
其中GDI模式纯粹依赖cpu来渲染，开末尾的彩蛋特效，cpu占用会比较高。使用MewVG就会好很多，会调用显卡来渲染。
----------------------20260525----------------------
在Seawo sv21 RK3568的嵌入式板卡上移动鼠标UI动效卡顿问题应该找到了，是板卡的cpu频率调节失效导致的，频率被锁在了816M Hz，这个板卡本来不是官方linux固件，配的Armbian固件上有些缺陷，这样性能受限情况下鼠标移动会导致Xorg进程直接拉满cpu。目前编译缓慢的问题，估计也是一样的问题，性能受限了。
---------------------20260526-----------------------
优化了设备树，解决了板卡频率调整问题，cpu性能算是正常了些，编译时间少了不少，但对于AOT编译来说还是慢。
界面交互鼠标响应好了一点，但是就只好了点，感觉还是容易卡顿，待后续继续研究。
浙公网安备 33010602011771号