移动开发中的构建与发布：它的含义、格式及工作方式

构建格式：APK、AAB、IPA

APK 与 AAB

APK（Android Package Kit）— 在 Android 上构建和发布移动应用的传统格式。APK 包含应用的所有代码、资源和清单。AAB（Android App Bundle）— Google 于 2018 年推出并于 2021 年 8 月起对新应用强制使用的格式。AAB 不能直接安装 — Google Play 会根据 AAB 为每个设备动态生成优化的 APK。

AAB 的优势：下载大小平均减少 15%（仅提供所需资源：正确的屏幕密度、语言、CPU 架构）。AAB 还支持模块化交付 — 您可以按需（Play Feature Delivery）或延迟（Play On-Demand）加载模块。对于开发者来说，AAB 是强制性的；对于 Google Play 以外的分发（侧载、应用市场）— 仅使用 APK。

IPA

IPA（iOS App Store Package）— iOS 可安装文件，是一个包含已签名应用的 ZIP 归档文件。IPA 包含 Payload/ 文件夹中的 .app 包、Provisioning Profile 和签名。IPA 仅在 macOS 上通过 Xcode 构建，Xcode 会创建一个归档文件（.xcarchive）并导出 IPA。通过 App Store 分发时，IPA 使用 Apple Distribution Certificate 签名；对于 Ad Hoc 或 Enterprise 分发 — 使用相应的证书。

编译与优化：JIT、AOT、ART、Bitcode

JIT 与 AOT

JIT（Just-In-Time）— 在应用执行期间编译代码，影响构建和发布速度。在 Android 5.0（Lollipop）及更早版本中，使用带有 JIT 编译的 Dalvik VM。每次启动应用时，DEX 字节码会「即时」转换为机器码。缺点：首次启动时速度变慢且额外消耗电量。AOT（Ahead-Of-Time）— 在应用启动之前，安装期间编译代码。从 Android 7.0（Nougat）开始，ART（Android Runtime）在安装期间完全编译应用。

ART（Android Runtime）— 在 Android 5.0 中取代 Dalvik 的运行时环境。ART 采用混合方法：安装时 AOT 编译 + 对频繁执行的方法使用 JIT。这结合了 AOT 的速度（快速启动）和 JIT 的灵活性（自适应优化）。结果：与 Dalvik 相比，Android 应用性能提升了 20-30%。对于开发者来说，过渡到 ART 是透明的 — 代码无需更改。

Bitcode 和 App Thinning

Bitcode — Apple 用于为不同处理器架构重新编译 IPA 的中间代码表示（IR）。Bitcode 是可选的：对于 iOS 应用默认启用，对于 watchOS 和 tvOS 是强制性的。当新处理器发布时，Apple 可以在无需开发者参与的情况下重新编译 Bitcode。App Thinning — Apple 的技术，包括 Slicing（仅提供设备所需的资源）和 On-Demand Resources（按需加载资源）。App Thinning 可将 App Store 的下载大小减少 30-50%。

DEX — Android 的字节码格式，由 ART/Dalvik 执行。Kotlin/Java 源代码编译为 class 文件，然后通过 dx 或 d8（一种现代且更快的工具）转换为 DEX。Multidex — 用于超过单个 DEX 文件中 65,536 个方法限制的应用的机制。在现代项目中，如果 targetSdkVersion >= 21，multidex 会自动启用。

代码签名：Code Signing、Keystore、Provisioning Profile

Android：Keystore

Keystore — 包含用于在构建期间签名 Android 应用的私钥和证书的文件。Keystore 通过 keytool（-genkey 命令）或 Android Studio 创建。重要：Keystore 不能丢失 — 没有它您将无法在 Google Play 上更新应用。签名参数：keyAlias、keyPassword、storePassword 和 storeFile。格式：JKS（Java KeyStore）或用于 AAB 的 PEPK（Play Encrypted Private Key）。

App Bundle ID（Android）— 应用在包命名法中的唯一标识符（com.example.app）。Version Code — 用于内部版本编号的整数（每个新构建都会增加它）。Version Name — 显示给用户的字符串（1.2.3）。这些参数在应用级别的 build.gradle 中设置。

iOS：Apple Certificate 和 Provisioning Profile

Apple Certificate — 验证开发者身份的数字证书。类型：Development（用于调试）、Distribution（用于 App Store）、Ad Hoc（用于有限分发）。证书在 Apple Developer Account 中创建并下载到 Keychain。Provisioning Profile — 连接证书、App ID（Bundle Identifier）和允许设备列表的文件。没有 Provisioning Profile，应用将无法在设备上运行。

Bundle ID（iOS）— 应用的唯一标识符（com.example.app）。Build Number — 构建编号，每次构建都会增加。Marketing Version — 显示给用户的版本。版本管理：对于 iOS，参数在 Info.plist 和 Project Settings 中设置；对于 Android — 在 build.gradle 中设置。在 IT Sectr，我们通过 Fastlane 自动化版本更新 — 这消除了发布时的人为错误。

商店发布流程

Google Play Console

Google Play Console — 用于发布 Android 应用的工具。流程：注册开发者帐户（$25 一次性费用）、创建应用、填写元数据（名称、描述、截屏、类别）、上传 AAB、配置价格和分发、审核。Google 会自动检查应用（病毒、政策合规性），对某些类别还会手动检查。审核需要几小时到 2-3 天。

App Store Connect

App Store Connect — Apple 用于发布 iOS 应用的平台。流程：Apple 开发者帐户（$99/年）、在 App Store Connect 中创建应用、在 Xcode 中准备 IPA（Archive → Distribute App → App Store Connect）、通过 Transporter 或 Xcode 上传、填写元数据、提交审核。App Review — Apple 的手动审核可能需要 24 小时到 7 天。常见的拒绝原因：按钮无法使用、内容不完整、未经解释的权限请求。

Beta 测试：TestFlight、Closed/Open Beta

TestFlight（iOS）

TestFlight — Apple 用于 iOS 应用 Beta 测试的官方工具。TestFlight 支持 Internal Testing（最多 100 名测试人员，通过电子邮件邀请，无需审核）和 External Testing（最多 10,000 名测试人员，需要 Apple 审核）。构建版本有效期为 90 天，之后需要上传新的构建版本。当上传新构建版本时，TestFlight 会自动更新测试人员的应用。

Internal / Closed / Open Beta（Android）

Internal Testing（Android）— 最多 100 名测试人员，无需 Google 审核，构建版本立即可用。Closed Beta — 通过电子邮件或 Google Groups 最多 1000 名测试人员，无需审核。Open Beta — 通过公开链接不限测试人员数量，需要 Google 审核。Staged Rollout — 逐步增加接收更新的用户百分比（5% → 20% → 50% → 100%）。这是最安全的发布方式。

App Thinning（iOS）— 自动减少下载的 IPA 大小：Slicing（仅提供设备所需的资源）、Bitcode（处理器优化）、On-Demand Resources（按需下载）。在 IT Sectr，我们使用 TestFlight 进行 iOS Beta 测试，使用 Internal Testing 进行 Android 测试 — 这使我们在大规模发布前能发现潜在问题。