应用程序规范文件

到目前为止，在我们对 Elixir 和 OTP 的快速探索中，我们已经了解了服务器进程以及监控它们的监督者。接下来旅程中的最后一个环节是：应用（application）。

一种不同的应用

由于 OTP 源自 Erlang 生态，它沿用了 Erlang 中的命名方式。不幸的是，其中一些名称并不直观易懂。例如，“application” 这个词就是其中之一。当我们大多数人提到“应用”时，通常会想到一个可以运行的程序，比如在电脑、手机上运行，或通过网页浏览器访问的软件。这种应用是一个完整的、独立的整体。

但在 OTP 的世界里，情况并非如此。实际上，一个 OTP 应用是一个代码包，附带一个描述文件。这个描述文件告诉运行时环境：该代码有哪些依赖项、注册了哪些全局名称等等。事实上，OTP 应用更像一个动态链接库（dynamic link library）或共享对象（shared object），而不是传统意义上的应用程序。

不妨在脑海中把“application”这个词理解为一个组件或服务，这样更容易把握其含义。

举个例子，之前我们使用 HTTPoison 库获取 GitHub 问题时，实际上安装的是一个独立的应用程序，其中包含了 HTTPoison。虽然看起来我们只是在使用一个库，但 mix 会自动加载 HTTPoison 应用。当我们启动它时，HTTPoison 又启动了它所需的其他几个应用（如 SSL 和 Hackney），这些应用又各自启用了自己的监督者和工作进程。而这一切对我们来说都是透明的，完全无需干预。

我们说过应用是一种组件，但有些应用位于整个结构的顶层，是可以直接运行的。在本章中，我们将同时探讨这两种类型的应用组件。实际上，它们本质上几乎相同，因此我们先来了解它们的共通之处。

应用规范文件

你可能已经注意到，时不时地，mix 会提到一个名为 name.app 的文件，其中 name 是你的应用名称。

这个文件被称为应用规范文件，用于向运行时环境定义我们的应用。Mix 会根据 mix.exs 中的信息，并结合编译过程中获取的额外信息，自动生成这个文件。

当我们运行应用时，系统会查阅这个文件以确定需要加载的内容。我们的应用并不一定需要使用全部 OTP 功能。这个文件始终会被创建并引用。然而，一旦我们开始使用 OTP 的监督树结构，添加到 mix.exs 中的配置信息就会被复制到 .app 文件中。