代码重构和系统兼容性改进建议

Nukepayload2 commented 6 years ago

我粗略地阅读了这个程序的源码，并对它有了一定了解。从中我看出了一些显著的问题，会阻碍今后的软件维护。

应用架构设计问题

这个软件是 Code Behind 模式的 WPF 应用，并且代码长度已经有一定规模了。这种情况下应当考虑选择使用 Mvvm 模式重构代码。Code Behind 模式将逻辑、数据结构与 UI 代码混杂在一起，按理说这样的写法应当仅存在于原型制作阶段（急于看到第一个成品），而不应该在软件有一定规模的情况下使用。

纯托管化改造

Windows 10 要出 ARM64 版本了，而这个项目包含一些本机 C++ 动态链接库。这种混用非微软提供的本机动态链接库和托管代码的方式会阻碍应用程序今后的移植工作，或者在 ARM64 设备上大幅降低性能。有关如何使用托管代码重写弹幕窗口，可以参考 http://sharpdx.org/wiki/class-library-api/directcomposition/

针对平台的自适应代码

我注意到一些选项是不应该留给用户去选择的。比如说 Direct Composition 弹幕渲染模式。这个模式应该在 Windows 8 或更高的系统自动打开，在 Windows 7 自动关闭。如果这个设置被误用，会对游戏主播带来困扰。目前这种优化的渲染技术被证实是稳定的。因为 Windows 商店上大多数应用在用这种渲染机制，它们没有因为绘图 API 有问题而出现诡异的行为。反倒是使用旧式绘图方式 (LayeredWindow) 的软件容易出问题。

自定义缩放支持

如果你的应用目标 .NET Framework 版本低于 4.7.2 Preview, 那么你的 WPF 应用是没有针对每个显示器的 DPI 感知功能的。这样如果用户更改缩放比例或者使用远程桌面，你的应用会变得模糊。在这方面我研究过怎样在低版本实现逐监视器 DPI 感知，可以看看我的仓库 https://github.com/Nukepayload2/WPF_Borderless_Window/ 里的 Demo，并在 Nuget 上安装我帮你们编译好的类库。

Nukepayload2 commented 6 years ago

顺便提一下，我现在工作的公司是会卖 WPF 控件的。不必担心我提出不合理的建议。

copyliu commented 6 years ago

你的建议我都接受, 以下回复:

架构问题: 如你所说, 现在的写法理应只存在在原型阶段, 暂时还没觉得此软件的规模已经到了无法维护的地步. 会另开一个issue坑着先.
纯托管改造: 你说的方案需要sharpdx, 我不希望弹幕姬存在更重的引用, 而且由于代码签名证书过期并不再续费也无法续费, 添加更多引用只会导致更多的部署问题比如某杀毒软件定时删无签名的dll文件之类的,也会导致软件下载大小激增.
针对平台的自适应代码: Direct Composition 弹幕渲染模式经过有一段时间的实装, 确实已经一定程度上证实了其稳定性, 会考虑下个功能改进或修复bug时拿掉这个选项.
高DPI支持: 等我入手高分屏之后我才会重视这个问题(如同多屏显示支持那样).

在 2018/3/26 21:38, Nukepayload2 写道:

我粗略地阅读了这个程序的源码，并对它有了一定了解。从中我看出了一些显著的问题，会阻碍今后的软件维护。

应用架构设计问题这个软件是 Code Behind 模式的 WPF 应用，并且代码长度已经有一定规模了。这种情况下应当考虑选择使用 Mvvm 模式重构代码。Code Behind 模式将逻辑、数据结构与 UI 代码混杂在一起，按理说这样的写法应当仅存在于原型制作阶段（急于看到第一个成品），而不应该在软件有一定规模的情况下使用。

纯托管化改造 Windows 10 要出 ARM64 版本了，而这个项目包含一些本机 C++ 动态链接库。这种混用非微软提供的本机动态链接库和托管代码的方式会阻碍应用程序今后的移植工作，或者在 ARM64 设备上大幅降低性能。有关如何使用托管代码重写弹幕窗口，可以参考 http://sharpdx.org/wiki/class-library-api/directcomposition/

针对平台的自适应代码我注意到一些选项是不应该留给用户去选择的。比如说 Direct Composition 弹幕渲染模式。这个模式应该在 Windows 8 或更高的系统自动打开，在 Windows 7 自动关闭。如果这个设置被误用，会对游戏主播带来困扰。目前这种优化的渲染技术被证实是稳定的。因为 Windows 商店上大多数应用在用这种渲染机制，它们没有因为绘图 API 有问题而出现诡异的行为。反倒是使用旧式绘图方式 (LayeredWindow) 的软件容易出问题。

自定义缩放支持如果你的应用目标 .NET Framework 版本低于 4.7.2 Preview, 那么你的 WPF 应用是没有针对每个显示器的 DPI 感知功能的。这样如果用户更改缩放比例或者使用远程桌面，你的应用会变得模糊。在这方面我研究过怎样在低版本实现逐监视器 DPI 感知，可以看看我的仓库 https://github.com/Nukepayload2/WPF_Borderless_Window/ 里的 Demo，并在 Nuget 上安装我帮你们编译好的类库。

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/copyliu/bililive_dm/issues/22, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBtoFxOqUzr46S4xrHkjjv6gj7v-NIzks5tiO9IgaJpZM4S7I7q.

Nukepayload2 commented 6 years ago

签名的问题我倒是有个办法。先看看今年下半年 Windows 10 的 ARM64 版表现如何。如果表现好，可以把弹幕姬打包成商店应用，然后发布到微软商店。这样微软会给程序包签名，同时阻止 NT SERVICE\TrustedInstaller 之外的用户修改你的软件包安装目录。至于开发人员账号，你可以自己在微软的开发人员中心买，我印象中前年是 120 RMB 就能永久用，也可以借用在校大学生的邮箱免费注册一个。

Nukepayload2 commented 6 years ago

软件大小问题可以试试 ILMerge 链接程序集（如果你不用反射的话）。工具下载： https://www.nuget.org/packages/ilmerge 教程： https://github.com/Microsoft/ILMerge/blob/master/ilmerge-manual.md

Genteure commented 6 years ago

可以把弹幕姬打包成商店应用，然后发布到微软商店。

@Nukepayload2 但是还是有很多 Windows 7 用户的。根据 www.danmuji.org 最近七天的 Google Analytics 统计，在占总共 86.78% 的 Windows 访客中：

48.96% 是 Windows 10
48.73% 是 Windows 7
1.71% Windows 8.1
0.61% 其他

直接看 ClickOnce 请求版本检查的日志应该会更准确一些，不过大体上应该差不多。还是有不少人 “Windows10 有bug/不好用/占资源/卡” 然后就装了Windows7的。

Nukepayload2 commented 6 years ago

我没有让你们这么早就放弃 Win7 的支持。毕竟那个系统在 2020 年才会成为下一个 XP。那些装了 Win10 反而卡的大多是连 AVX 指令集都没有的老电脑，到 win7 彻底退役的时候那些人也该换电脑了。你们需要看得远一些。我不信以后 B 站不会动弹幕的实现机制或者设计。你们以后肯定还是有修改代码的必要。下一次 B 站弹幕改版你们打算怎样给代码签名呢？就算 B 站弹幕长时间不改版，这套 UI 随着微软逐步实现系统应用的 Fluent Design，会越来越难融入到当前系统的风格。最近给预览体验人员推送的 1803 功能更新已经在相当多的地方添加了亚克力材质和揭示光照效果。然而 WPF 4 默认的控件外观还停留在 Windows 8 时代的 Aerolite。总有一天要让弹幕姬混合使用 UWP 的窗口和显示弹幕用的 Win32 窗口，来迎合系统风格的变化。顺便说一句坏消息。WPF 的 DPI 感知功能从 .NET Framework 4.7.2 发行声明里面消失了。这意味着这个功能被推迟。

Nukepayload2 commented 6 years ago

杀毒软件定时删无签名的dll文件

定时删无签名 dll 那种软件不配称为杀毒软件，碰到的话应当直接给 Windows Defender 提交样本并举报这是假的杀毒软件。微软现在欢迎用户举报存在恶意恐吓行为的假杀毒软件。

我用 .NET API 分析工具检查了，弹幕姬需要权限的地方也就用了网络客户端, 动态代码生成。依赖的本机 dll 目测需要顶置窗口。理论上稍微正常点的杀毒软件都认为没有威胁，比如说 WD 和卡巴斯基。

顺便提一下，你们在用一些过时 API，比如说 TaskEx 。这个过时 API 会导致某些环境（例如 Windows 8 没打任何补丁）发生找不到元数据的异常，某些情况会导致意外的同步等待异步操作情况，造成程序假死。对于 TaskEx 的处置方式是升级项目的 .NET Framework 版本 (一年前流行的版本是 4.6.1) 并将 TaskEx 替换成 Task。

xqq commented 6 years ago

360用户了解一下

Nukepayload2 commented 6 years ago

我在 win7 虚拟机里测试我的软件时用过 360。它非常喜欢删易语言和 VB6 的程序，甚至是各种开发环境。但是它很少删除使用比较常见的 API 的 .NET 软件。

copyliu commented 6 years ago

是随机性的, 连System.Core都会被删, 每个月都会有错误报告发到我这里花式缺dll包括系统的命名空间

另外 wosign 了解一下? https://web.archive.org/web/20160414093617/https://buy.wosign.com/codesign_360.html

"使用沃通（WoSign）代码签名证书签名的软件，提交到360软件认证平台，通过360认证后，360安全卫士马上不拦截！"

在 2018/4/7 11:50, Nukepayload2 写道:

我在 win7 虚拟机里测试我的软件时用过 360。它非常喜欢删易语言和 VB6 的程序，甚至是各种开发环境。但是它很少删除使用比较常见的 API 的 .NET 软件。

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/copyliu/bililive_dm/issues/22#issuecomment-379429797, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBtoH8B1advRIA9hCGADEG8hvDQ3IDeks5tmDeRgaJpZM4S7I7q.

Nukepayload2 commented 6 years ago

System.Core 我记得是 .NET Framework 的一部分，不是这个仓库里面的代码产生的。如果那个文件被删除，理论上所有依赖这个程序集的软件都会无法启动。所以说这是破坏性的操作。掌握 360 删除 System.Core.dll 的证据之后完全有理由向微软举报 360 的恶意行为。

证书费用的问题我想到一个办法。可以把应用发布到微软商店之后产生的安装包的证书提取出来给非商店版的签名，并且让 win7 用户安装微软商店的证书。既然是微软商店签名的软件，360 应该管不着了。微软商店的证书依赖的所有证书都需要安装，尤其是 Microsoft Root Certificate Authority 2011 。

copyliu commented 6 years ago

会考虑微软商店的证书, 但是就算是微软自己签名的文件比如弹幕姬所需的System.Threading.Tasks.dll System.IO.dll 一样会被做掉. 老实讲我已经不太想解决"被删文件"的事情了, 只要不增加类似的情况的发生几率就好, 于是回到最初的问题, 我不想再往弹幕姬里增加任何的文件增加被删的几率.

在 2018/4/7 12:21, Nukepayload2 写道:

System.Core 我记得是 .NET Framework 的一部分，不是这个仓库里面的代码产生的。如果那个文件被删除，理论上所有依赖这个程序集的软件都会无法启动。所以说这是破坏性的操作。掌握 360 删除 System.Core.dll 的证据之后完全有理由向微软举报 360 的恶意行为。

证书费用的问题我想到一个办法。可以把应用发布到微软商店之后产生的安装包的证书提取出来给非商店版的签名，并且让 win7 用户安装微软商店的根证书。既然是微软商店签名的软件，360 应该管不着了。

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/copyliu/bililive_dm/issues/22#issuecomment-379431012, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBtoBaMdzRCE9x2AGCg_S1m98DWrks6ks5tmD6xgaJpZM4S7I7q.

Nukepayload2 commented 6 years ago

那不如这样，Win7 版和 Win10 版分开。Win7 版作为长期维护版本，Win10 版活跃开发并且在微软商店分发。如果你们不愿意同时维护两个版本，或许我哪天闲了会开发具备类似功能但是更加现代化的 Win10 版软件，参考你们的代码 (仅参考，我会换个语言写，防止任何人说我有复制粘贴行为)，并且在软件内的感谢列表里面附上这个仓库的地址？

copyliu commented 6 years ago

提议不错, 我去了解一下时髦的Fluent Design, 之后再议

在 2018/4/7 12:41, Nukepayload2 写道:

那不如这样，Win7 版和 Win10 版分开。Win7 版作为长期维护版本，Win10 版活跃开发并且在微软商店分发。如果你们不愿意同时维护两个版本，或许我哪天闲了会开发具备类似功能但是更加现代化的 Win10 版软件，参考你们的代码 (仅参考，我会换个语言写，防止任何人说我有复制粘贴行为)，并且在软件内的感谢列表里面附上这个仓库的地址？

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/copyliu/bililive_dm/issues/22#issuecomment-379431888, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBtoCYUv_2FGWO0qTFLFkVAlacWzKsAks5tmENtgaJpZM4S7I7q.

copyliu / bililive_dm