发布与上架：应用签名与打包（AAB、APK）、Google Play上架流程、国内应用商店上架（华为、小米、OPPO、vivo）、版本更新与热修复

说实话，很多开发者觉得写代码是最难的。但在我看来，把代码变成用户手机里能跑的应用，这个过程才是真正的「最后一公里」。我见过太多项目，功能做得挺好，结果卡在打包签名上，或者上架后被商店驳回。今天咱们就把这摊事彻底捋清楚。

一、应用签名：你的数字身份证

签名是什么？说白了就是给你的 APK 或 AAB 文件盖个章。这个章证明「这个应用是我写的」，别人改不了。Android 系统靠签名来识别应用的作者，同一个包名但签名不同，系统会认为是两个不同的应用。

核心要点：签名文件一定要保管好！丢了签名，你永远无法更新已发布的应用。我曾经有个同事，换电脑时把 keystore 弄丢了，结果那个应用只能永远停在 1.0 版本，最后被迫下架重做。

1. 生成签名文件

Android Studio 里操作很简单：

Build → Generate Signed Bundle / APK → 创建新密钥

填好这些信息：

  • Key store path：签名文件的存放路径，建议放在项目根目录外的安全位置
  • Password：密钥库密码，记牢！
  • Key alias：别名，一个密钥库可以存多个密钥
  • Validity (years)：有效期，Google Play 要求至少 25 年，我一般直接填 30 年

我的习惯：把 keystore 文件备份到两个不同的地方，密码写在物理笔记本上。别问我为什么这么谨慎，问就是吃过亏。

2. 签名配置（build.gradle）

项目里配置签名，这样每次打包就不用手动选了：

android {
    signingConfigs {
        release {
            storeFile file("my-release-key.jks")
            storePassword "密码"
            keyAlias "my-alias"
            keyPassword "密码"
        }
    }
    buildTypes {
        release {
            signingConfig signingConfigs.release
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }
}

注意：千万别把密码硬编码提交到 Git 仓库！我建议用 gradle.properties 文件，或者用 CI/CD 的环境变量来管理。

二、打包格式：APK vs AAB

从 2021 年 8 月开始，Google Play 强制要求新应用使用 AAB 格式。但国内商店目前还是以 APK 为主。嗯，这里要分清楚场景。

对比项 APK AAB
文件大小 较大，包含所有资源 较小，按需分发
分发方式 直接安装 需 Google Play 处理
国内支持 全部支持 部分商店开始支持
签名要求 JKS 或 PKCS12 必须使用 APK Signature Scheme v2/v3

我个人建议：Google Play 用 AAB，国内商店用 APK。这样两边都照顾到。

三、Google Play 上架流程

上架 Google Play 其实不复杂，但有几个坑要注意。我一步步说：

  1. 注册开发者账号：一次性 25 美元，需要 Google 账号和信用卡
  2. 创建应用：在 Google Play Console 里点「创建应用」，填好名称和默认语言
  3. 填写商店信息：
    • 应用说明（短描述和完整描述）
    • 截图（至少 2 张，建议 8 张）
    • 图标、特色图、宣传图
    • 应用分类和标签
  4. 设置定价和分发范围：免费还是付费？哪些国家可以下载？
  5. 上传 AAB 文件：记得用签名后的版本
  6. 审核：通常几小时到几天不等

避坑指南：我曾经因为应用里用了「短信权限」被 Google 驳回三次。后来才知道，Google 对敏感权限审核特别严，必须说明使用场景，还要提供视频演示。所以，能不用敏感权限就别用。

四、国内应用商店上架

国内商店各有各的脾气。我整理了一下主流商店的要点：

华为应用市场

  • 需要企业开发者认证（个人也可以，但限制多）
  • 必须使用华为签名工具重新签名
  • 审核周期：1-3 个工作日
  • 特别注意：华为对隐私政策要求极高，必须提供完整的隐私说明

小米应用商店

  • 个人开发者可以上架
  • 需要提供软著或授权书
  • 审核周期：1-2 个工作日
  • 小米对应用质量要求高，UI 不规范会被驳回

OPPO 软件商店

  • 支持个人开发者
  • 需要提供身份证信息
  • 审核周期：1-2 个工作日
  • OPPO 对广告行为很敏感，别乱弹窗

vivo 应用商店

  • 个人开发者可以上架
  • 需要提供软著或授权书
  • 审核周期：2-3 个工作日
  • vivo 对应用稳定性要求高，崩溃率超过 0.5% 会被下架

我的经验：国内商店上架，最稳妥的做法是先把华为和小米过了。这两家审核最严，过了它们，其他商店基本没问题。

五、版本更新与热修复

应用上线后，版本更新是常态。但怎么让用户无缝升级？这里有两个方案：

1. 常规版本更新

通过应用商店的版本管理功能：

  • 在 build.gradle 里设置 versionCode 和 versionName
  • 每次发布新版本，versionCode 必须递增
  • 商店会根据 versionCode 判断是否需要更新
android {
    defaultConfig {
        versionCode 3
        versionName "1.2.0"
    }
}

2. 热修复

热修复是什么？就是不重新安装应用，直接修复线上 bug。常用的方案有：

  • Tinker（腾讯）：微信团队出品，成熟稳定
  • Sophix（阿里）：接入简单，兼容性好
  • Robust（美团）：即时生效，不需要重启

注意：热修复不是万能的。它只能修复方法级别的 bug，不能修改资源文件、AndroidManifest.xml 或者新增四大组件。说白了，小修小补可以，大动干戈还得走商店更新。

我个人的建议是：常规更新走商店，紧急 bug 用热修复。比如线上有个空指针崩溃，用户一打开就闪退，这时候热修复就派上用场了。我曾经用 Tinker 在 2 小时内修复了一个线上崩溃，用户完全无感知，体验非常好。

六、知识体系总览

下面这张图把本章的核心内容串起来了，你可以对照着看：

应用发布与上架 应用签名 • 生成 keystore • 配置 build.gradle • 签名版本 v2/v3 打包格式 • APK：国内商店 • AAB：Google Play 应用商店上架 • Google Play • 华为、小米 • OPPO、vivo 版本更新 • versionCode 递增 • 商店自动更新 热修复 • Tinker / Sophix • 方法级修复 • 无需重新安装 应用发布与上架知识体系总览

好了，这一章的内容就这些。从签名到打包，从 Google Play 到国内商店，再到版本更新和热修复，每一步都有它的门道。你把这些都掌握了，应用上线这块基本就稳了。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →