1.搭建开发环境
1.1 Node环境
注意 Node 的版本应大于等于 18
node -v
18.19.0
1.2 Java环境
React Native 需要 Java Development Kit [JDK] 17
java --version
java 17.0.12 2024-07-16 LTS
1.3 安装 Android Studio
参考官网即可
1.4 首次调试
- 创建项目:
npx @react-native-community/cli init AwesomeProject
以windows电脑和安卓手机为例
windows电脑最好把防火墙打开,安卓手机通过usb线连接电脑,打开开发者模式,
执行react-native run-android命令,在手机会安装对应的APP
2.打包、签名、上架和版本发布
一、打包流程
1. Android 打包
- 生成签名密钥
在 Windows 上keytool命令放在 JDK 的 bin 目录中(比如C:\Program Files\Java\jdkx.x.x_x\bin),需要在命令行中先进入那个目录才能执行此命令。
keytool -genkeypair -v -keystore my-release-key.keystore -alias my-key-alias -keyalg RSA -keysize 2048 -validity 10000
- 配置签名信息
把签名配置加入到项目的 gradle 配置中android/app/build.gradle
signingConfigs {
release {
storeFile file('my-release-key.keystore')
storePassword 'your-password'
keyAlias 'my-key-alias'
keyPassword 'your-password'
}
}
- 生成APK
cd android && ./gradlew assembleRelease
生成的 APK 文件位于android/app/build/outputs/apk/release/app-release.apk,可以用来发布
password - vx号
如果遇到打包失败,尝试修改 android\build.gradle
buildscript {
repositories {
// 添加阿里云镜像
maven { url 'https://maven.aliyun.com/repository/public' }
maven { url 'https://maven.aliyun.com/repository/google' }
google()
mavenCentral()
}
}
allprojects {
repositories {
// 添加阿里云镜像
maven { url 'https://maven.aliyun.com/repository/public' }
maven { url 'https://maven.aliyun.com/repository/google' }
google()
mavenCentral()
}
}
2. iOS 打包
配置证书和描述文件 Xcode → Signing & Capabilities → Team
清理项目
xcodebuild clean -workspace ios/YourApp.xcworkspace -scheme YourApp -configuration Release
- 打包Archive
xcodebuild archive -workspace ios/YourApp.xcworkspace -scheme YourApp -configuration Release -archivePath build/YourApp.xcarchive
- 导出IPA
xcodebuild -exportArchive -archivePath build/YourApp.xcarchive -exportOptionsPlist ExportOptions.plist -exportPath build
基本是在Xcode上执行
二、签名机制
- 签名作用:
- 身份认证:证明应用由特定开发者发布
- 完整性校验:防止应用被篡改
- 权限控制:应用更新需相同签名
1. Android 签名
使用keystore文件,包含公私钥对
支持V1-V4签名方案,V2之后验证整个APK
通过Gradle配置,支持多环境
相同签名才能更新应用
- 签名文件结构
# 签名密钥库(Keystore)包含:
- 私钥(Private Key):用于签名
- 公钥(Public Key):用于验证
- 证书链(Certificate Chain):包含开发者信息
- 别名(Alias):密钥的标识
- 签名类型对比
| 签名方案 | 引入版本 | 特点 | 安全性 |
|---|---|---|---|
| V1 (JAR签名) | Android 1.0 | 兼容性好,支持所有版本 | 中 |
| V2 (APK签名) | Android 7.0 | 验证整个APK,更快 | 中 |
| V3 (APK签名) | Android 9.0 | 支持密钥轮换 | 中 |
| V4 (APK签名) | Android 11 | 增量签名,支持APK安装器 | 中 |
- 签名验证过程
- 安装时: APK → 提取签名信息 → 验证签名 → 安装
- 启动时: 应用启动 → 系统验证签名 → 允许运行
- 更新时: 新APK签名 = 旧APK签名 → 允许更新 新APK签名 ≠ 旧APK签名 → 拒绝更新
2. iOS 签名
基于证书链体系:根证书→开发者证书
描述文件绑定设备、应用、权限
代码签名确保运行时完整性
每年需要更新证书
- 签名流程
- 生成密钥对: 开发者生成RSA密钥对, 私钥本地保存,公钥提交给Apple
- 创建证书请求(CSR): Keychain Access → 证书助理 → 从证书颁发机构请求证书
- Apple签名证书: Apple用根证书为开发者证书签名 形成证书链:根证书 → 中间证书 → 开发者证书
- 创建描述文件: 包含:App ID、设备ID、证书、权限 由Apple用私钥签名
- 应用签名: 应用 + 描述文件 + 证书 → 签名应用
- 签名验证
安装时验证:
- 验证证书链(Apple根证书 → 开发者证书)
- 验证描述文件签名
- 验证应用签名
运行时验证:
- 验证代码完整性
- 验证权限
- 沙箱限制
Android vs iOS 签名对比
| 方面 | Android | iOS |
|---|---|---|
| 签名文件 | .keystore/.jks | 证书 + 描述文件 |
| 签名方式 | 应用签名 | 代码签名 |
| 有效期 | 可自定义(通常25年) | 固定1年 |
| 更新机制 | 签名不变可更新 | 每年更新证书 |
| 多环境 | 不同keystore文件 | 不同描述文件 |
| 自动化 | Gradle配置 | Fastlane/Xcode配置 |
三、上架流程
1. Google Play 上架
- 准备材料:
- 应用图标(512×512)
- 应用截图(至少2张)
- 应用描述和关键词
- 隐私政策链接
- 年龄分级
- 上架步骤:
- 创建Google Play开发者账号($25一次性费用)
- 创建应用,填写基本信息
- 上传APK/AAB文件
- 填写内容分级问卷
- 设置定价和分发范围
- 提交审核(通常1-2天)
2. App Store 上架
- 准备材料:
- App Store图标(1024×1024)
- 多尺寸截图(6.5寸、5.5寸、12.9寸)
- 应用预览视频(可选)
- 应用描述、关键词、支持URL
- 隐私政策URL
- 上架步骤:
- 创建Apple Developer账号($99/年)
- 在App Store Connect创建应用
- 填写应用信息、元数据
- 上传IPA文件(通过Transporter或Xcode)
- 提交审核(通常1-3天)
- 审核通过后手动发布或定时发布
| 材料 | Google Play | App Store | 国内商店 |
|---|---|---|---|
| 应用图标 | 512×512 | 1024×1024 | 512×512 |
| 截图数量 | 至少2张 | 多尺寸 | 至少3张 |
| 隐私政策 | 必须 | 必须 | 必须 |
| 软著证书 | 不需要 | 不需要 | 必须 |
| 企业认证 | 需要 | 需要 | 需要 |
| 审核时间 | 1-2天 | 1-3天 | 3-5天 |
| 年费 | $25一次性 | $99/年 | 免费/300元 |
四、版本更新
APP版本号组成要素
- APP版本号命名规范最常见由5部分组成:
- <主版本号>
- <子版本号>
- <阶段版本号>
- <日期版本号>
- <字母版本号>
- 各版本号含义
| 版本号 | 含义 | 递增条件 | 示例 |
|---|---|---|---|
| 主版本号 | 不兼容的API修改 | 破坏性变更,不向下兼容 | 1.0.0→ 2.0.0 |
| 次版本号 | 向下兼容的功能性新增 | 新增功能,向后兼容 | 1.0.0→ 1.1.0 |
| 修订号 | 向下兼容的问题修正 | Bug修复,性能优化 | 1.0.0→ 1.0.1 |
- 字母版本号共有5种,分别是:
- Base:假的页面链接,虽包含所有用户界面和功能,但页面功能未完整实现,仅展示可视化基础框架。
- Alpha(α版):以实现软件功能为主,忽视用户界面设计,主要在软件开发者内部用于产品功能的实现性验证。
- Beta(B版):相较于Alpha版有显著改进,消除严重错误,用户页面趋于完整和规范,但仍需多次测试。
- RC(Release Candiate,发布候选版):最终Release版本之前的最后一个版本,相当成熟,不存在致命性Bug,与即将发行的正式版相差无几,是测试通过的“上线版本”。
- Release版本:最终版本,经前面一系列版本后交付给用户使用,一般情况下不会以单词形式出现在软件封面上,取而代之的是符号R。
APP版本兼容性问题及解决方案
| 问题类型 | 具体问题表现 | 核心解决方案 |
|---|---|---|
| 数据存储不兼容 | 数据迁移机制 + 版本化存储 | • 数据库迁移脚本 • 默认值填充策略 • 版本检测与升级 |
| API接口不兼容 | 向后兼容设计 + 字段可选 | • 宽松解析新增字段 • 缺省值处理 • 版本化API端点 |
| 功能模块不兼容 | 功能开关 + 降级方案 | • 动态导入组件 • 版本条件渲染 • 降级功能实现 |
| UI布局不兼容 | 响应式设计 + 渐进增强 | • 版本条件样式 • 组件降级渲染 • 兼容性测试 |
