一個用於處理應用程式和定義應用程式回呼的模組。

應用程式是包裝 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 所要求的。

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 設計原則使用者指南。