用于处理应用程序和定义应用程序回调的模块。

应用程序是 Erlang/OTP 中打包软件的惯用方式。简单来说，它们类似于其他编程语言中常见的“库”概念，但具有一些额外的特征。

应用程序是实现某些特定功能的组件，具有标准化的目录结构、配置和生命周期。应用程序可以加载、启动和停止。每个应用程序也有自己的环境，它提供了一个统一的 API 用于配置每个应用程序。

开发人员通常与应用程序环境及其回调模块交互。因此，我们将首先介绍这些主题，然后再深入了解应用程序资源文件和生命周期。

应用程序环境

每个应用程序都有自己的环境。环境是一个关键字列表，它将原子映射到项。请注意，此环境与操作系统环境无关。

默认情况下，应用程序的环境是一个空列表。在 Mix 项目的 mix.exs 文件中，您可以在 application/0 中设置 :env 键

def application do
  [env: [db_host: "localhost"]]
end

现在，在您的应用程序中，您可以使用 fetch_env!/2 等函数来读取此环境

defmodule MyApp.DBClient do
  def start_link() do
    SomeLib.DBClient.start_link(host: db_host())
  end

  defp db_host do
    Application.fetch_env!(:my_app, :db_host)
  end
end

在 Mix 项目中，可以通过 config/config.exs 和 config/runtime.exs 文件覆盖应用程序及其依赖项的环境。前者在构建时加载，在代码编译之前加载，而后者在运行时加载，就在应用程序启动之前加载。例如，使用您应用程序的人员可以按如下方式覆盖其 :db_host 环境变量

import Config
config :my_app, :db_host, "db.local"

有关更多信息，请参阅 Mix 模块中的“配置”部分。您还可以使用 put_env/3 和 delete_env/2 等函数动态更改应用程序环境。

库中的环境

库很少使用 config/config.exs 和 config/runtime.exs 配置文件。库通常在其 mix.exs 的 application/0 函数中定义其环境。配置文件通常由应用程序用于配置其库。

读取其他应用程序的环境

每个应用程序负责自己的环境。不要使用此模块中的函数直接访问或修改其他应用程序的环境。每当您更改应用程序环境时，Elixir 的构建工具只会重新编译属于该应用程序的文件。因此，如果您读取了另一个应用程序的应用程序环境，则您可能依赖于过时的配置，因为您的文件不会随着它的更改而重新编译。

编译时环境

在前面的示例中，我们在运行时读取了应用程序环境

defmodule MyApp.DBClient do
  def start_link() do
    SomeLib.DBClient.start_link(host: db_host())
  end

  defp db_host do
    Application.fetch_env!(:my_app, :db_host)
  end
end

换句话说，应用程序 :my_app 的环境键 :db_host 只有在 MyApp.DBClient 实际启动时才会读取。虽然在运行时读取应用程序环境是首选方法，但在某些罕见的情况下，您可能希望使用应用程序环境来配置特定项目的编译。但是，如果您尝试在函数之外访问 Application.fetch_env!/2

defmodule MyApp.DBClient do
  @db_host Application.fetch_env!(:my_app, :db_host)

  def start_link() do
    SomeLib.DBClient.start_link(host: @db_host)
  end
end

您可能会看到警告和错误

warning: Application.fetch_env!/2 is discouraged in the module body,
use Application.compile_env/3 instead
  iex:3: MyApp.DBClient

** (ArgumentError) could not fetch application environment :db_host
for application :my_app because the application was not loaded nor
configured

发生这种情况是因为在定义模块时，应用程序环境尚未可用。幸运的是，警告告诉我们如何解决此问题，方法是使用 Application.compile_env/3

defmodule MyApp.DBClient do
  @db_host Application.compile_env(:my_app, :db_host, "db.local")

  def start_link() do
    SomeLib.DBClient.start_link(host: @db_host)
  end
end

这里的区别在于，compile_env 期望默认值作为参数给出，而不是使用 mix.exs 的 def application 函数。此外，通过使用 compile_env/3，Mix 等工具会在编译期间存储使用的值，并在您的系统启动时将编译值与运行时值进行比较，如果它们不同，则会引发错误。

无论如何，应避免使用编译时环境。只要有可能，在运行时读取应用程序环境应该是首选。

应用程序回调模块

应用程序可以加载、启动和停止。通常，Mix 等构建工具会为您处理启动应用程序及其所有依赖项，但您也可以通过调用以下方法手动执行此操作

{:ok, _} = Application.ensure_all_started(:some_app)

当应用程序启动时，开发人员可以配置一个执行自定义代码的回调模块。开发人员使用此回调来启动应用程序监督树。

第一步是在 mix.exs 文件中的 application/0 定义中添加一个 :mod 键。它期望一个元组，其中包含应用程序回调模块和启动参数（通常是空列表）

def application do
  [mod: {MyApp, []}]
end

传递给 :mod 的 MyApp 模块需要实现 Application 行为。这可以通过在该模块中放置 use Application 并实现 start/2 回调来完成，例如

defmodule MyApp do
  use Application

  def start(_type, _args) do
    children = []
    Supervisor.start_link(children, strategy: :one_for_one)
  end
end

use Application

当您使用 use Application 时，Application 模块将设置 @behaviour Application 并为 stop/1 函数定义一个可重写定义，这是 Erlang/OTP 所必需的。

The start/2 回调必须生成并链接一个监督器，并返回 {:ok, pid} 或 {:ok, pid, state}，其中 pid 是监督器的 PID，state 是可选的应用程序状态。 args 是传递给 :mod 选项的元组的第二个元素。

传递给 start/2 的 type 参数通常是 :normal，除非在分布式设置中配置了应用程序接管和故障转移。分布式应用程序超出了本文档的范围。

当应用程序关闭时，其 stop/1 回调将在运行时停止监督树后调用。此回调允许应用程序进行任何最终清理。该参数是 start/2 返回的状态（如果有），否则为 []。 stop/1 的返回值被忽略。

通过使用 Application，模块将获得 stop/1 的默认实现，该实现会忽略其参数并返回 :ok，但可以被重写。

应用程序回调模块还可以实现可选回调 prep_stop/1。如果存在，则在终止监督树之前调用 prep_stop/1。它的参数是 start/2 返回的状态（如果有），否则为 []，其返回值传递给 stop/1。

应用程序资源文件

在上面的部分中，我们已经在 mix.exs 文件的 application/0 部分中配置了一个应用程序。最终，Mix 将使用此配置创建一个 应用程序资源文件，该文件名为 APP_NAME.app。例如，OTP 应用程序 ex_unit 的应用程序资源文件名为 ex_unit.app。

您可以在 Mix.Tasks.Compile.App 的文档中了解有关应用程序资源文件生成的更多信息，也可以通过运行 mix help compile.app 来了解。

应用程序生命周期

加载应用程序

应用程序被加载，这意味着运行时会找到并处理它们的资源文件

Application.load(:ex_unit)
#=> :ok

当加载应用程序时，其资源文件中指定的环境将与其配置文件中的任何覆盖合并。

加载应用程序不会加载其模块。

实际上，您很少手动加载应用程序，因为这是启动过程的一部分，将在下面解释。

启动应用程序

应用程序也被启动

Application.start(:ex_unit)
#=> :ok

在应用程序编译完成后，运行系统就是启动当前应用程序及其依赖项的问题。与其他语言不同，Elixir 没有负责启动系统的 main 过程。相反，您启动一个或多个应用程序，每个应用程序都有自己的初始化和终止逻辑。

当应用程序启动时，如果 Application.load/1 尚未调用，则会自动调用它。然后，它会检查其资源文件的 applications 键中列出的依赖项是否已启动。至少有一个依赖项未启动是一个错误条件。诸如 ensure_all_started/1 等函数会为您处理启动应用程序及其所有依赖项。

如果应用程序没有配置回调模块，则此时会完成启动。否则，将调用其 start/2 回调。此函数返回的顶级监督器的 PID 会被运行时存储以供以后使用，并且如果存在，返回的应用程序状态也会被保存。

停止应用程序

启动的应用程序最终会被停止

Application.stop(:ex_unit)
#=> :ok

停止没有回调模块的应用程序是定义的，但除了某些系统跟踪之外，实际上它是一个空操作。

停止具有回调模块的应用程序包含三个步骤

1. 如果存在，则调用可选回调 prep_stop/1。
2. 终止顶级监督器。
3. 调用必需回调 stop/1。

传递给回调的参数与 start/2 可选返回的状态有关，并在上面关于回调模块的部分中进行了说明。

需要注意的是，步骤 2 是一个阻塞步骤。终止一个主管会触发一个递归的子进程终止链，从而有序地关闭所有后代进程。只有在整个监督树终止后才会调用 stop/1 回调。

要干净地关闭一个正在运行的系统，可以调用 System.stop/1。它会按照应用程序启动的顺序反向关闭所有应用程序。

默认情况下，来自操作系统的 SIGTERM 会自动转换为 System.stop/0。您还可以通过 :os.set_signal/2 函数对操作系统信号进行更明确的控制。

工具

Mix 构建工具自动化了大部分应用程序管理任务。例如，mix test 会自动启动您的应用程序依赖项和应用程序本身，然后运行您的测试。 mix run --no-halt 会启动您的当前项目，可用于启动一个长期运行的系统。请参阅 mix help run。

开发人员还可以使用 mix release 构建**发布版**。发布版能够将所有源代码以及 Erlang VM 打包到一个单一目录中。发布版还允许您明确控制每个应用程序的启动方式和顺序。它们还提供了一种更简化的机制来启动和停止系统、调试、记录以及系统监控。

最后，Elixir 提供了 escripts 和 archives 等工具，它们是用于打包应用程序的不同机制。这些工具通常用于开发人员之间共享工具，而不是作为部署选项。请参阅 mix help archive.build 和 mix help escript.build 以获取更多详细信息。

更多信息

有关应用程序的更多详细信息，请查看 :application Erlang 模块 的文档以及 应用程序 部分的 OTP 设计原则用户指南。