Android2Unity

Play Asset Delivery实践篇 (踩坑—2021.

2021-07-22  本文已影响0人  北京朝阳区精神病院院长

闲聊

最近一段时间，开始负责一个游戏项目安卓SDK对接工作，又是熟悉的味道还是那个配方。从游戏研发边缘成员折腾回安卓SDK对接工作中(再次入坑)。

马上快8月了Google 上架游戏政策又发生变化，手中对接游戏主要发往海外。所以Google的要求我们还是要满足的。想想发往国内的游戏渠道，真是幸福。

废话说完，进入今天正题。针对Google 8月份新规 游戏这块需要作出调整以应对新规，正好做个记录，以踩坑者的角度去记录一下过程。

1.png

上架Google时间轴

开发者应该着重关注8月份起新政策。新应用8月份上架Google Play 强制API>=30，老应用截止11月份前强制API >=30。同理、同样的操作还有 Play结算库要升级到3.x+版本才被允许上架商店。可参考另一篇博客Google Play-v4.0结算库

8月起，新应用需要使用 Android App Bundle 才能在 Google Play 中发布。对于超过150MB的新应用，谷歌提供两种方式供大家使用，分别是Play Feature Delivery 和 Play Asset Delivery

Google时间轴.png

Android App Bundle 简介

Android App Bundle 是官方提供一种新发布格式(后缀.aab),其中包含应用的所有经过编译的代码和资源。 APK 生成及签名全部交由 Google Play 来处理。

Google Play 会根据你上传的 App Bundle,针对每种设备生成配置，并提供经过优化的 APK，因此只会下载特定设备所需的代码和资源来运行你的应用。

你可以不必再构建、签署和管理多个 APK 来优化对不同设备的支持，而用户也可以获得更小且更优化的下载文件包。

上传 app bundle 时，如果 Play 管理中心发现应用下载大小超过 150MB会收到如下错误提示(我不死心，已经大胆的试了一下。看官们就别在试水了)

2021719-135639.png

有一点需要注意，超过150MB的应用。 Android App Bundle 不支持 APK 扩展 (.obb) 文件，只支持 Play Feature Delivery和Play Asset Delivery两种方式用来替代传统的.obb文件

aab文件.png

Play Feature Delivery和Play Asset Delivery

Play Asset Delivery (后续简称-PAD)将 app bundle 的优势带到游戏中。它允许超过 150 MB 的游戏替换旧版扩展文件 (OBB)，方法是将包含游戏所需的所有资源的单个文件发布到 Play。

PAD 提供了灵活的分发模式、自动更新、压缩和增量修补功能，并且可免费使用。使用 PAD，所有资源包均在 Google Play 上托管和提供，因此你无需使用内容分发网络 (CDN) 向玩家提供游戏资源。

Play Asset Delivery 使用资源包，资源包由资源（如纹理、着色器和声音）组成，但不包含可执行代码。通过 Dynamic Delivery，可以按照以下三种分发模式自定义如何以及何时将各个资源包下载到设备上：安装时分发、快速跟进式分发和按需分发。

Play Feature Delivery(后续简称-PFD)功能模块的独特优势在于能够自定义应用的不同功能如何以及何时下载到搭载 Android 5.0（API 级别 21）或更高版本的设备上。例如，为了减小应用的初始下载大小，你可以将某些功能配置为按需下载，或者只能由支持特定功能（比如拍照或增强现实）的设备下载。

虽然将应用作为 App Bundle 上传时，默认即可获得高度优化的下载文件，但如需使用更高级和可自定义的 Feature Delivery 选项，你就必须使用功能模块对应用的功能进行额外的配置和模块化处理。也就是说，功能模块为你提供了用于创建模块化功能的基块，而你可以将这些功能配置为按需下载。

PAD和PFD推荐选择方式

这两种方式，游戏类应用更建议是用PAD形式，为什么 ？我产生过这样的疑问！！！从字面上来看PAD 翻译过来就是应用资源下发。常规的U3D或者COCOS引擎接入SDK 给到安卓或者IOS，通常是以资源的(Asset)形式输出的，这种方式更符合PAD设计 。

而PFD偏向非游戏类应用(例如电商应用)，它的设计更倾向于模块化性质。如果游戏用了模块化方式无形中增加了游戏代码和设计的成本。所以游戏类型应用不建议PFD方式。

PAD分发模式

PAD下载大小上限

Asset Pack 因具有较高的大小上限而成为大型游戏的理想之选

PAD分发模式选择

游戏在使用 PAD会面临三种模式的选择分别对应着、 安装时分发（install-time）、快速跟进式分发（fast-follow）和按需分发（on-demand）！！！

建议用安装时分发（install-time）方式，对于游戏和SDK压力非常小,清晰明了。基本不需要额外的代码和逻辑。按分发模式文档配置即可简单方便。安装时分发模式的总下载大小为 1 GB，一般的游戏基本不会超过此范围。可以作为初期使用。

PAD实践操作

前置工作

install-time模式配置

目录结构.png install模式.png 
apply plugin: 'com.android.asset-pack'

assetPack {
    // packName 的名称可更改，但是要和配置对应上
    packName = "install_time_asset_pack" 
    dynamicDelivery {
    //只能指定一种类型，对应PAD分发模式
        deliveryType = "install-time"  
    }
}



include ':install_time_asset_pack'   //命名要和packName一致（这段配置可复制）
settings.gradle.png 
android {
 //指定了install-time模式，其他两种模式大同小异
 //命名要和packName一致
    assetPacks = [":install_time_asset_pack"] 
}

dependencies {  
    implementation 'com.google.android.play:core:1.10.0'
}
cocosCreator.png

⚠️此时生成AAB是未签名,仅供测试用。上传到谷歌上会提示该文件未签名

生成aab.png image.png

本地测试Play Asset Delivery

测试没问题的标准！！！aab通过bundletool转换为apks能正常安装，能正常进入游戏 ，各个游戏功能点正常。

注意一点：使用aab转换成apks测试，是如果不指定签名 ，会用安卓默认签名。可能会导致Google支付拉不起，详细用法如下链接：Google文档中bundletool使用

上传谷歌商店测试

本地测试没问题后，建议上传到Google 商店真实的系统的测试一遍。谷歌上传应用时候开启了签名计划，需要秘钥才能提交，按下面三图生成一个名为private_key.pepk秘钥，把生成的秘钥提交至GP，添加测试计划，然后发布内部Beta版供测试需要。

Generate Signed Bundle or APk.png Android App Bundle.png 生成aab签名.png

把aab成功上传到GP后台，会看到如下类似内容，说明上传内容是没问题的。后台会根据你上传包体包含资源进行分发

Lark20210719-140046.png

解惑踩坑过程中出现的问题

问题一：为什么生成出来的AAB 依旧是很大(超越了150MB)？

答: 先通过两种图做个比较便知分晓，下图是正常没有进行分包的，能看到base里面直接600多mb，这种aab提交GP 会出错，错误内容上面已经展示过了

正常的aab内容.png

而下面是经过install-time分发模式分包后的样子 ，可以看到base文件夹其实不到12mb。资源被分到了 install_time_asset_pack文件下。这种方式aab大小没有变化还是600mB, 但是提交Google Play既不会提示出错， 还能正常对外发布。

拆分后的aab内容.png

为什么第二种方式没有问题? 你上传的aab包整体大小没变还是600mb ，但是aab已经包含了分包后的内容，只要你上传到GP后台，剩下内容例如 APK生成及签名、下发设备等全部交由 Google Play 来自动处理。

aab后缀格式本质和apk没区别 是个zip包，当用户实际从Google Play Store点击安装的时候，根据用户设备信息，GP后台服务器通过bundletool工具 下发符合这个设备的apks文件

问题二：文档中明明提到了分发模式有读取路径的操作你为什么没有这个逻辑

答： 如果没有特殊逻辑需求下，只要你gradle远程依赖了core库，路径读取等相关操作 core库自动帮你解决了。Play Core库的作用 就是运行时执行了几个操作，操作内容如下所示：

上一篇 下一篇

猜你喜欢

热点阅读