HBulderX-App云端打包
原文
https://ask.dcloud.net.cn/article/37979
概述
过去,App 云端打包时需要将应用代码、打包证书等提交到 DCloud 云端打包机,在云端打包机的原生开发环境中生成安装包 apk/ipa。
DCloud 云端服务器虽然不会保存开发者应用代码和证书等信息,但开发者可能还是不放心,或者担心在网络传输过程中可能存在拦截泄漏的风险。
而离线打包,不但不方便,还有 2 个重要功能无法使用:
- 原生混淆,保护 js 代码(因为秘钥的安全问题,离线打包无法使用)
- 插件市场的付费原生插件(因为插件版权问题,离线打包无法使用)
HBuilderX2.9.9 版本新增 Android 平台安心打包功能,不再提交应用代码及打包证书到云端服务器,同时也减轻云端打包机压力,缩短高峰期云端打包等待时间。
HBuilderX3.0.7 版本新增 iOS 平台支持安心打包功能(仅支持 MacOS)
安心打包原理
首次打包
- HBuilderX 会提交 App 的模块配置信息到云端,在云端打包机生成
原生代码包
(不包含应用代码、证书信息) - HBuilderX 下载原生代码包,在本地电脑上将
应用代码
添加到原生代码包中,生成未签名安装包
- 缓存原生代码包,用于下次打包复用
- 在本地电脑上使用打包证书对未签名安装包进行签名操作,生成
安装包
- HBuilderX 会提交 App 的模块配置信息到云端,在云端打包机生成
非首次打包
HBuilderX 判断缓存的原生代码包是否可以复用,如果没有修改 App 模块配置或影响原生代码包配置操作继续下一步,否则转
首次打包
流程,以下情况也会触发首次打包
流程:
- 使用了 uni 原生插件,本地无法判断原生插件是否更新了,因此项目中只要包含 uni 原生插件都会走
首次打包
流程 - HBuilderX 更新,本地缓存原生代码包需要更新,需要走
首次打包
流程生成新版本原生代码包
- 使用了 uni 原生插件,本地无法判断原生插件是否更新了,因此项目中只要包含 uni 原生插件都会走
将修改后的应用代码添加到原生代码包中,生成未签名安装包
在本地电脑上使用打包证书对未签名安装包进行签名操作,生成安装包
因为大多数打包,并不改动原生部分(主要是 manifest.json),只修改前端代码。此时将无需从云端打包机下载原生包,打包速度会非常快。
安心打包优势
- 更安全:打包时不提交应用代码、证书等信息
- 更快速:非首次打包时不用提交云端打包机排队等待,本地直接出包
- 省流量:减少了打包时提交打包资源,非首次打包时不用下载原生代码包
- 更便宜:除非使用了体积很大的本地原生插件,否则将难以突破 40M 的免费打包体积阀值。开发者和 DCloud 的成本双下降
使用安心打包
新版本 HBuilderX 云端打包时无需额外操作,默认会勾选 “安心打包”,如下图所示:
如果没有安装安心打包插件,会弹出以下提示框,点击 “安装” 继续
插件安装完成后需重新点击 “打包” 按钮提交打包
打包完成后自动保存到项目的 “unpackage/release/apk/“ 目录
如果清空了这个目录,那么下次打包将执行首次打包逻辑
注意事项
- Windows 环境:仅 Android 平台支持安心打包,iOS 暂不支持;MacOSX 环境:Android 和 ios 都支持安心打包。
- 自定义调试基座不支持安心打包
- 使用 DCloud 老版证书不支持安心打包
- 使用原生混淆时,配置的待加密 js 文件需要提交到云端打包机(打包完成后自动清除这些 js)
- 安心打包并非纯离线打包,虽然证书和前端代码不再提交云端打包机,但项目的 manifest 中的模块配置、本地原生插件、原生混淆配置的前端文件,仍需提交才能出包
- iOS 平台安心打包无法兼容 swift,如果 uni 原生插件使用 swift 开发,提交 appstore 提示 “ITMS-90426: Invalid Swift Support - The SwiftSupport folder is missing. Rebuild your app using the current public (GM) version of Xcode and resubmit it.” 错误时,请改用传统打包
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 王文哲的博客!