performance - 为什么要创建 DLL 而不是将所有内容编译成一个大的可执行文件？

Question

我看到并自己做了很多小产品，其中同一个软件被分成一个可执行文件和几个 DLL，这些 DLL 不仅仅是由其他人完成的共享库，而是专门为这个软件完成的库，由同一个开发团队。 (我在这里不是在谈论只需要数百个 DLL 并与其他产品广泛共享的大型产品。)

我知道从开发人员的角度来看，将代码分成几个部分，每个部分都编译成一个单独的 DLL，这很好。代表着:

如果开发人员更改了一个项目，他只需要重新编译这个项目和依赖的项目，这会更快。

一个项目可以由团队中的单个开发人员完成，而其他开发人员将只使用提供的接口(interface)，而无需进入代码。

软件的自动更新有时可能更快，对服务器的影响更小。

但是最终用户呢？当所有东西都可以组合在一起时，交付一个由一个 EXE 和几个 DLL 组成的软件不是很糟糕吗？毕竟:

用户甚至可能不明白这些文件是什么以及为什么它们会在他的硬盘上填满内存，

用户可能想要移动程序，例如将其保存在 USB 闪存驱动器上。拥有一个大的可执行文件让事情变得更容易，

大多数防病毒软件都会检查每个 DLL。检查一个可执行文件将比较小的可执行文件和几十个库快得多。

使用 DLL 会使某些事情变慢(例如，在 .NET Framework 中，必须找到一个“好的”库并检查它是否已签名)，

如果 DLL 被删除或替换为错误版本会怎样？每个程序都处理这个吗？或者它甚至没有解释它有什么问题就崩溃了？

拥有一个大的可执行文件有 some other advantages .

所以 从最终用户的角度来看，对于中小型程序，交付一个大型可执行文件不是更好吗？ 如果是这样，为什么没有工具可以轻松做到这一点(例如，集成在通用 IDE 中的魔术工具将整个解决方案编译成一个可执行文件，当然不是每次，而是按需或在部署期间)。

这在某种程度上类似于 putting all CSS or all JavaScript files into one big file为用户。拥有多个文件对开发人员来说更智能并且更易于维护，但是将网站的每个页面链接到两个文件而不是几十个文件可以优化性能。以同样的方式， CSS sprites对设计师来说很糟糕，因为他们需要更多的工作，但从用户的角度来看更好。

Answer 1

这是一个权衡
(你自己已经想通了；))
对于大多数项目，客户并不关心安装了多少文件，而是关心及时完成了多少功能。让开发人员的生活更轻松也使用户受益。

DLL 的更多原因

有些库在同一个构建中不能很好地协同工作，但可以在 DLL 中运行(例如，一个 DLL 可能使用 WTL3，另一个需要 WTL8)。

某些 DLL 可能包含要加载到其他可执行文件(全局 Hook 、shell 扩展、浏览器插件)中的组件。

某些 DLL 可能是第 3 方的，仅作为 DLL 提供。

公司内部可能会重复使用——即使您只看到一个“公共(public)”产品，它也可能在使用该 DLL 的十几个内部项目中使用。

某些 DLL 可能是使用不同的环境构建的，该环境并非对公司中的所有开发人员都可用。

独立 EXE 与已安装产品
无论如何，许多产品都不能作为独立的可执行文件运行。它们需要安装，并且用户不要触摸他不应该触摸的东西。拥有一个或多个二进制文件并不重要。

构建时间影响
也许您低估了构建时间的影响，并为大型项目保持稳定的构建。如果构建甚至需要 5 分钟，您可以委婉地称之为“让开发人员提前思考，而不是修补直到看起来可以正常工作”。但这是一个严重的时间进食者，并造成严重的分心。

单个项目的构建时间很难改善。在 VC9 上工作，在一个项目中构建并行化是不稳定的，增量链接器也是如此。更快的机器特别难以“优化”链接时间。

开发者独立
你可能低估的另一件事。
要使用 DLL，您需要一个 .dll 和一个 .h。
要编译和链接源代码，通常需要设置包含目录、输出目录、安装第三方库等，真的很痛苦。