概述（Overview）

outsystems是一整套低代碼的企業級應用（WEB 和 移動端）的開發環境。
本文主要講解outsystems的Platform Tools與Platform Services

平臺工具（Platform Tools）

集成開發環境IDE（Service Studio）

Service Studio 是其集成開發環境（IDE），是開發人員創建應用程序的核心工具
可以用于開發 Web 和移動應用程序

• 可視化開發
  通過可視化界面，開發人員無需編寫大量代碼，而是通過拖拽、配置等直觀的操作來設計應用的各個部分，這大大降低了開發的難度和門檻，提高了開發效率。
  

• XML 指令
  使用 XML 格式的指令來定義應用的多個關鍵方面，包括數據模型（定義數據的結構和關系）、應用邏輯（處理業務規則和數據流程）、用戶界面（UI，決定應用的外觀和交互方式）、業務流程流（描述業務活動的順序和規則）、集成（與其他系統或服務進行數據交互）以及安全策略（保障應用的數據安全和訪問權限）。
  

• 代碼生成與優化
  基于 XML 中定義的這些信息，OutSystems 平臺會自動生成并優化代碼。這意味著開發人員不需要手動編寫大量的底層代碼，平臺會根據可視化設計和 XML 配置生成高效、可維護的代碼，同時還會對代碼進行優化，以提高應用的性能和穩定性。
  

第三方集成（Integration Studio）

OutSystems Integration Studio 是 OutSystems 平臺中的一個重要工具，它專注于實現與第三方系統的集成。在現代企業的數字化轉型中，企業內部的應用系統往往需要和外部的各種系統進行數據交互和功能協同，該工具就提供了這樣的集成能力。

1、可集成的第三方系統

• 外部數據庫
  像 MySQL、Oracle、SQL Server 等外部數據庫系統是常見的集成對象。通過 OutSystems Integration Studio，可以讓 OutSystems 應用與這些外部數據庫建立連接，實現數據的讀取、寫入、更新等操作。例如，企業可能有一個舊的客戶信息數據庫，新開發的 OutSystems 應用需要使用這些客戶信息，就可以通過該工具將兩者集成起來。

• 自定義代碼
  當集成過程中遇到一些特殊的業務邏輯或功能需求，現有的集成模板和配置無法滿足時，就可以使用自定義代碼。開發人員可以編寫特定的代碼來處理復雜的集成場景，比如對數據進行特殊的轉換、調用第三方系統的特定 API 等。
  

2、集成第三方部署過程

• Upload a DLL File 上傳 DLL 文件：
  DLL（Dynamic Link Library）是 Windows 系統中常用的動態鏈接庫文件。在集成第三方系統時，可能會使用到一些自定義的 DLL 文件，這些文件包含了特定的功能和邏輯。通過上傳 DLL 文件，可以將這些額外的功能集成到 OutSystems 平臺中。
• Platform Server
  平臺服務器是 OutSystems 平臺的核心組件之一，它負責管理和運行 OutSystems 應用的各種服務和資源。上傳的 DLL 文件首先會被部署到 Platform Server 上，以便在平臺層面進行管理和調度。
• Deploy to Application Server
  應用服務器用于實際運行 OutSystems 應用。將集成相關的內容（包括上傳的 DLL 文件等）部署到應用服務器后，應用就可以與第三方系統進行正常的交互和通信，最終為用戶提供完整的業務功能。
  

服務中心（Service Center）

Service Center 在 OutSystems 平臺中扮演著重要的角色，它提供了全面的環境配置和管理功能，涵蓋了數據庫連接、郵件服務器、應用配置等多個方面，同時還支持應用的版本管理和平臺服務、元數據倉庫的管理，有助于保障整個 OutSystems 平臺的穩定運行和應用程序的順利開發與部署。

1、環境配置

• 數據庫連接
  在 Service Center 中可以對數據庫連接進行配置。數據庫是應用程序存儲和獲取數據的重要基礎，合理配置數據庫連接參數（如數據庫地址、端口、用戶名、密碼等）能確保應用程序與數據庫之間的穩定通信。例如，若應用使用 MySQL 數據庫，就需要在 Service Center 里準確設置 MySQL 數據庫的連接信息。

• 郵件服務器
  配置郵件服務器信息，使得應用程序能夠發送和接收郵件。這對于實現一些需要郵件通知功能的應用場景非常重要，如用戶注冊成功后的郵件提醒、系統異常時的郵件告警等。配置內容通常包括郵件服務器地址、端口、認證方式等。

• 特定應用配置
  針對每個具體的應用，可以在 Service Center 中進行特定的配置。不同的應用可能有不同的業務需求和運行參數，通過這里的配置可以滿足個性化的要求，例如設置應用的訪問權限、緩存策略等。

2、應用程序配置

• 在線和離線應用管理
  OutSystems 中，在線應用依賴網絡實時交互，需管理 Web 服務端點；離線應用可離線使用，要配置數據同步，二者都有屬性與安全管理。
• 回滾到上一版本
  當應用程序在更新到新版本后出現問題時，可以利用 Service Center 的回滾功能將應用恢復到上一個正常運行的版本。這能快速解決因新版本引入的 bug 或兼容性問題，減少對業務的影響。
• 應用屬性
  可以查看和修改應用的各種屬性，如應用的名稱、描述、版本號等。這些屬性信息有助于對應用進行管理和識別，方便開發團隊和運維團隊了解應用的基本情況。
• Web 服務端點
  管理應用所使用的 Web 服務的端點信息。Web 服務是應用與外部系統進行交互的重要方式，準確配置 Web 服務端點能確保應用與外部系統之間的數據傳輸和功能調用正常進行。

3、配置管理

• 平臺服務
  對 OutSystems 平臺的各種服務進行管理和監控。這些服務是平臺正常運行的基礎，包括應用服務器服務、調度服務等。通過 Service Center 可以啟動、停止、重啟這些服務，以及查看服務的運行狀態和日志信息。
• 元數據倉庫
  元數據倉庫存儲了 OutSystems 平臺中所有應用的元數據信息，如數據模型、頁面布局、業務邏輯等。Service Center 可以對元數據倉庫進行管理，包括備份、恢復、同步等操作，確保元數據的安全性和一致性。
  

Lifetime

OutSystems LifeTime 是一個具備集中化管理功能的工具，在 OutSystems 平臺生態里扮演關鍵角色，能夠助力企業高效管理 IT 資源、應用程序發布等一系列事務。

1、集中化管理

• 用戶認證
  LifeTime 提供 IT 用戶認證機制，確保只有經過授權的人員才能訪問和操作平臺相關資源。通過與企業現有的身份驗證系統集成，如 LDAP、Active Directory 等，保障登錄的安全性和規范性，防止未授權訪問。
  
• 權限管理
  可以精細地管理 IT 用戶的權限，根據不同的角色和職責，為用戶分配不同的操作權限。例如，開發人員可能只有開發和測試環境的訪問權限，而運維人員則擁有生產環境的部署和管理權限。
• 多環境管控
  能夠對開發、測試、預生產、生產等不同環境進行統一管理。包括環境的創建、配置、監控等操作，確保各個環境的一致性和穩定性。例如，在開發環境中進行新功能的開發和測試，測試通過后，可平滑地將應用部署到預生產環境進行進一步驗證，最后再發布到生產環境。

2、DevOps 流程支持
LifeTime 支持完整的 DevOps 流程，實現從代碼開發、測試到部署的自動化。通過集成版本控制系統、自動化測試工具等，加速軟件交付周期，提高軟件質量。例如，當開發人員提交代碼變更時，LifeTime 可以自動觸發構建和測試任務，測試通過后自動部署到相應環境。

• 預發布應用管理
  在 OutSystems 的 DevOps 流程里，預發布（Staging）環節是軟件從開發環境過渡到生產環境的關鍵階段。預發布環境盡可能模擬生產環境，能在實際投入使用前發現并解決潛在問題，保證應用在生產環境中的穩定性和可靠性。
  

• 依賴分析
  在將應用部署到預生產環境之前，LifeTime 會對應用的依賴關系進行詳細分析。確保應用所依賴的其他組件、服務等都已正確配置和部署，避免因依賴問題導致應用在生產環境中出現故障。
  

• 自動更新
  支持應用的自動更新功能。當應用有新版本發布時，LifeTime 可以自動將新版本應用部署到相應環境，減少人工干預，提高更新效率。
  

• 運行時監控
  對預發布應用在運行時進行實時監控，收集應用的性能指標、日志信息等。一旦發現異常情況，能夠及時發出警報，以便運維人員及時處理，確保應用的穩定運行。
  

平臺服務（Platform Services）

代碼生成器（Code Generator）

Code Generator 即代碼生成器，是 OutSystems 開發平臺中的一個重要組件，其主要功能是依據特定輸入生成可用于部署的代碼。
OutSystems 的 Code Generator 通過處理不同來源的輸入，自動生成與數據庫交互、實現后端業務邏輯以及構建用戶界面的代碼，并通過一鍵發布功能觸發整個自動化流程，為開發人員提供了高效、便捷的開發體驗。

1、輸入源

• Service Studio 的 XML 指令
  Service Studio 是 OutSystems 用于可視化開發的工具。開發人員在 Service Studio 中通過可視化界面設計應用的各種元素，如數據模型、業務邏輯、用戶界面等，這些設計信息最終會以 XML 格式的指令保存。Code Generator 會讀取這些 XML 指令，以此為基礎生成代碼。
• Integration Studio 的二進制代碼
  Integration Studio 主要用于與第三方系統進行集成開發。在這個過程中會產生二進制代碼，Code Generator 也會處理這些二進制代碼，將其融入到最終的應用代碼中，實現與第三方系統的交互功能。

2、編譯與部署代碼的生成

• 與數據庫交互的 SQL 代碼
  Code Generator 會根據應用的數據模型和業務需求，生成用于與數據庫進行交互的 SQL 代碼。這些代碼負責數據的增刪改查操作，確保應用能夠正確地從數據庫中獲取和存儲數據。
• 后端業務邏輯代碼
  根據在 Service Studio 中定義的業務規則和流程，Code Generator 會生成相應的后端業務邏輯代碼。這些代碼運行在服務器端，處理各種業務邏輯，如計算、驗證、工作流管理等。
• 界面的 HTML 和 JavaScript 組件
  為了實現用戶界面的交互效果和展示功能，Code Generator 會生成 HTML 和 JavaScript 代碼。HTML 用于構建頁面的結構，JavaScript 則負責實現頁面的動態效果和交互邏輯，為用戶提供良好的使用體驗。
  
  1-Click-Publish
  整個代碼生成和編譯部署的過程是自動化的，只需開發人員按下 “1-Click-Publish” 按鈕觸發，Code Generator 就會被觸發，自動完成從讀取輸入源到生成最終可部署代碼的一系列操作。

Code Generator Validations

OutSystems 的代碼生成器驗證（Code Generator Validations）通過對外部依賴的檢查優化、日志監控功能的添加以及數據庫升級腳本的運行，全方位地保障了應用的質量和性能。

• 外部依賴檢查與應用優化
  檢查機制：代碼生成器會仔細檢查應用的外部依賴，即應用在運行過程中所依賴的其他組件、服務或資源。通過深入分析代碼邏輯和數據流向，找出那些雖然存在但實際上并未被應用使用的部分。
  優化示例：以數據庫查詢為例，如果一個查詢語句的結果在整個應用中從未被使用，代碼生成器的優化器會將該查詢標記為待移除項。這樣做可以顯著減少應用的冗余代碼，降低系統資源的消耗，提高應用的運行效率。同時，移除無用的查詢還能簡化代碼結構，使代碼更易于理解和維護。
• 添加日志和監控功能
  功能意義：在應用中添加日志和監控功能是保障應用穩定性和可維護性的重要手段。日志記錄可以幫助開發人員和運維人員追蹤應用的運行狀態、記錄關鍵事件和錯誤信息。當應用出現問題時，通過查看日志可以快速定位問題所在，縮短故障排除時間。
  實時監控：監控功能則可以實時收集應用的性能指標，如響應時間、吞吐量、資源利用率等。開發人員可以根據這些監控數據及時發現潛在的性能瓶頸，并進行針對性的優化，確保應用在各種負載情況下都能穩定運行。
• 數據庫升級腳本運行
  部署前準備：在應用部署之前，代碼生成器會自動運行數據庫升級腳本。隨著應用的不斷更新和迭代，數據庫的結構和數據也需要相應地進行調整。數據庫升級腳本就是用于實現這些調整的工具。
  數據一致性：運行這些腳本可以確保數據庫的版本與應用的版本保持一致，避免因數據庫結構不匹配而導致的應用故障。同時，它還能保證數據的完整性和一致性，為應用的正常運行提供堅實的基礎。

部署服務（Deployment Services）

Deployment Controller Service（部署控制器服務）

• 協調部署工作：作為整個部署流程的核心協調者，Deployment Controller Service 負責統籌與所有 Deployment Service 的交互。當有新應用需要部署或者現有應用需要更新時，它會與各個 Deployment Service 進行通信，確保部署操作有序進行。
  例如，在大型企業級應用部署場景中，可能存在多個前端服務器，每個服務器都有對應的 Deployment Service，部署控制器服務要確保所有這些服務同步工作，避免出現部署沖突或不一致的情況。
• 代碼分發：該服務會將代碼生成器生成的應用代碼分發到每個前端服務器對應的 Deployment Service 中。它依據預設的規則和配置，準確地把代碼傳遞給相應的服務，為后續在各個應用服務器上的部署做好準備。

Deployment Service（部署服務）

• 前端服務器專屬：每個前端服務器都配備一個獨立的 Deployment Service。這種一對一的配置模式保證了每個前端服務器的部署工作可以獨立進行，提高了部署的靈活性和可維護性。即使某個前端服務器出現問題，也不會影響其他服務器的部署操作。
  

• 應用部署執行：Deployment Service 的主要任務是將接收到的應用代碼部署到對應的應用服務器上。它負責處理部署過程中的具體操作，如創建應用實例、配置運行環境、啟動應用服務等。通過與應用服務器的交互，確保應用能夠在目標服務器上正常運行。
  

服務如何協調部署?

OutSystems Deployment Services 各服務通過有序的協作流程來完成應用的部署，具體協調部署的方式如下：

1、前期準備與代碼生成階段

• 部署控制器服務與代碼生成器服務協作編譯：Deployment Controller Service（部署控制器服務）主動發起與 Code Generator Service（代碼生成器服務）的協作。它將應用的相關配置、需求等信息傳達給代碼生成器服務，二者共同確定代碼生成的規則和方向，為后續的代碼生成工作做好準備。
• 代碼生成器服務更新數據庫：Code Generator Service 在明確編譯要求后，著手對數據庫進行更新操作。它依據應用的數據模型變化，對數據庫的表結構、字段等進行調整，確保數據庫與應用的功能需求相匹配，保證后續應用與數據庫交互的準確性。
  

2、代碼編譯與分發階段

• 部署控制器服務編譯代碼：在代碼生成器服務完成數據庫更新和代碼生成后，Deployment Controller Service 對生成的應用代碼進行編譯。此過程中，它會檢查代碼的語法錯誤、解析依賴關系，并對代碼進行優化，使代碼達到可部署的標準。
• 部署控制器服務分發代碼：編譯完成后，Deployment Controller Service 將編譯好的代碼發送給每個前端服務器上的 Deployment Service（部署服務）。每個前端服務器都有自己獨立的部署服務，負責接收和處理來自部署控制器服務的代碼。
  

3、部署執行與監控階段

• 部署服務執行部署：各個前端服務器上的 Deployment Service 接收到編譯好的代碼后，開始在對應的應用服務器上執行部署操作。這包括創建應用實例、配置運行環境、啟動應用服務等一系列具體步驟，確保應用能夠在目標服務器上正常運行。

• 部署控制器服務監控部署：Deployment Controller Service 會對所有前端服務器上的 Deployment Service 的部署過程進行實時監控。它會跟蹤部署的進度、檢查是否出現錯誤等情況，以確保應用能夠成功安裝。
  

• 失敗處理機制：如果在監控過程中發現某個部署服務的部署失敗，Deployment Controller Service 會啟動后臺重試機制，嘗試重新進行部署。它會按照預設的規則進行多次重試，以解決可能出現的臨時性問題，如網絡波動、資源短暫不足等。如果經過多次重試后部署仍然失敗，Deployment Controller Service 會取消該次部署，避免資源的進一步浪費，并可能觸發相應的錯誤處理流程，通知相關人員進行排查和修復。
  
  

4、緩存更新階段

• 緩存失效服務通知前端服務器：當應用部署成功后，Cache Invalidation Service（緩存失效服務）會發揮作用。它采用發布 / 訂閱模式，通過 RabbitMQ 消息代理來通知前端服務器。由于應用部署可能會導致數據、頁面等發生變化，前端服務器的緩存可能不再準確，因此緩存失效服務會告知前端服務器更新緩存，以保證用戶訪問到的是最新的應用內容。
  

如何監控部署服務？

• 通過 Service Center 監控部署服務
  在 OutSystems 生態系統里，借助 Service Center （服務中心）對 Deployment Services（部署服務）進行監控是保障應用穩定運行和高效部署的關鍵環節。
  
  

應用程序服務（Application Services）

調度服務（Scheduler Service）

在 OutSystems 平臺里，Scheduler Service（調度服務）是執行異步任務的關鍵組件，它能夠處理多種類型的異步任務，如定時器任務、郵件發送任務以及業務流程任務，這極大地增強了應用的自動化和靈活性。

1、執行定時器（Timers）任務

• 任務原理：定時器任務允許開發者根據預設的時間間隔或特定時間點來觸發相應的操作。Scheduler Service 會持續監控時間，當達到預設的時間條件時，就會自動執行對應的任務。
• 應用場景：在電商應用中，可以設置定時器任務在每天凌晨對商品庫存進行自動盤點；在新聞資訊類應用里，可定時抓取最新的新聞內容。
• 配置與管理：在 OutSystems 的開發環境中，開發者能夠方便地配置定時器任務的執行時間和要執行的邏輯。通過簡單的設置，就能讓 Scheduler Service 按照要求執行任務，并且可以隨時對這些任務進行修改或刪除。

2、執行郵件（Emails）任務

• 任務原理：當應用需要發送郵件時，Scheduler Service 會將郵件發送任務作為異步任務處理。它會負責管理郵件的排隊、發送和重試機制，確保郵件能夠準確無誤地發送到目標收件人手中。
• 應用場景：常用于用戶注冊成功后的歡迎郵件發送、訂單狀態變更通知、系統異常告警等場景。例如，當用戶在電商平臺下單后，系統會立即觸發郵件發送任務，通知用戶訂單已成功創建。
• 優勢：采用異步方式發送郵件，避免了因郵件發送過程中的網絡延遲或其他問題而阻塞應用的正常運行，保證了應用的響應速度和性能。

3、執行業務流程（Business Processes）任務

• 任務原理：對于復雜的業務流程，Scheduler Service 可以將其拆分成多個步驟，并以異步的方式依次執行。它能夠根據業務規則和流程定義，自動調度各個步驟的執行順序和時間。
• 應用場景：在企業的審批流程中，當員工提交請假申請后，Scheduler Service 會自動觸發審批流程，依次通知相關的審批人員進行審批，同時記錄審批狀態和時間。
• 靈活性與可擴展性：這種異步執行業務流程的方式使得業務流程的調整和擴展變得更加容易。開發者可以根據業務需求隨時修改流程定義，而無需對整個應用進行大規模的改動。

它是如何工作的？

1、任務入隊機制

• 應用添加任務到隊列：當應用程序需要執行一些定時操作、發送郵件或者執行業務流程時，會將相應的任務信息添加到一個隊列中。這個隊列就像是一個任務的 “待辦清單”，所有等待執行的任務都會按照一定的規則依次排列。
  例如，一個電商應用在用戶下單后，會將發送訂單確認郵件的任務添加到隊列中。
  

2、任務執行調度

• 獲取并觸發任務執行：Scheduler Service 會不斷地從隊列中獲取任務，并將其分配到可用的前端服務器上執行。它會根據前端服務器的負載情況、資源可用性等因素進行智能調度，確保任務能夠在合適的時機和服務器上得到處理。
  例如，如果某臺前端服務器當前負載較低，調度服務就會優先將任務分配給它。

3、每個前端服務器默認線程分配

• 定時器任務線程 （默認3 個線程）：每臺前端服務器默認配備 3 個線程來運行定時器任務。定時器任務通常是按照預設的時間間隔或特定時間點觸發的操作，如每天凌晨的數據備份、每小時的系統監控等。這 3個線程可以同時處理多個定時器任務，提高任務執行的效率。
• 郵件任務線程（默認2 個線程）：有 2 個線程專門用于運行郵件任務。當應用需要發送郵件時，調度服務會將郵件任務分配給這 2 個線程中的一個進行處理。由于郵件發送可能涉及到網絡延遲等因素，多個線程可以并行處理郵件任務，減少郵件發送的等待時間。
• 業務流程任務線程（默認10 個線程）：每臺前端服務器默認有 10 個線程來運行業務流程任務。業務流程通常包含多個步驟和復雜的邏輯，需要更多的計算資源和處理時間。10個線程可以同時處理多個業務流程任務，確保業務流程能夠高效、流暢地執行。

日志機制（Log Mechanism）

OutSystems 的日志機制通過應用程序調用內部 API 寫入日志、日志機制服務進行分類處理和轉發，最后按日志類型將日志分離存儲到多個數據庫表中的方式，實現了高效、靈活的日志管理。這種設計不僅方便了對不同類型日志的管理和分析，還提高了系統的可維護性和問題排查的效率。

1、應用程序寫入日志條目

• 使用內部 API：應用程序在運行過程中，當需要記錄某些事件、錯誤信息、業務操作等日志時，會調用 OutSystems 提供的內部 API。這個 API 為應用程序提供了一種標準化的方式來創建和寫入日志條目。
  例如，當一個電商應用中的用戶完成一次下單操作時，應用可以使用該 API 記錄下單的時間、訂單編號、用戶信息等相關日志信息。
• 日志內容定制：開發人員可以根據具體需求定制日志的內容，包括日志的級別（如調試、信息、警告、錯誤等）、日志的描述信息以及與日志相關的上下文數據。這樣可以確保記錄的日志能夠準確反映應用程序的運行狀態和發生的事件。
  

2、Log Mechanism 接收并處理信息

• 信息接收：Log Mechanism 服務負責接收應用程序通過內部 API 發送過來的日志信息。它作為日志處理的中間環節，會對這些信息進行初步的處理和整理。
• 信息分類：根據日志的類型（如系統日志、業務日志、安全日志等），Log Mechanism 服務會對接收的日志信息進行分類。不同類型的日志將被發送到不同的數據庫表中進行存儲，以便后續的管理和查詢。例如，系統錯誤日志可能會被存儲在一個專門的錯誤日志表中，而業務操作日志則會被存儲在業務日志表中。
• 信息轉發：經過分類處理后，Log Mechanism 服務會將日志信息發送到對應的數據庫中進行存儲。
  

3、日志信息存儲到數據庫表

• 數據持久化：日志信息最終會被存儲在數據庫的相應表中。每個數據庫表根據日志類型進行設計，包含了與該類型日志相關的字段。例如，錯誤日志表可能包含錯誤代碼、錯誤描述、發生時間、相關的應用模塊等字段；業務日志表可能包含業務操作名稱、操作時間、操作人員、操作結果等字段。
• 數據完整性和一致性：數據庫會確保日志數據的完整性和一致性，通過數據庫的事務處理機制，保證日志信息能夠準確無誤地存儲到相應的表中。同時，數據庫的索引和查詢優化功能也有助于提高日志查詢的效率，方便開發人員和運維人員快速定位和分析問題。
  

Mobile Application Build Service (MABS)

OutSystems 的 Mobile Application Build Service (MABS) 是一項平臺服務，在移動應用開發領域發揮著重要作用，主要用于生成原生應用包，它能夠簡化開發流程，加快開發速度。

MABS是如何工作的？

1、利用 OutSystems 模板創建新項目

• 基礎結構搭建：當開發者使用 MABS 構建移動應用時，首先會借助 OutSystems 提供的模板來創建一個新項目。這些模板就像是預先設計好的藍圖，包含了原生應用的基礎結構，例如基本的文件目錄組織、必要的代碼框架等。
• 默認功能集成：模板還集成了一些默認的應用功能，如用戶界面布局、數據存儲機制、網絡請求功能等。這使得開發者無需從頭開始編寫所有代碼，大大節省了開發時間和精力，能夠快速進入到應用的個性化開發階段。

2、處理應用資源

• 資源收集與整理：在創建項目后，MABS 會開始處理應用所需的各種資源。這包括應用的圖標，它是應用在設備主屏幕上的視覺標識，需要符合特定的尺寸和格式要求；還有啟動畫面，它在應用啟動時顯示，為用戶提供良好的視覺過渡。此外，還涉及到應用的各種配置文件，這些文件定義了應用的一些基本屬性和行為。
• 資源優化與適配：MABS 會對這些資源進行優化和適配處理。例如，對于圖標，會將其轉換為不同分辨率的版本，以適應各種移動設備的屏幕；對于啟動畫面，會確保其在不同設備上的顯示效果一致。同時，會對配置文件進行驗證和調整，確保其符合目標平臺的要求。

3、選擇移動平臺

• 平臺針對性構建：開發者需要明確指定要構建的移動平臺，是 iOS 還是 Android。不同的平臺有不同的操作系統特性、開發規范和應用市場要求。MABS 會根據所選的平臺，對應用進行針對性的調整和優化。
  例如，在 iOS 平臺上，應用需要遵循蘋果的人機交互指南和 App Store 的審核規則；在 Android 平臺上，則需要考慮不同廠商設備的兼容性和 Google Play 商店的要求。
• 平臺特定代碼生成：MABS 會根據所選平臺生成相應的平臺特定代碼。這些代碼是為了充分利用目標平臺的獨特功能和特性，如 iOS 的 Touch ID、Face ID 功能，或者 Android 的多窗口支持等。

4、添加原生插件

• 功能擴展：原生插件是一些預先開發好的代碼模塊，用于為應用添加額外的功能。開發者可以根據應用的需求選擇合適的原生插件，并將其添加到項目中。
  例如，如果應用需要實現社交媒體分享功能，可以添加社交媒體分享插件；如果需要進行地理位置定位，可以添加地圖和定位插件。
• 插件集成與適配：MABS 會負責將這些插件集成到應用中，并確保它們與所選平臺和應用的其他部分兼容。它會處理插件與應用代碼之間的接口調用、數據傳遞等問題，使得插件能夠無縫地融入應用的整體功能中。

5、添加簽名密鑰

• 安全認證：在移動應用開發中，簽名密鑰是確保應用安全性和完整性的重要手段。對于 iOS 應用，需要使用蘋果開發者賬號生成的簽名證書；對于 Android 應用，需要生成自己的密鑰庫文件。開發者需要將這些簽名密鑰添加到 MABS 中。
• 應用簽名：MABS 會使用這些簽名密鑰對構建好的應用包進行簽名。簽名后的應用包在發布到應用商店或安裝到設備上時，系統會驗證簽名的有效性，以確保應用沒有被篡改，保護用戶的安全。

6、構建移動應用包

• 代碼編譯與打包：在完成上述所有步驟后，MABS 會對應用的代碼進行編譯。它會將開發者編寫的代碼以及集成的插件代碼轉換為目標平臺能夠執行的機器代碼。同時，會將處理好的資源文件和配置文件一起打包成一個完整的應用安裝包，如 iOS 的 .ipa 文件或 Android 的 .apk 文件。
• 輸出結果：最終，MABS 會輸出構建好的移動應用包，開發者可以將其發布到相應的應用商店，供用戶下載和安裝，或者在測試設備上進行安裝和測試。