第二十八章 发布与上架：从签名到商店的全流程

说实话，很多开发者觉得写代码是最难的。但在我看来，把写好的代码顺利送到用户手里，才是真正的考验。我自己就见过不少项目，功能做得挺好，结果卡在上架环节——签名不对、版本号冲突、商店审核被拒……折腾好几天。

这一章，咱们就把发布上架这件事彻底讲透。从签名生成开始，到 Google Play 和国内主流商店的上架流程，再到版本管理和多渠道打包。嗯，都是实战中一定会碰到的内容。

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

签名是什么？说白了，就是给 APK 打上一个独一无二的标记。Android 系统通过签名来识别应用的开发者身份。同一个包名，如果签名不一致，系统会认为这是两个不同的应用——这就是为什么你无法直接覆盖安装别人签名的 APK。

我个人习惯用 Android Studio 自带的签名工具，方便又不容易出错。当然，你也可以用命令行 keytool 来生成。

生成签名文件

在 Android Studio 里，操作路径是：Build → Generate Signed Bundle / APK。然后选择 APK（或者 AAB，后面会讲），点击 Create new... 来创建新的密钥库。

这里有几个关键字段，我重点说一下：

• Key store path：密钥库文件的保存路径。建议放在项目根目录下，方便团队共享。
• Password：密钥库密码。千万别忘了，忘了就废了。
• Key alias：密钥别名。一个密钥库可以包含多个密钥，用别名区分。
• Validity (years)：有效期。Google Play 要求签名有效期至少到 2033 年 10 月 22 日之后。我一般直接填 30 年，省心。

签名配置

生成签名文件后，需要在 build.gradle 里配置签名信息：

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

注意：密码直接写在 gradle 文件里不安全。我建议把密码放在 gradle.properties 中，或者用环境变量读取。

Google Play 上架流程

Google Play 是全球最大的 Android 应用市场。上架流程其实不复杂，但有几个坑需要留意。

第一步：注册开发者账号

访问 play.google.com/console，用 Google 账号登录，支付 25 美元的一次性注册费。嗯，这个费用是永久的，之后不再收费。

第二步：准备应用信息

在 Google Play Console 里创建应用后，需要填写：

• 应用名称和描述：简短有力，突出核心功能。
• 截图和视频：至少 2 张截图，建议 8 张。我一般会准备一张功能全景图、几张核心操作截图、一张亮点展示图。
• 应用类别和标签：选对类别有助于用户搜索到你的应用。
• 隐私政策：如果你的应用收集任何用户数据（包括崩溃日志），必须提供隐私政策链接。

第三步：上传应用包

Google Play 现在推荐使用 Android App Bundle（AAB）格式，而不是 APK。AAB 的好处是 Google Play 会根据用户的设备配置（屏幕密度、CPU 架构、语言等）动态生成最优的 APK，能有效减小安装包体积。

在 Android Studio 中生成 AAB：Build → Generate Signed Bundle / APK → Android App Bundle。

第四步：审核与发布

提交后，Google 会进行自动化审核和人工审核。通常几个小时到几天不等。审核通过后，你可以选择「发布」或「分阶段发布」。我建议新应用先做 5% 的分阶段发布，观察崩溃率和用户反馈，没问题再全量发布。

国内应用商店上架

国内的情况比较特殊。商店多、规则杂、审核标准也不一样。我整理了几个主流商店的要点。

商店	开发者注册	审核周期	特殊要求
华为	企业/个人均可，需实名认证	1-3 个工作日	需提供软著或授权书；64 位架构必须支持
小米	企业/个人均可	1-2 个工作日	需提供隐私政策；应用内不能有「小米」相关敏感词
OPPO	企业/个人均可	2-5 个工作日	需提供软著；应用图标不能包含「官方」字样
vivo	企业/个人均可	1-3 个工作日	需提供软著；应用描述不能夸大宣传

你想想看，每个商店都要单独注册、单独上传、单独维护版本。如果手动操作，光是上传 APK 就能累死人。所以，后面讲的多渠道打包就派上用场了。

版本管理：VersionCode 与 VersionName

这两个字段在 build.gradle 里定义：

android {
    defaultConfig {
        versionCode 3
        versionName "1.2.0"
    }
}

VersionCode 是一个整数，用于系统判断版本新旧。每次发布新版本，这个数字必须递增。Google Play 和国内商店都以此为准。我习惯用时间戳来生成 versionCode，比如 20250301 表示 2025 年 3 月 1 日发布的版本。这样一眼就能看出版本的新旧。

VersionName 是展示给用户看的版本号，比如 "1.2.0"。它遵循语义化版本规范：主版本号.次版本号.修订号。主版本号变化表示不兼容的 API 修改，次版本号变化表示新增功能但向后兼容，修订号变化表示 bug 修复。

多渠道打包

多渠道打包，说白了就是一次编译生成多个不同渠道的 APK。每个渠道的 APK 里会嵌入不同的渠道标识，方便统计各渠道的下载量和用户行为。

配置渠道

在 build.gradle 中定义渠道：

android {
    flavorDimensions "channel"
    productFlavors {
        google {
            dimension "channel"
            manifestPlaceholders = [CHANNEL_VALUE: "google"]
        }
        huawei {
            dimension "channel"
            manifestPlaceholders = [CHANNEL_VALUE: "huawei"]
        }
        xiaomi {
            dimension "channel"
            manifestPlaceholders = [CHANNEL_VALUE: "xiaomi"]
        }
        oppo {
            dimension "channel"
            manifestPlaceholders = [CHANNEL_VALUE: "oppo"]
        }
    }
}

然后在 AndroidManifest.xml 中引用渠道占位符：

<meta-data
    android:name="CHANNEL"
    android:value="${CHANNEL_VALUE}" />

这样，打包时每个渠道的 APK 都会自动替换 ${CHANNEL_VALUE} 为对应的渠道名。

打包命令

在终端执行：

./gradlew assembleRelease

这条命令会生成所有渠道的 Release 版本 APK。如果你只想打某个渠道的包：

./gradlew assembleHuaweiRelease

生成的 APK 在 app/build/outputs/apk/ 目录下，按渠道分文件夹存放。

知识体系总览

下面这张图帮你梳理本章的核心逻辑：

这张图把本章的五个核心知识点串在了一起。你可以看到，签名是基础，版本管理是规范，多渠道打包是效率工具，而 Google Play 和国内商店是最终交付的出口。每一步都环环相扣。

好了，这一章的内容就到这里。记住，发布上架不是终点，而是产品与用户见面的起点。把流程标准化、自动化，你就能把更多精力放在真正重要的事情上——把产品做好。

---