关于Unity手游更新的思考

发表于2017-04-14
评论4 6.5k浏览

本篇文章要给大家探讨的是Unity手游更新的更新问题,大家所熟悉的手游安装方式有两种,一种是安装的时候就把程序和资源安装到本地。另外一种是只安装程序和少量的必要资源,然后在启动的时候再把缺少的资源下载完整。

传统的手游更新方法

Android

通常采用覆盖更新的方式,将打包生成并带有对应平台签名的apk上传到平台,平台会根据versionCode判断版本情况提示升级,可通过桌面应用(如应用宝)或手机管家一类的手机应用进行更新。

android系统中的应用可以拉起提示安装apk,基本可以实现内部覆盖升级。

iOS

只能采用上传appstore进行审核更新,审核通过后可以随时点对外发布,但审核周期通常在一周以上。

弊端

由于传统更新方式都采用了更新:更新过程中,需要玩家重新下载整个游戏包并覆盖安装

根据某游戏经历5次做了替包更新,每次更新需要玩家完整下载140M的包体,每次强制更新都有10%以上的流失,从图中可见流失情况十分明显(出现明显凹槽)

而更严重的是iOS的审核机制,会使版本迭代时间变得不确定,严重bug难以发布紧急版本。

思考

我们需要一种增量更新,更新过程中,包括代码和资源变化都无需下载完整包,做差量包。

备注:上述游戏整包替换与热更替换数据对比

对于iOS小版本的更新或修复严重bug的紧急版本需要能绕过审核,发布到外网。

我们要的Unity手游更新方法

目标

l  有从Unity的资源管理到发布成手机版本的一体化流程,做到一键发布版本

l  版本发布做差量更新包,包括资源和代码都可以更新,一般情况下版本发布可绕过苹果iOS审核流程

l  一般开发人员在开发过程中并不需要关注资源在不同平台的差异及发布过程,但使用方式不符合更新流程要有错误提示

l  发布平台支持版本管理、灰度测试、不同运营平台差异化一键发布

l  在代码不需要变动的情况下支持切换多语言文字包和资源包

限制

l  android系统的apkiOS系统的app在安装过以后都不允许修改包内容,既包内容在系统中是只读的,这于pc游戏常使用的更新本地资源的升级方式完全不同

l  iOS系统中的代码只允许以静态编译(AOT)方式发布,在法律政策上也不允许下载并执行代码,并且封了内存(或者堆)的可执行权限,相当于变相的封锁了JIT这种编译方式。

 

Unity手游更新的技术选型

代码更新

由于iOS系统方面的种种限制,静态语言的更新一定要进行苹果审核,并进行整包更新。动态脚本语言则提供了动态更新的可能性,参照市面经过验证的方案,可将luajs作为文本的方式发布到手机上,实现游戏逻辑修改。

版本发布流程

游戏更新流程图

技术方案采用

l  使用自研的资源加载管理器,要求不同平台调用的加载资源接口相同,开发者调用时不需要考虑是从哪个AssetsBundle中加载的,以方便后期AssetsBundle的分布优化

l  使用自研的AssetBundle设置工具,设置过程自动化,减少人工参与,可进行多语言资源包管理,能查重复的资源引用,方便后期优化

 

 

l  使用lua脚本语言进行游戏逻辑开发,并发布为文本文件

l  使用ifs进行release阶段的资源打包和制作版本差异包

l  使用iips来进行手机端资源和版本更新,操作可读写的persistent目录(iOSApplication/[packagename]/Documentsandroid/data/data/[packagename]/files)进行资源版本管理

l  使用soda来管理编译机进行编译

l  使用mtclsTVersion来管理游戏版本和资源版本的对外发布、版本号控制、灰度测试

以上所有打包和发布流程使用脚本串联,减少人工干预

自动化与便利性

主要由更新带来的额外操作有:需要设置每个文件的assetbundle属性;开发过程中每次修改资源都要更新assetbundle文件才能使用;不同端(Editor、手机端)调用加载资源方式不同。

通过上述加载方案既实现了不同端调用相同接口加载资源,资源的更改也不需要更新assetbundle文件,同时assetbundle属性是自动设置的。

 

资源加载流程图

弊端

由于使用ifs进行assetbundle文件的打包与版本差量包制作,那么第一次游戏启动时需要解压资源全量包,第一次启动游戏时间会变长;

需要将游戏assetbundle文件解压到可读写的persistent目录,造成手机空间的浪费(游戏目录下一份资源,persistent目录一份资源)。

可能出现的assetbundle交叉引用资源

进一步思考

使用资源加载重定向的方式可解决第一次启动时间长、手机空间占用大的问题。大版本将游戏资源带在发布包里面,小版本则是解压到persistent目录,再进行资源重定向,每次大版本更新后将persistent目录清空即可。

交叉引用资源问题可通过工具找出再人工排除。

在后期优化中也可以采用后台在wifi环境下预下载更新包等优化手段。

因为已经将游戏中所有资源都分出资源包,所以如果使用首次进入下载资源包、分批下载资源包也都方便切换。

 

 

如社区发表内容存在侵权行为,您可以点击这里查看侵权投诉指引