unity几个路径以及热更新原理
1Resources 路径 只读 不能动态的修改
存放内容 预制体(prefabs) - 不容易变化的预制体
prefabs打包的时候 会自动过滤不需要的资源 有利于减小资源大小
主线程加载
Resources类的Load方法
文件夹中的内容打包的时候会被压缩和加密
2streamingAssetsPath 内容会原封不动的打入包中
一般建议存放一些二进制文件 (配置文件,unity资源包(AB文件)等)
特点
只读 不可写
主要存放二进制文件
通过WWW类 读取文件(移动端)
3persistentDataPath 特殊路径 唯一可读写的路径
这个路径在IOS平台是 应用程序的沙盒
但是在安卓Android平台上 它可以是程序的沙盒 也可以是SDcard
并且在打包输出的时候可以设置为沙盒或者SDcard
projectsettings - otherSettings - writePermission
可读写 不同平台路径不同 这个路径下的文件夹 首次运行程序时自动创建
热更新解决方案 将易变资源 还有逻辑 (10版本)放在streamingAssetsPath(资源包AB文件 配置表 Lua文本文件)
从网络端下载版本文件 读取出数据 对比当前服务器版本和本地版本版号 例如11版本 从服务器下载最新版本
更新的内容 大小等相关数据 MD5验证
我认为xlua的概念很好,很多人用lua就是为了热更新,如果没有热更新的需求,大多数人是不喜欢lua,或者所谓的脚本开发的,xlua很好的解决了这部分人得需求。
但我有一点其他看法,我04年毕业在网易工作的时候,网易的游戏都是基于脚本的,不管是客户端,还是服务器端,那个时候不是lua,就是python,还有一种是类似c语法的脚本(我忘记名字了),这个是云风主导的,当时选择脚本作为逻辑开发语言的核心想法不是为了热更新,而是解决
1)划分引擎层和业务层,svn管理好权限,让新来的同学,接触不到核心引擎的代码权限,他们只能在脚本层做业务,等你对业务足够熟悉,对引擎足够了解,对公司足够忠诚后,才开放引擎层代码,这么做早年是为了解决私服问题,很多同学拿着全部源代码去架设私服,这多可怕,所以做业务的程序员只能拿到一个编译后的app和一份脚本接口文档,而编译出来的app会检查线上ip,报告非法服务器地址等,协助打击私服。
2)避免书写不好的c、cpp代码崩溃整个进程,脚本代码出错了,最多影响局部逻辑,还可以上报脚本错误,方便后续解决问题,现在unity里也一样,如果c#代码书写不好,就直接闪退了,不如用lua做一个安全的调用层。
3)快速修改代码,快速跑起来,早年cpp代码编译速度比较慢,修改一行代码调试运行等半天,脚本代码方便修改,方便跑起来,不用等,放到今天也一样,同时iOS还有text size大小的限制,太多的stub function会撑大text size,而lua脚本再多的代码也不会有这个问题,不用再为了text size取舍代码怎么写,功能去留的问题。
4)反外挂,对,你没看错,反外挂,早年PE各种脱壳、反编译工具,使得一个exe几乎没有秘密,外挂作者很容易做外挂,而用脚本后,几乎所有逻辑都是中间代码,这部分中间代码可以通过修改opcode,加密,一边run,一边解密等技术,保证在进程空间内基本没有完成代码存在,对外挂作者是个很大挑战,所以网易的游戏反外挂历来做的都是最好的;
5)最后才是所谓的“热更新”, 当年也不是现在这种热更新,就是每次客户端启动的时候,有一个launcher去服务器下载一个update,然后应用这个update而已。
Unity没有实现iOS平台代码热更新是因为:
所谓热更新就是指代码可以不通过重新打包提交App Store的方式来更新客户端的执行代码。由于以下几个原因客户端更新希望更加轻量和快速:
App Store的审核周期比较难控制;
手机网络游戏更新频繁;
对于大型游戏,玩家更新成本太大。
所以需要新的代码可以在简单的发布之后可以直接被客户端动态加载执行,而不需要重新提交App Store,玩家也不需要重新下载安装整个程序。
现有的方案是在Unity环境里内嵌一个Lua虚拟机,经常变动的和对执行效率没要求的逻辑用Lua实现,游戏启动时加载服务器上最新的Lua字节码来执行游戏。
如果C#的程序集可以动态加载,就无需嵌入其他的虚拟机来实现动态逻辑。
亲爱的道友们:
近期接到很多玩家反馈集市的摊位太少,一直无法寄售商品。为了保证玩家的游戏体验, 服务器将在26日15:00:00进行紧急在线更新 ,减少商品的寄售时间,加强商品的流通率,减缓压力,提高用户体验。
由于系统热更新时,需要暂停3分钟的集市功能,请各位道友在更新时尽量减少集市操作,谢谢大家的合作。
主要调整内容:
1、需要公示的商品,公示期时间12小时保持不变,转寄售期时,减少寄售期时间为24小时,即寄售24小时没有人购买则会因为超时下架。
2、不需要公示的商品,由原先的24小时寄售期减少为12小时,即寄售12小时没有人购买则会因为超时下架。
0条评论