概述（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 会输出构建好的移动应用包，开发者可以将其发布到相应的应用商店，供用户下载和安装，或者在测试设备上进行安装和测试。