让你见识见识 “Hello, World!” 的威力
呃…为啥我编译HelloWorld不算pdb文件只有6KB呢…(加上pdb文件总共26KB)
1 个赞
这是自带运行时的呀
net6的优点或者说是缺点
可以打包为不依赖运行时的(就是附带一个运行时) 150+MB
也可以打包依赖运行时的 也就是你的那种,别人要运行要去安装运行时
还有打包成单个文件的
附带运行时就是因为net6不像net4系统自带,它的安装率没那么高(应该说很低很低)
所以大部分软件都会推出 依赖和不依赖的两个版本
普通用户安装多个net软件时应该会选择不依赖运行时吧(大概?)
这样就导致了结果就像electron那样,一个软件带一个浏览器…
比electron好的一点就是它提供了运行时,可以避免这种情况
但很难说服用户去安装…
造成这样的原因上面有人说了…
我忽然意识到普通人看超大图也就地图了
地图处理策略是分块渲染降低硬件压力.
但是压缩后的普通的超大图像放大看肯定只能先解码到内存里
所以除非看bmp,其他图片没辙
明白了，看来对用win10普通版的用户来说，基本不用关心.net版本问题。
我倒从来没见过两种都发布的，微软自己的产品有只能依赖的也有只能不依赖的，比如 PowerToys 只能依赖，安装包会自动安装，而 Your Phone 和 WinDbg 就是自带（可能是因为 MSIX），PowerShell 似乎能依赖，但官方提供的安装方式只有自带，我遇到的个人开发者的软件都是依赖的，毕竟分发上百 MB 的软件并不方便，让用户自己安装 .NET 也没多困难，而且简单弄个安装包（比如用 Advanced Installer）就可以兼顾体积小和安装方便了。
如果提供两个版本的话，我觉得他们大概率会直接选体积小的，然后发现运行不了再去问。
补充一下，Hello World 打包的初始体积应该是 60 MB，做了死代码移除后可以降到 10 MB，不过这样会影响反射。如果再叠加上 NativeAOT 的话可以降低到 1 MB，已经比 Go 还小了。如果再极限一些，最低可以降到 5 KB，这个体积应该是持平甚至优于 C++ 的，虽然因为牺牲特性太多，没什么实际意义。详细可以见这篇文章。
安装包这么大，确实有点心虚，发布的话流量成本也会高不少。
不知道通过 <TargetFrameworks>net6.0-windows;net472</TargetFrameworks> 这种方式编译多个版本是否可行？.net6 相对于 framework 性能提升大么？如果不大的话，综合来看还是Framework更合适点了。
远没到发布的地步呢
自娱自乐的东西
暂时被BUG折腾得快麻木了
Debug时无论如何都是正常的
正式运行时突然就多出一个句柄锁定文件
测了好久才发现是工作目录这东西锁定了…
用改变工作目录的方法暂时屏蔽了
至于性能
宣传满天飞
我在乎的是它宣传的启动速度和IO
这对即用即关的图片浏览器比较重要
我也不知道它到底是真提升还是像Chrome那样一个版本提升30%那种吹.
就当它有吧,总不至于是降低体验
目前处于被多线程搞昏头的阶段.
你是用MPV 修改了个图片浏览器，还是从头写了一个？
修改 MPV 大有搞头啊，不要放弃，我等着用你的版本呢。
C#有启动速度可言？
多线程，搞定访问冲突和安全锁就行了。
启动速度还是有点慢
所以弄了单实例
这样就可以假装关闭实则隐藏至后台
目前这样的"启动速度我还算比较满意的"
https://s1.328888.xyz/2022/08/19/Bm4rX.gif
多线程现在最主要的问题是优先级…
这个我目前是没优先级,就让它自动调度
目前的问题是当前浏览的图片加载的线程可能抢不过预读的线程
搜了一下也没啥好办法
弄了半天结果第一张图片加载的速度好像更慢了.
图片浏览器是单独的,很简单的
wpf 一个 image 控件,剩下的写逻辑就行了…
至于修改mpv net嘛.算不了什么, 大部分功能lua脚本都能实现
少部分lua脚本不能实现的比方说关联带图标,加载同类型以前我用AHK都实现过
这次只不过集中弄一下.
后续可能也没啥好改的了
分享了成品,感兴趣的话自己测试下吧
WPF能调用GPU吗，不然性能还是不行。
这单进程加载，是用鼠标手势将图片路径发送到浏览器吗？从出现鼠标漏斗看，还有很大提升空间。
我写过一个简单的多线程的。一个线程显示当前，一个线程扫目录，然后用两个线程向前后预读。
在预读前会给图片路径加个"预读"的状态，显示线程开始显示一个图片时，会检查路径状态，如果正在预读，那么等待预读完成再加载。
WPF 本身就是用 DirectX 实现的，自带控件性能不行的话可以用 API 自己画。
框架这种东西就是用它给的东西…
别说GPU. 操作DirectX都很难…
另外我搜索过GPU相关的图片浏览器,没找到主打这个功能的,涉及到的都少
倒是github c# image viewer 星数最多的 ImageGlass 最新的测试版支持
但就我测试来说效果也不怎么好…
扫目录不是问题,非常非常快,3W多图片的文件夹扫一遍排序也要不了多久
多线程的问题是
当前浏览 图片1, 后台加载图片2-10
快速往后切的时候比方我瞬间切到第11张图片
你前面加载的怎么办…
在这里我加了大量的判断,每预读一张都要判断一次,然后让前面的不继续加载了
但已经在加载的就没办法,至少得等一张加载关闭
当然也可以在此时开一个新线程去加载第11张
这就会有我上面说的东西…它的优先级不受我控制,我没办法让它优先执行
它会受到后台预读线程的影响
有取消后台线程的方法,但取消的逻辑也很复杂
在大图的情况下这种情况就特别严重了…
说下鼠标漏斗的问题
无论用什么图片它都会出现
无论是我这个还是我原来用的JPEGView还是你用的Honeyview都会出现
不是将当前图片路径发送到图片浏览器
就是启用一个新实例,然后新实例发消息给原来的实例,然后退出新实例激活原来的实例…
就是双击打开…
图片显示这块GPU作用还是很明显的，堪比游戏CPU/GPU的差异。
从图1跳到11，挂起正在预读2的线程，视图片大小判断是否清除。
同样视图片大小判断预读数，如果都是小图片，同时预读15个，跳到11也没问题了。
有线程池，当然也可以有进程池，预载大量空白进程。
咱这种自用软件，讲什么武德，图片可以预载，进程也可以，比如我系统就加载了十几个空白AHK进程。(调用一个新脚本可以实现微秒级)
然后鼠标手势发送路径给空白进程，解决漏斗问题。
我这鼠标手势垃圾的很…
一次成功的手势需要100+ms
发送路径的前提是执行一个复制…
干扰剪贴板(我这每复制一个内容都会提示)
且与新打开一个文件的逻辑不同(我到底是要复制还是要打开?)
与之相比我选择接受漏斗…你不说的话我可能没注意到
线程的问题我目前还在头疼中,我会参考下你的意见.
如果你不是做手机版，这么在意手势操作干嘛？还是你想做跨平台的，鼠标我反正很少用手势，
另外给你一个提示，acdsee这种看图软件，都是先生成缩略图的，
我之前也想做一个看图软件，后面觉得acdsee已经可以了，
市场还有很多替代品，比如xnview，
但是还是支持你，做得好的话，还是有人需要的。
软件没手势操作啊…
这是另一个软件的功能…
全局关闭窗口都是这一个手势
和当前软件是无关的…
事实上dotnet的各个组件都可以自带的。
总比Electron强 