积分 6709 最后登录 2024-4-23 精华 0 阅读权限 220 主题 145 UID 3887572 帖子 2897 PB币 3573 威望 925 贡献 0 技术 801 活跃 4722
14N.M.
UID 3887572 帖子 2897 PB币 3573 贡献 0 技术 801 活跃 4722
介绍
Nagisa 是一个开放源代码的支持多语言的下载实用工具,在 Windows 通用平台运行并以MIT许可发行。
Nagisa 采用 C++/CX 编写,只使用 WinRT API、Win32 API、WRL 和 STL,这是为了确保更高的执行速度和较小的程序大小。在保证用户体验的情况下,Nagisa 通过优化运行效率以降低设备的功耗,从而能延长您设备的续航时间且为延缓全球变暖奉献力量。
项目地址:https://github.com/Project-Nagisa/Nagisa
商店地址:https://www.microsoft.com/store/apps/9NFW53N9MFJR
远景帖子:https://bbs.pcbeta.com/viewthread-1775493-1-1.html
智机网帖子:http://bbs.wfun.com/thread-1005444-1-1.html
开发近况
也许有些人发现,自从上个月Nagisa上架后,几天后对一个奔溃率占比60%的bug修复后发布了0.3.23之后,就再也没更新……
也许会有人认为我已经弃坑了,但并不是这样的。
因为0.3的阶段需要挺长一段时间搞定,以下是开发近况:
1. 等 Windows 10, Version 1803 稳定版出现后,我需要评估下使用新版 Windows SDK 的必要性。
因为 Windows 10, Version 1803 的 Windows SDK 内置了可以让开发者使用标准 C++ 语法编写 Windows Runtime 组件甚至整个应用的 C++/WinRT 库,这吸引到了我。
当然,如果可以的话,我想继续保证对 Windows 10, Version 1507 的支持。
毕竟之后版本的其他特性除了 C++/WinRT 外都对我没有多少吸引力,除非 Windows 10 未来某个版本让 Windows Runtime 的 StreamSocket 支持 ALPN 特性,否则呵呵。
2.使用 OpenSSL 作为 Nagisa 的 SSL 和 Hash 库。
因为 Windows 10 现有版本的 Windows Runtime 的 StreamSocket 都不支持 ALPN 特性,这样我就没有办法跟进 HTTP/2 协议的支持,让我这个强迫症患者不爽。
曾经试图使用 hack 法为 Windows Runtime 的 StreamSocket 实现支持 ALPN 特性,但很遗憾失败了。
于是像很讨厌引入外部库的我不得不引入 OpenSSL 作为 Nagisa 的 SSL 库。
虽然后来发现 OpenSSL 还支持计算 Hash 以校验文件的完整性,于是可以共用代码了,笑。
当然,由于微软为 Windows Runtime 应用做的魔改版 OpenSSL 版本不是很新,于是我对其进行了魔改,且改进了 entropyRT 函数的实现以降低开销。
现在已经被微软的魔改版 OpenSSL 库合并了我的成果,详情:https://github.com/Microsoft/openssl/commits?author=MouriNaruto
3.编写自制传输引擎
既然引入了 OpenSSL 解决了 SSL 支持问题后,就可以开干了。
我打算先学习 libcurl 的实现,然后用 StreamSocket 实现 HTTP/FTP/WebSocket 以及对应的基于 SSL 的协议的支持。
随后再去搞 BitTorrent,ED2K 等 P2P 协议的支持。
据我的朋友 vbfool 表示后台套接字代理每次事件触发后都只提供了 30 秒的处理器时间让开发者进行处理,于是对于计划支持多线程和多任务下载的 Nagisa 来说是个不小的考验。
由于 Windows Runtime 并没有提供对 IStorageFile 进行 File Mapping 的接口,估计需要使用一些技巧尽量让系统一次性往文件写入更多的内容以减少系统调用次数,继而减小性能开销和 meltdown 漏洞产生的性能影响。
由于一次事件响应只有30秒的CPU时间,所以性能方面需要特别注意。
当然,我现在先暂停 Nagisa 的开发,因为想等 Windows 10, Version 1803 稳定版出现后,评估下使用新版 Windows SDK 的必要性。(这样可以减少一些无用功)
最后,我需要强调下 UWP 的框架 Windows Runtime 是一个基于 COM 的为 .Net 应用优化的本机框架不是托管框架。
Windows Runtime 原生开发语言是 C++ 而不是 C#。(虽然微软希望大家使用 C# 写 UWP,但是 Windows 10 的 Windows Runtime框架、系统级 UWP 和一些内置非系统级 UWP 是用 C++ 实现的。)
毛利
展开阅读全文​
3
查看全部评分