unity热更新脚本

‘壹’ unity可以代码热更新吗

可以，目前比较成熟的是用Lua，比如toLua#，题主可以在github关注一下.还有一种是ILRuntime

‘贰’ 为什么Unity没有实现iOS平台代码热更新

IOS不是JIT模式，所以不支持代码热更新。但是现在可以用Lua脚本中转一下实现，IOS类的热更新可以实现的。

‘叁’ unity几个路径以及热更新原理

1.Resources 路径 只读 不能动态的修改

存放内容 预制体（prefabs） - 不容易变化的预制体
prefabs打包的时候 会自动过滤不需要的资源 有利于减小资源大小
主线程加载
Resources类的Load方法
文件夹中的内容打包的时候会被压缩和加密
2.streamingAssetsPath 内容会原封不动的打入包中
一般建议存放一些二进制文件 （配置文件,unity资源包（AB文件）等）
特点
只读 不可写
主要存放二进制文件
通过WWW类 读取文件（移动端）
3.persistentDataPath 特殊路径 唯一可读写的路径
这个路径在IOS平台是 应用程序的沙盒
但是在安卓Android平台上 它可以是程序的沙盒 也可以是SDcard
并且在打包输出的时候可以设置为沙盒或者SDcard
projectsettings - otherSettings - writePermission
可读写 不同平台路径不同 这个路径下的文件夹 首次运行程序时自动创建
热更新解决方案 将易变资源 还有逻辑 （1.0版本）放在streamingAssetsPath（资源包AB文件 配置表 Lua文本文件）
从网络端下载版本文件 读取出数据 对比当前服务器版本和本地版本版号 例如1.1版本 从服务器下载最新版本
更新的内容 大小等相关数据 MD5验证

‘肆’ 为什么Unity没有实现iOS平台代码热更新

刚好听了一节关于Unity iOS热更新的课，获得了一些关于进行热更新的注意事项和重要路径方面的相关知识。现在大概的讲一下，可能不太对，听听就行。

第三，unity热更新有四个重要路径--Resources,Streamingassets,Apllication.datePath,Apllication.persistentDatePath.重点讲一下后两个。Apllication.datePath是属于游戏的数据文件夹的路径，用到的时候很少，是无法进行热更新的。Apllication.persistentDatePath属于持久化数据存储目录的路径，文件夹下的资源无论使用与否都会被打包，运行时有效，可以读写，无内容限制，适合进行热更新。

大概这样，没有具体做过，肯定不全面了。

‘伍’ unity lua 热更新 哪些模块

更新LUa其实也是更新资源。 Lua被看作一个资源么。Lua代码都是运行时才编译的，不运行的时候就如同一张图片、一段音频一样，都是文件资源；所以更新逻辑只需要更新脚本，不需要再编译，因而Lua能轻松实现“热更新”。运行效率由于使用反射，所以成为它与生俱来的诟病。目前有对他的改进，像C#ToLua、Slua。但是Ulua是很成熟的，这个对于项目开发我认为暂时比性能重要！很多人在用，很多坑都已经被人采完。个人比较看好Slua的发展。当然了还有李总的L#走的就不是Lua的路。网上还有说nLua的，我是新手不了解。 看看权威的解释：ulua包含两种c模式（luajit版+原生luavm版），加之tolua c#提供了直接访问渠道。所以追求效率的，请选用ulua。但是ulua因为底层使用luajit，而luajit目前不能在WP平台使用，所以如果ulua支持WP平台需要第二种原生luavm的底层库。nlua包含2种模式（KeraLua c版本）（KopiLuac#版本），它支持全平台，因为c版本底层用的原始的luavm（非luajit）。但是缺少tolua c#的支持，因此效率略低于ulua，但是支持WP平台（其他平台也支持）。unity lua 热更新 哪些模块

‘陆’ 如何评价腾讯在Unity下的xLua热更方案

我认为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怎么用lua做热更新

更新LUa其实也是更新资源。 Lua被看作一个资源么。Lua代码都是运行时才编译的，不运行的时候就如同一张图片、一段音频一样，都是文件资源；所以更新逻辑只需要更新脚本，不需要再编译，因而Lua能轻松实现“热更新”。运行效率由于使用反射

‘捌’ unity3d的热更新一定要花20万么

热更新，是对hot update 或者 hot fix的翻译，计算机术语，表示在不停机的前提下对系统进行更改。
hot 就是热，机器运行会发烫，hot就是不停机的意思。
热更新，是个很形象的词，机器烫的时候更新，开着更新。
比如Windows 不重启的前提下安装补丁
比如Http服务器在不重启的前提下换掉一个文件
那么对于Unity3D来说，何谓热更新？
额……这个真相实在是不想讲出来，因为很多时候，这个词都用错了。
Unity3D是一个客户端工具，用户是否重启客户端，根本是我们不关心的问题。
很多时候我们用着热更新这个词汇，却不需要真的热更新。
只有少部分游戏，游戏资源在玩的过程中边玩边下，不重启的前提下变更了资源。
我们不需要用户不重启客户端就能实现资源代码的更新，我们需要的是用户重启客户端能实现资源代码的更新。

让我们暂时放过这个我们的需求连词汇都用错了这个基本事实，来总结一下何谓Unity3D热更新
Unity3D热更新就是指：用户重启客户端就能实现客户端资源代码更新的需求或者功能。
为何热更新
热更新，能够缩短用户取得新版客户端的流程，改善用户体验。
没有热更新：
pc用户：
下载客户端->等待下载->安装客户端->等待安装->启动->等待加载->玩
手机用户：
商城下载APP->等待下载->等待安装->启动->等待加载->玩
有了热更新
pc用户：
启动->等待热更新->等待加载->玩
有独立loader的pc用户：
启动loader->等待热更新->启动游戏->等待加载->玩
手机用户：
启动->等待热更新->等待加载->玩
通过对比就可以看出，有没有热更新对于用户体验的影响还是挺大的，主要就是省去用户自行更新客户端的步骤。
为了方便用户、留住用户、进而从留住的用户身上赚到钱，热更新如今已经成为了大部分游戏的标配功能。
如果你的游戏不标配这个功能，那么竞争力就会少一些，无论是主动还是被动，无论是方便用户还是被标配，你都必须面对热更新这个课题，虽然这个词用错了。
如何热更新
热更新是为了让用户获得资源和代码的变更，这里的代码不是指真的代码，用户不要代码，他要的是变化的业务逻辑。实现变更的具体过程是首先查并更新本地资源和业务逻辑，如需下载则下载。然后启动时资源均从本地资源创建，业务逻辑从本地执行。
Unity3D提供了一种机制AssetBundle，可以满足所有资源的比对下载加载，但是assetbundle每平台分别打包对于多平台项目而言比较麻烦，是一个明显的短板，而且assetbundle不能脱离unityeditor产生，也是一个麻烦，项目大了话，多人合作，把所有资源都放入assetbundle明显降低效率。
对于代码，Unity3D是不提供变更机制的。但是Unity3D执行核心是Mono，也就是dotnet，dotnet有一种符号反射机制，可以直接加载一个dll，然后反射出其中的类型进行操作。符号和反射的主要问题是有些平台不能使用，比如ios wp8。另外dotnet有一种emit机制，可以运行时调用编译器对代码进行编译，他的问题也是平台不支持。
以上两点是Unity3D免费赠送给你的帮助
如果不能满足你的需求，你就需要自己搞定三个模块：
资源下载模块
当assetbundle不能满足需要时，我们需要自己建立检查更新需要则下载的机制，也就是资源下载模块。
这个资源下载模块应该有一个版本生成工具，我们将一组文件生成一个一个版本待下载。
有一个Unity3D用的下载模块，下载模块会首先检查服务器上的版本信息，和本地信息做比对，需要的文件则下载。
资源加载模块
然后需要建立自己的从下载保存在本地的文件中加载出资源的机制，也就是资源加载模块。
资源加载模块负责从下载的文件中加载出资源。
如果你希望游戏带有一份初始资源文件，这里有两种思路
一种是资源加载模块直接提供从包内文件和下载文件两种加载路径
一种是游戏第一次启动时，将包内文件全部到下载文件
脚本模块
当符号反射不能满足需求时，业务逻辑更新就只有套用脚本语言这一条路，也就是脚本模块。
虽然dotnet世界里有很多脚本可以用 ironRuby ironPython,可是在unity这个特定环境下全部不可用。
你可以使用的一个选择是lua，这个由魔兽世界采用作为界面脚本，从而红遍整个游戏行业，十年经久不衰的脚本。
unity有了很多lua的绑定库，也有了unilua这样的pure c#移植实现。
你还有一个选择是C#Light/Evil，他是C#语法的，pure c#实现的一门新生脚本语言，就是为了Unity3D逻辑热更新而生。

‘玖’ Unity3D开发中热更新为什么不能使用C#的思考

阅读了网上一些文章，其实使用C#进行热更新是可以的，将需要更新的代码打包成程序集，然后利用反射即可，但是也提到在IOS平台是不行的，至于为什么不行，就不再说了，然后就是推荐Lua作为热更新方案，但是，为啥Lua就行？C#就不行？
因为C#是编译型语言，Lua是解释型语言？
好多人都说Lua能热更新，是因为它是解释型语言，不用编译，在运行时能动态解释Lua代码并运行。这种方法实际上不准确，从某些角度来说是错的。Lua确实是解释性脚本语言，但是不是因为是解释型才能进行热更新。即使使用C++这种编译语言，也能进行热更新，将动态链接库进行更新就是，然后动态加载动态链接库获取更新的函数地址即可。
而且，还有一点，C#并不能说是一种编译型语言，C#代码会被编译成IL，IL解释成机器码的过程可以在运行之前进行也能在运行时进行。如果在运行时进行解释，那么和Lua不就一样了吗，为啥C#不能进行热更新呢？
JIT对IL进行解释执行的原理
首先说一下，JIT对IL如何在运行时进行解释并执行的，大致过程为：将IL解释为所在平台的机器码，开辟一段内存空间，要求这段内存空间可读、可写、可执行，然后把解释出的机器码放入，修改CPU中的指令指针寄存器中的地址，让CPU执行之前解释出来的机器码。
注意这段内存的条件，最重要的一条是必须是可执行的，一般的内存申请我们只是存放数据，但是这里的内存权限要是有可执行权限
IOS限制了什么？
IOS不允许获取具有可执行权限的内存空间，这就直接要求JIT要以full AOT模式，这种模式会在生成之前把IL直接翻译成机器码而不是在运行期间，进行了这种操作C#从某种角度来说和C++一样，成为了编译型语言，失去了运行时解释的功能。
Lua的解释执行怎么就行呢？
如果Lua的解释执行原理和C#相同，肯定也不能在IOS平台上运行时解释执行。Lua是使用C编写的脚本语言，它在运行时读入Lua编写的代码，在解释Lua字节码（Lua自己的指令）时不是翻译为机器码，而是使用C代码进行解释，不用开辟特殊的内存空间，也不会有新代码在执行，执行的是Lua的虚拟机，用C写出来的虚拟机，这和C#的机制是完全不同的，因为Lua是基于C的脚本语言。
总结
说白了，就是由于Lua这种脚本语言的特性，基于已经存在的某种语言的一种新的语言，这也是脚本语言和C#、C++这类语言的本质区别。当然，Lua虚拟机不仅可以使用C写，也可以用C#写。使用热更新也不一定非要用Lua，Python同样可以，只不过Lua短小精悍，本身代码长度就不是很大，可以从GitHub上看到。

‘拾’ unity.streamingassets 不能热更新吗

可以实现资源更新 模型贴图Prefab (需要打成assetbundle的包)代码更新的话需要用到脚本迭代