在 Windows 世界里，应用部署普遍使用两种模型来处理系统与第三方的依赖项。
第一种是将所有依赖项捆绑到应用中。这种方式让开发者能精准控制应用使用哪些依赖项。这样做的缺点是会让应用的体积更大，对移动设备不太友好。另一个问题是依赖项的更新必须由开发者推送，而不是实际创建依赖项的公司。这样会在处理严重安全 bug 时带来难以接受的时间滞后。
另一种选择是把所有依赖项存储在共享空间中。对于 Com 应用是放在 Win32 文件夹，对于.Net 应用是放在全局程序集缓存（GAC）。但这样导致了“DLL Hell”的问题。即使维持了严格的向后兼容，同时也限制了你的选项。这阻止了某些有趣的场景发生，例如在不强制其它应用使用的情况下允许单一应用使用预发布版本的库。因此，通常需要用户手动去更新如.Net Framework 这类关键库。
在 Win10 Tools 1.1 中，Universal Windows Apps (UWP) 有了第三种选择。在新模型下，每个应用仍能指定.Net 的版本。这包括 beta 版的 framework。但当应用安装好后，通用库被放入共享位置。这种方法将让其它使用相同版本的应用能访问这些通用库。
在微软的一些测试中，他们找到方法将小型 UWP 应用的体积由 5.3MB 减少到只有 1.3MB。在更大样本中，他们将体积由 10.1MB 减少到只有 7.9MB。
出乎意料的是，这个特性还能减少生成时间。微软的 Rich Lander 声称，
对于大部分应用来说，这特性能为发布版本提供更快的生成时间。我们观察到的生成时间普遍更快，提升接近 30%——但有少数应用的实际生成耗时更长。我们正努力让交付版本的生成时间有更加稳定的改进。
这是一个预发布的特性，所以微软没有默认开启。然而，你可以开启后再将应用提交到 Windows Store。
查看英文原文： A New Publication Model for Universal Windows Apps
感谢张龙对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群
）。
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论