概念

AppImage 的開發遵循一些容易理解的核心原則與概念，讓開發者與使用者都能輕鬆使用。本節說明其中最重要的概念。

一個應用程式 = 一個檔案

AppImage 非常容易理解。每個 AppImage 都是一般檔案，且每個 AppImage 只包含一個應用程式及其所有相依項目。當 AppImage 設為可執行 後，使用者即可執行它，例如在桌面環境的檔案管理員中雙擊，或在主控台執行等。

備註

經常有人 詢問 是否能支援某種「可重複/共享框架」。這些框架預期包含多個 AppImage 會用到的函式庫集合，因而可節省磁碟空間。在管理上，有人建議使用複雜的自動化系統，在缺少時從網路自動抓取「框架」，或以一些複雜、且多半是手動的方式，讓使用者把框架與 AppImage 一起放在 USB 隨身碟等可攜式磁碟上。

這對部分人或許是好點子，即使運作良好，也會違背我們最重要的概念：一個應用程式 = 一個檔案。AppImage 之所以容易理解，正是因為 每個應用程式都是單一檔案。這種做法沒有複雜性，連阿嬤都能理解。而且，現在磁碟空間也不貴，對吧？

若您偏好或確實需要此做法，請改用其他方案。AppImage 不會實作這類功能。

不要依賴系統提供的資源

AppImage 作者需要決定要支援哪些目標系統（Linux 散布版）。接著，必須把那些無法合理假設會隨每個目標系統（Linux 散布版）預設安裝、且版本足夠新的相依項目一併打包。

為了能在任何 Linux 散布版上執行，AppImage 應該打包所有在執行時需要、但無法合理期待所有仍受支援目標系統（Linux 散布版）預設安裝就「一定有」的資源。最常見的資源包含實際二進位檔、共享函式庫相依、圖示與其他圖形，以及用於桌面整合的一個或多個桌面檔。

這不代表 AppImage 不能使用系統提供的資源，例如可合理假設每個目標系統都具備的基礎函式庫（如 C 標準函式庫或圖形函式庫）、使用者介面主題等。可參考 excludelist，了解我們認為目前各仍受支援目標系統（散布版）中已包含的函式庫清單。

在舊系統上建置，在新系統上執行

最佳實務是：在可假設使用者仍在使用的最舊且仍受支援的 Linux 散布版上開發與編譯應用程式。例如，仍受支援的最舊 Ubuntu LTS 版本就是不錯的開發與建置選擇。

應用程式應在盡可能舊的系統上建置，以便在較新的系統上執行。這樣就能排除某些「基礎函式庫」，因為可預期它們存在於所有主流桌面 Linux 散布版中，從而降低 一個應用程式 = 一個檔案 的負擔。這些相依項目多為共享函式庫，包含如 :code:`libc.so.6`（GNU C 函式庫、也是多數 Linux 散布版的 C 標準函式庫），以及常見的 zlib 或 GLib 函式庫。

依賴散布版提供的資源似乎與 前一節 相矛盾。這是在降低重複與儘可能自包含之間的取捨。

在某些情況下，反而會因為包含函式庫而導致 AppImage 在目標系統上無法運作。例如硬體相依的函式庫（像顯示卡驅動提供的函式庫，例如 :code:`libGL.so.1`（`來源 <https://github.com/AppImage/pkg2appimage/blob/14c255b528dd88ef3e00ae0446ac6d84a20ac798/excludelist\#L38-L41>`__）），或在不同散布版上建置與連結方式不同的函式庫（例如 libharfbuzz.so.0 與 :code:`libfreetype.so.6`（`來源 <https://github.com/AppImage/pkg2appimage/blob/14c255b528dd88ef3e00ae0446ac6d84a20ac798/excludelist\#L98-L102>`__））。

可（或必須）排除的函式庫清單，即所謂的 excludelist，由 AppImage 團隊仔細維護並定期更新。

AppImage 規範

AppImage 一詞並非指某個軟體專案，而是 AppImage 規範 <ref-appimage-specification>`中定義的一項標準。其參考實作稱為 :ref:`ref-appimagekit。

作為具備參考實作的標準設計，讓使用者可實作自己的 AppImage 建置工具，並有助於維持不同工具與元件之間的相容性。

AppDir

AppDir 指的是應用程式目錄。這些目錄是 AppImage 的「來源」。當 appimagetool 建置 AppImage 時，會建立該目錄的唯讀映像，在前面加上 runtime，並將檔案標記為可執行。

AppDir 格式在 AppDir 規範 中說明。