为什么程序这么大？

如果我们看一下老式程序Netscape Navigator或Microsoft Word的早期版本，则这些程序的大小不到50 MB。现在，当我安装google chrome时，它是200 MB，而Slack的桌面版本是300 MB。我读到一些规则，即程序将占用所有可用内存，无论内存多少，但为什么呢？

为什么与10或15年前相比，当前的程序规模如此之大？这些程序并未执行更多的功能，并且看起来也没有太大不同。现在的资源消耗是什么？

“看起来非常不同”是一个感知问题。当今的图形必须在与以前完全不同的屏幕分辨率下显示出出色的效果，其结果是，过去对于徽标来说已经足够好的100x100图像现在看起来非常发粘。必须用相同的东西的1000x1000图像替换它，这是原来的100倍。（我知道您可以使用矢量图形代替，但这只是强调了一点-以前必须将矢量图形渲染代码添加到不需要的系统中，因此这只是一种尺寸增加的权衡到另一个。）

“不同地工作”同样是一个感知问题。如今的浏览器做大量更多的东西比一个从1995年（尝试用一个历史性的笔记本电脑上网冲浪，一个阴雨天-你会发现它几乎无法使用）没有多少人使用了非常多，用途可能完全不知道的90他们中的％，但他们在那里。

当然，最重要的是，普遍的趋势是花费更少的时间来优化空间，而更多地用于引入新功能。对于每个人来说，这是更大，更快，更便宜的计算机的自然副作用。是的，有可能编写与1990年一样资源高效的程序，其结果将是惊人的快速和流畅。但这将不再具有成本效益。您的浏览器可能需要十年才能完成，届时要求将会完全改变。人们过去常常非常注重效率来编程，因为去年缓慢的小型机器迫使他们这样做，其他所有人也都在这样做。只要这个改变，节目成功的瓶颈，从能够运行转移所有来运行越来越多的闪亮事物，那就是我们现在的位置。

如果将Netscape Navigator与现代浏览器进行比较，则功能会有很大的不同。只需将HTML 3.2规范（当我进行打印预览时为51页）与当前的HTML规范（PDF版本为1155页）进行比较。大小增加了20倍。

Netscape Navigator没有DOM，也没有CSS！没有动态更改文档，没有JavaScript修改DOM或样式表。没有标签。没有音频或视频。现代浏览器是一个非常复杂的程序。

原因之一是应用程序内打包的数据更大，因为它们具有更高的分辨率和质量。Netscape时代的图标最大为32x32像素，最大深度为8位（可能只有4个），而现在它的大小可能约为64x64，它是带有透明色的真彩色，即32位深度。那是大16倍。而且空间是如此的便宜，以至于人们在生成PNG时甚至常常不打扰检查“压缩”选项。

另一个原因是，如今的应用程序随身携带着令人难以置信的数据量，而较早的应用程序却没有。如今，存在与视频中的“入门”演示文稿一起交付的应用程序。

另一个原因是，当今的编程语言往往会与丰富的运行时环境结合在一起，运行时环境相当大，每种环境都达到100MB。即使您没有使用运行时环境的所有功能，也仍然必须将整个程序与应用程序打包在一起。

但是主要原因是，如今存在无数个可以在我们的应用程序中使用的库，并且我们已经开发出一种使用库的文化，以避免不断重复发明轮子。当然，一旦开始使用库，就会弹出几个问题，并且我们已经养成了给它们最自由答案的习惯：

• 如果只供我的一个功能使用，是否值得再包含一个库？- 是的

• 如果我只需要该库提供的全部功能的一小部分，是否值得包含另一个库？- 是的

• 如果只收录我两天的工作，值得再增加一个图书馆吗？- 是的

• 仅仅因为我工资单上的不同程序员刚好已经熟悉了不同的库而包含多个或多或少地达到相同目的的库是否值得？- 是的

  （请注意，我只是观察这些趋势，对于我是否同意这些趋势，我不作任何陈述。）

值得一提的另一个原因是，当试图在多个选择中决定使用哪个应用程序时，一些用户认为占据更多空间的应用程序将具有更多的功能，更精美的图形等。（当然，这完全是胡说八道） ）

那么，总而言之，软件的行为是否像天然气？它会占用所有可用空间吗？从某种意义上说是可以的，但没有任何令人震惊的程度。如果我们看一下占据驱动器大部分空间的东西，对我们大多数人来说，答案是它不是应用程序，而是到目前为止的电影和音乐等媒体。软件的膨胀速度与存储容量的膨胀速度不同，而且膨胀的可能性也不大，因此在将来，应用程序可能只占用户可用存储空间的很小一部分。

除了其他答案外，十年前，本地化/国际化版本通常会有单独的版本。现在，通常情况下，程序会将完全的本地化支持捆绑到每个发行版中，从而扩大了程序的大小。

原因之一是依赖关系。一个具有丰富功能和美观外观的程序需要完成许多工作-加密，拼写检查，使用XML和JSON，文本编辑以及许多其他工作。他们从哪里来？也许您自己滚动，并使其尽可能小。您很可能会使用第三方组件（也许是MIT许可的开放源代码），而这些组件实际上并不需要很多功能，但是一旦您需要第三方组件中的单个功能，则通常必须随身携带整个组件。因此，您添加了越来越多的依赖项，并且随着它们自身的发展和增长，依赖于它们的程序也随之增长。

尽管图形/可用性确实是影响因素，但其中很多是库/多余的编译代码。

小代码仍然可以使用的示例：MenuetOS，这是一个完整的64位OS，具有功能强大的应用程序，可安装在单个软盘上。

没有明显原因的大型代码示例：我做了一个简单的文本输出“ Hello，World！”。最近在阿达 编译的可执行文件超过1 MiB!。汇编中的同一可执行文件仅是KiB或2（并且大部分是可执行文件的开销，实际运行的代码为数十个字节）。

确实必须将软件构建为适合两件事：用户和可用硬件。如果程序可以及时地执行用户想要的操作，并且硬件可供用户使用，则该程序适合其目的。好吧 但是，随着硬件在所有可测量维度上的改善，从不合适到适合的离散程序的数量也在增加-设计空间越来越大：

• 高级语言使得用更少的代码和时间来表达思想成为可能。相反，这种降低的复杂性使得表达日益复杂的想法成为可能。
• 与应用程序捆绑在一起的更多数据可以使其立即变得更加可用。例如，将拼写检查应用程序与人类已知的每种语言捆绑在一起可能不会很快-毕竟只有几千兆字节。
• 硬件的权衡允许开发人员和用户在他们关心的资源上有更多选择。例如，参见FLAC / OGG与WAV，SVG与PNG，数据库索引。
• 人性化的界面通常会折衷使用以前需要大量硬件才能实现的可用性。抗锯齿，高分辨率，快速刷新以及在不连续面板之间进行滑动都可以带来更逼真的，因此直观和相关的体验。

对于Android应用程序，这绝对是正确的。四年前，一个简单的应用程序占用了大约2-5兆字节的空间。如今，一个简单的应用程序需要大约10-20 MB的空间。

可用空间越多，应用程序大小越大。

我认为使用Android的主要原因有两个：

• Google扩展了Android框架，添加了许多新功能。

• 开发人员不再关心。图像包含在更高的分辨率中（当然，智能手机的屏幕分辨率有所提高），而第三方库则被毫不考虑地包含在内。

其中很多都归结为开发人员的时间和时间的成本。早在Visual Basic首次出现时，它就与C / C ++竞争，最大的障碍是您可以用ANSI C for Windows编写“ Hello World”（大约15K）。VB的问题在于，您总是遇到300K运行时库的问题。

现在，您可以将VB程序的大小增加10倍，而仍然只有几千个K，但是将C / C ++程序的大小增加10倍，并且您正在寻找更多MONTHS的开发。

最终，您的应用程序膨胀是一笔很小的代价，可以弥补开发生产的巨大飞跃，价格降低以及功能的巨大庞大，而这在过去的手工开发阶段是无法实现的。当程序小而又快但又很弱，彼此不兼容，功能不足且开发成本高时。

随着时间的流逝，用户的需求在不断发展，并且需求也越来越大，因此，不同软件的供应商/作者被迫以竞争的名义满足这些需求。

但是满足新的需求意味着经常添加新的代码。新代码意味着需要修复的新漏洞。修复新漏洞可能会添加代码或为新漏洞打开大门。

为满足用户需要而添加的每个功能可能都需要更高的处理器能力来提高速度（我们都抱怨这种浏览器的速度），新的图形资源以获得更好的视觉效果...等等。

所有这些都意味着增加了新的应用程序层（代码），安全性以及有时是硬件。

许多大小来自内置库。如今，许多应用是使用电子构建的，电子与应用捆绑在一起。如果在Linux上安装应用程序，则它们通常要小得多，因为许多应用程序已经通过其他程序也在使用的共享库安装了。

构造软件时，如果需要功能A，则将导入模块A *。A *可以解决A，但是A *比A可以解决更多的问题，而且A *可能很大。所有大型模块都将生成大型软件。

也许情况不一样，但类似这样：如果您只需要使用Java在控制台上打印“ hello world”，则需要安装JRE（> 60MB）。

如果Java示例不好，请尝试以下一种方法：如果该软件需要记录到文件，则可以使用一个记录模块，该模块实际上可以通过网络和其他一些功能将日志记录到数据库中，但是这些功能从未用于该项目。

我读到一些规则，即程序将占用所有可用内存，无论内存多少，但为什么呢？

这不是真的。在操作系统承受内存压力之前，系统不会释放已消耗的内存。这是一项性能改进。如果您正在浏览带有图像的页面，则可以导航。您可能会向后导航，因此再次需要该图像。如果操作系统具有RAM，则除非确定您不再需要它，否则没有必要清除内存。

当用户很可能希望在屏幕上显示高响应性的网页时，立即清除内存将使CPU周期和内存带宽远离用户。

操作系统将消耗所有可用的非应用程序内存，其中大部分用于文件系统缓存。

内存管理是一个棘手的问题，但是一直有很多聪明的人在努力。没有任何事情是故意浪费的，主要目标是为您提供一台响应迅速的计算机。

的确，程序趋向于扩展以填充可用空间，这与郊区现象类似，在郊区现象中，您将新车道添加到拥堵的高速公路上，并在几年之内再次备份了流量。

但是，如果您仔细研究一下，您可能会发现他们的程序实际上在做更多的事情。例如，浏览器运行更高级的图形，使用了几年前还没有的漂亮的开发人员工具，等等。它们还链接到许多库，有时仅使用一小部分代码。因此，尽管程序可能会增加大小以填充可用内存，但其中某些原因可能是出于正当的理由。

在未优化的对象上构建的库需要更多的内存来加载，安装和运行更多的计算周期。目标代码大部分是膨胀的。

只需逐步运行标准C ++代码，以查看所有assert（）ed对象调用即可确保它们是有效对象。当您一层又一层地设计对象以封装对象时，底层会变得blo肿且不透明。程序员变得懒惰并承担更多的对象，因为它比重新设计受限于所需功能的对象要快。真的就是这么简单。

考虑Linux C内核（仅内核）的大小与定制应用程序的大小。内核可以运行整个机器。但是它的构建速度不如应用程序快，它需要花费一些时间才能实现最佳功能。