unity3d多线程加载（Unity中资源动态加载的几种方式比较）

本文目录

• Unity中资源动态加载的几种方式比较
• unity开放世界大地图如何优化
• unity3d是否支持写成多线程程序如果支持的话需要注意什么
• Unity3D多线程之页面和窗口管理
• unity3d 脚本越多效率越低吗
• Unity3D的协程和C#线程之间的区别是什么
• unity3d C#脚本多线程为什么只运行一次
• Unitysocketio在unity3d中需要使用多线程吗

Unity中资源动态加载的几种方式比较

　　您好！
　　用Unity3D制作基于web的网络游戏，不可避免的会用到一个技术-资源动态加载。比如想加载一个大场景的资源，不应该在游戏的开始让用户长时间等待全部资源的加载完毕。应该优先加载用户附近的场景资源，在游戏的过程中，不影响操作的情况下，后台加载剩余的资源，直到所有加载完毕。
　　本文包含一些代码片段讲述实现这个技术的一种方法。本方法不一定是最好的，希望能抛砖引玉。代码是C#写的，用到了Json，还有C#的事件机制。
　　在讲述代码之前，先想象这样一个网络游戏的开发流程。首先美工制作场景资源的3D建模，游戏设计人员把3D建模导进Unity3D，托托拽拽场景，完成后把每个gameobject导出成XXX.unity3d格式的资源文件（参看BuildPipeline），并且把整个场景的信息生成一个配置文件，xml或者Json格式（本文使用Json）。最后还要把资源文件和场景配置文件上传到服务器，最好使用CMS管理。客户端运行游戏时，先读取服务器的场景配置文件，再根据玩家的位置从服务器下载相应的资源文件并加载，然后开始游戏，注意这里并不是下载所有的场景资源。在游戏的过程中，后台继续加载资源直到所有加载完毕。
　　一个简单的场景配置文件的例子：
　　MyDemoSence.txt
　　Json代码
　　{
　　"AssetList" : [{
　　"Name" : "Chair 1",
　　"Source" : "Prefabs/Chair001.unity3d",
　　"Position" : ,
　　"Rotation" :
　　},
　　{
　　"Name" : "Chair 2",
　　"Source" : "Prefabs/Chair001.unity3d",
　　"Position" : ,
　　"Rotation" :
　　},
　　{
　　"Name" : "Vanity",
　　"Source" : "Prefabs/vanity001.unity3d",
　　"Position" : ,
　　"Rotation" :
　　},
　　{

unity开放世界大地图如何优化

大地形数据加载方案
大地形加载考虑到现有的内存机制， 不可能一次性将其加入到内存中，这个问题是显而易见的，其实在游戏开发中经常遇到，比如我们常见的进度条，加载进度条的目的就是等待程序加载场景，进度条只是一个蒙板遮罩而已。大地形的加载，别无他法，只能用分块，这个是大方向，因此作为程序来说，要做的事情是如何分块？块的大小是多少？这些具体的问题我们要根据需求划分，比如飞行模拟器块大小可能就要大一些，因为俯瞰的视角比较大，场景漫游块可以小一些等等，下面我们就以游戏的经典之作——魔兽世界地形加载方案为例给读者先介绍一下它的实现原理，魔兽世界这款游戏实现的就是无缝地图的拼接，所以非常具有参考价值，先看下图所示：
魔兽世界是如何实现无限地图的？其实它也是很多的场景块拼接而成的，我们通过器分析魔兽世界的地形块的大小划分，魔兽世界场景我们称为MapWorld是由一系列MapTile组成，这些MapTile的大小是1600/3 ≈ 533.33m，而每个MapTile又是由 16x16 个MapChunk组成，由此可以计算出每个MapChunk≈33.33m。再就是每个MapChunk又由9x9＋8x8个地形顶点高度，法线，若干贴图层（一般为4层）组成的地表纹理。魔兽世界地形的大小，在这里我们就不讨论了，但它划分块的思想我们是可以借鉴的。
继续分析魔兽世界的分块方法：它们是根据矩阵的方式进行划分的，在XZ平面上进行的，每个块都会包含一定的信息数据的，比如：在XZ（3，3）位置的MapTile，每个MapTile都包含了该tile内使用的贴图、模型实例等等。所谓模型实例也就是我们的道具，可以理解成相同模型在tile内不同摆放位置、大小、角度的信息，它们都是被保存在二进制文件中的，为了节省文件尺寸，模式实例是通过index模型方式保存的，同顶点索引类似，在每个MapTile里面还有贴图信息比如贴图的名字和UV信息等等。本篇课程的分块思维方式跟魔兽世界的类似，会在后面的章节中详细介绍，块分好了以后，下面就是实现原理了。
实现原理：在任何时刻，程序总是保存着玩家所在的及其周围的3x3个MapTile，随着玩家的移动，这些MapTile会被动态更新，新的MapTile被加载以替换被卸载的旧MapTile。为了提高调度效率，魔兽引入了Cache机制，Cache中保存着最多16个MapTile数据。需要加载新的MapTile时，首先会在Cache中查找；卸载的旧MapTile也不会被立刻删除，而是保存在Cache中以备再次调用。由于一段时间内玩家的活动范围通常不会有太大变化，这一Cache策略在应用中表现的非常出色，这是无缝地图的基本原理。地形的动态加载卸载我们会使用多线程去实现，我们会整两个线程：一个线程专门用于加载地形，另一个线程专门用于卸载或隐藏地形MapTile。让我们再来回忆一下游戏的经典之作，游戏场景效果如下所示：
本篇课程实现的方法可以使用两种方式处理块的加载显示问题，一种是利用对象池的方式，预先加载分块地形，根据视距进行检测判断显示那些地块以及隐藏那些地块，在这里并不删掉它们。这样只需要一个线程就可以。另一种方式是利用多线程，起一个线程专门用于移除卸载不在视线范围内的地块，这样可以提升效率，下面介绍使用多线程的加载方案。
多线程实现大地形加载方案
多线程在PC端游戏中使用的比较多，比如可以起一个线程专门进行资源的加载，游戏服务器中同样也会有多线程的使用，下面给读者介绍多线程实现方案，多线程处理问题就是把所有的加载逻辑放到了新的进程中，和主线程做一些进程间的通信，接受主线程的加载建议，做按需加载，也会自主做一些提前预加载，放进分配的内存，就跟魔兽世界的处理方式一样，通过进程间的内存共享机制，把加载的地形数据，共享给主进程使用。主游戏进程，永远只要维护一个很小的内存即可，大量的内存数据，都在另一个进程中处理。这样就可以优化大地形块的加载，实现方式如下所示：
首先主线程会先加载九块地形，主线程只负责维护这九块地形，无论角色怎么移动，角色所在的整个区域永远是九块地形，如上图所示的，这九块可以直接使用主线程加载到内存中，剩下的16块我们通过另一个线程将其放到缓存中，角色的位置是在已经加载好的九块地形中间，也就是在A所在的位置。随着角色的移动，会有新的地形块加入进来，同时现有的地形块会被置换出去，这样一直显示九块地形，被置换的地形并不会马上卸载掉，会根据角色移动情况做预判，它会等主线程通知，按照一定的规则进行卸载地块和加载地块。其实这种实现方式就是我们通常所说的双缓存-多线程技术。实现的效果如下所示：
地形分块加载完事了后，下面就要考虑地形上面的纹理贴图问题了，地形的贴图资源也会占用大的内存，下面介绍如何加载海量贴图数据。
大地形海量图片的加载方案
大地形中的场景图片非常多，地形中的贴图至少会有四层，这么多贴图我们在加载时需要考虑的，我们分块时也需要考虑这些因素，另外场景中使用的LightMap烘培也是要考虑的问题，为了缓解内存压力，我们事先会将不同块中的地形材质以及建筑物材质进行打包，先介绍如何分块加载场景贴图？它实现方式如下所示：
该思路就是将场景中的贴图根据我们划分的块打成不同的图集，当然也可以将两个块中的贴图打成一个图集，图集大小对于PC端来说，最大是4096，在移动端最大是2048。这个也是为了避免内存频繁的加载卸载会导致很多内存碎片，不利于后面大内存的分配。在打图集之前我们需要做点事情就是需要将地形块中的纹理贴图与我们的打包图集之间建立一一对应关系，方便对号入座。因为我们打包的图集跟实际地形之间不会有任何关系，要确立二者之间的对应关系我们需要在它们中间再整一张索引文件表格，它是连接图集与实际地形纹理的桥梁，通过我们建的索引文件，我们可以找到实际地形中纹理与图集纹理之间的对应关系，我们建的索引表格是要加载到内存中的，而我们的图集是根据加载任务后期才加到内存中的，这就要求我们的索引文件尽可能的少，因为它们是常驻内存的，除了海量图片的加载，我们还需要处理密集建筑的加载。
- 密集建筑的加载方案
密集的建筑加载，大家试想一下，如果把场景中所有的建筑一次性加载到内存中，内存瞬间就会占满，帧数瞬间下降，这也是为什么大家在游戏场景中移动时，遇到密集的建筑就会卡顿一下的原因。以前处理方式是使用LOD处理，被遮挡的物体使用简模，这样也会加大内存的负载效果，如果角色一直在建筑物之间来回穿梭，这样不同LOD模型就需要来回切换，对内存也是一个负担，效果不理想。这些问题对于程序员面来说必须解决的问题，如何解决呢？很多人想到了合并大Mesh，这种方法行不通的，大网格并不适合做裁剪操作，试想一下，我们合并的网格，如果摄像机只看其一小部分，因为它们是一个整体这样就需要把他们一起加载到内存中，而实际上我们并不需要这么多模型数据，在合并网格时，在这里也给读者一个建议，尽量把靠的很近的模型进行合并，避免上述问题发生。其实最有效解决方案还是划分块，这个划分块可以利用地形划分的思想进行，它是与地形块紧密相关的，每个地形块中的建筑物跟随地形块一起加载。如果块中的建筑非常密集，这种方法还不能够完全解决，还需要进一步的处理，就是要加入OC遮挡算法结合LOD算法，这样就可以完全解决我们当前的问题了，这也是本篇课程
要讲解的方法，再进一步的优化方法是可以将OC遮挡算法和LOD算法放到GPU中计算，这样效率还会提升，在Siggraph3015发表了一篇文章GPU-Driven Rendering Pipelines，它的思想就是使用GPU进行遮挡裁剪处理，主要分两个阶段，使用的是DX12图形API，如下图所示：
它的思想就是第一步先做一个初略的遮挡裁剪列表，而后在此基础上再根据视线距离或者射线检测做进一步的细化裁剪操作，这个思想跟我们的碰撞检测算法类似，引擎中碰撞检测算法也是基于这个原理实现的，给读者介绍一下：实际可用的碰撞检测算法，一般要分2个阶段：
第一阶段，broad phase 快速找出潜在的碰撞物体对列表，不在这个列表里的是绝对没可能碰撞的。broad phase确定了一批需要进一步检查的物体对。
第二阶段，narrow phase 准确找出发生碰撞的物体对列表。因为上一个阶段的部分物体对实际上是没有碰撞的，需要在这个阶段剔除。
broad phase其中有一个简单算法叫sweep and prune(SAP)，本质上是利用了排序算法。第一步是初始化排序列表，列表中的元素是包围盒，可以用任意排序算法完成，例如快排；之后的排序就不是用快排了，而是用冒泡排序，为什么用冒泡排序更好呢？是因为一个默认的前提：物体的运动有时间相关性（temporal coherence），即当前帧和下一帧的位置是相近的，所以在冒泡排序过程中，发生的位置交换预期都很靠近。
其实算法中有很多类似的地方，这里我们也要互相借鉴它们解决问题的思想用于解决我们的问题。笔者以前做的是端游，端游中很多优化思想同样适用于移动端，移动端跟PC端比，就是一台配置比较低的电脑而已。接着我们的遮挡裁剪继续给读者介绍，论文作者也做了一个效率测试，以250’000物体，1G的网格为例，测试效果如下所示：
是不是很酷啊！在项目开发中完全可以用它解决问题，下面我们再谈谈使用GPU去优化我们的大地形场景。
GPU大地形渲染优化解决方案
我们的大地形首先会有自己的地表贴图，常用的地表贴图是四张纹理融合，最多可以有八张贴图融合，地形纹理渲染会涉及到LOD算法，远处的地形网格可以简化一些，对应的贴图也是最低的，这就是MipMap的使用。另外肯定有草有花以及其他大量相同的物件渲染，先说说草和花的绘制，他们在游戏中会非常的多，常用的做法是引擎提供的面片或者是十字交叉，或者三张图片交叉，然后将带有Alpha通道的贴图映射在上面，如下图所示效果：
CPU绘制这些草或者花在PC端是可以的，因为现在的电脑都是多核的，在手机端就会影响到效率问题了。使用CPU绘制，DrawCall会非常的多，而且草或者花还需要摆动，计算量很大的，这严重影响了运行效率，CPU有难，GPU可以帮忙，我们可以将草或者花的绘制放到GPU中执行，效果如下所示：

unity3d是否支持写成多线程程序如果支持的话需要注意什么

仅能从主线程中访问Unity3D的组件，对象和Unity3D系统调用
支持：如果同时你要处理很多事情或者与Unity的对象互动小可以用thread,否则使用coroutine。
注意：C#中有lock这个关键字,以确保只有一个线程可以在特定时间内访问特定的对象

Unity3D多线程之页面和窗口管理

先附上git地址

***隐藏网址***

主要基类UIbase

public ModelElement Parent { get; protected set; }//当前UI的父元素

public ModelElement model { get; protected set; }//当前模型

public T LoadUI《T》(string asset, string name)//从asset中载入UI模型
UI模型需要先注册

 class ModelManagerUI

{

 /// 载入模型数据

/// 《param name="buff"》模型二进制数据《/param》

/// 《param name="name"》注册asset名《/param》

/// 《returns》《/returns》

public unsafe static PrefabAsset LoadModels(byte buff, string name)

}

使用示例

public TextAsset baseUI;

    // Start is called before the first frame update

    void Start()

    {

        App.Initial(transform as RectTransform);

        ModelManagerUI.LoadModels(baseUI.bytes, "baseUI");

#if UNITY_EDITOR

        AssetBundle.UnloadAllAssetBundles(true);

#endif

        ElementAsset.LoadAssetsAsync("base.unity3d").PlayOver = (o, e) =》

        {

            UIPage.LoadPage《TestPage》();

        };

    }

UIpage之间的相互切换，UIpage继承于UIbase

示例页面之间切换

A页面

class A:UIPage

{

class View

{

        public EventCallBack Last;

        public EventCallBack Next;

}

View view;

public override void Initial(ModelElement parent, object dat = null)

    {

        view = LoadUI《View》("baseUI","a");

        base.Initial(parent, dat);

        view.Last.Click = (o, e) =》 { LoadPage《B》(); };

        view.Next.Click = (o, e) =》 { LoadPage《B》(); };

}

}

B页面

class A:UIPage

{

class View

{

        public EventCallBack Last;

        public EventCallBack Next;

}

View view;

public override void Initial(ModelElement parent, object dat = null)

{

         view = LoadUI《View》("baseUI","b");

        base.Initial(parent, dat);

       view.Last.Click = (o, e) =》 { LoadPage《A》 (); };

        view.Next.Click = (o, e) =》 { LoadPage《A》(); };

}

}

在UIPage中弹一个窗口，当再次调用时会隐藏当前窗口，显示新窗口

protected T ShowPopWindow《T》(object obj = null, huqiang.UI.ModelElement parent = null) where T : PopWindow, new()

public PopWindow currentPop { get; private set; }//当前窗口

public void HidePopWindow()//隐藏当前窗口，如果存在

public void ReleasePopWindow()//释放掉当前未激活的弹窗

public void ReleasePopWindow《T》()//释放掉该类型的窗口

public void ReleasePopWindow(PopWindow window)//释放掉改实例窗口

public T GetPopWindow《T》() where T : PopWindow//获取该类型的窗口

想要显示多个窗口请自行管理，List《PopWindow》 pops;

unity3d 脚本越多效率越低吗

Unity3D的脚本,并非多线程控制...所以其实你把脚本分散,跟集中在一个脚本里,到编译阶段他都是把代码集中起来...理论上是没有区别的...
但是编译器是死的,当脚本过多,定义static过多的时候,可能会弄出一些奇怪的无用功...这种适当地写在同一个脚本里是最好的.
如果你工程过于庞大,维护的时候太头疼...你就要选择了...把调用性很强的写在一起.
至于为什么是非多线程...已经有人做过实验了,顺序是按加载顺序的倒序进行.并且改变其中一个计算次数也不会改变得出结果的顺序...

Unity3D的协程和C#线程之间的区别是什么

【答案】：多线程程序同时运行多个线程 ，而在任一指定时刻只有一个协程在运行，并且这个正在运行的协同程序只在必要时才被挂起。
除主线程之外的线程无法访问Unity3D的对象、组件、方法。
Unity3d没有多线程的概念，不过unity也给我们提供了StartCoroutine(协同程序)和LoadLevelAsync(异步加载关卡)后台加载场景的方法。 StartCoroutine为什么叫协同程序呢，所谓协同，就是当你在StartCoroutine的函数体里处理一段代码时，利用yield语句等待执行结果，这期间不影响主程序的继续执行，可以协同工作。

unity3d C#脚本多线程为什么只运行一次

当你ReadP的方法运行玩了 这个线程就结束 了
如果想不停的运行的话 你可以在ReadP方法利放上死循环
while（true）
{
........
}

Unitysocketio在unity3d中需要使用多线程吗

Unity3D中的多线程。线程是一个相当复杂的话题，但如果掌握了它，就可以从容的使用多个硬件处理器或处理很难划分管理数据块。
如在场景中用A*算法进行大量的数据计算，变形网格中操作大量的顶点，持续的要运行上传数据到服务器，二维码识别等图像处理，如果同时你要处理很多事情或者与Unity的对象互动小可以用thread，否则使用coroutine。
线程是在程序中与其他线程同时运行的进行。在多处理器的计算机上可以做到多个线程的真正的同步，更多的线程取决于有多个处理核心。
Unity3D编程时，总有个主线程执行你的代码，也可以创建额外的线程和主线程同时运行。而Unity中，你仅能从主线程中访问Unity3D的组件，对象和Unity3D系统调用。任何企图访问这些项目的第二个线程都将失败并引发错误，这是一个要重视的一个限制。
所以当你写代码时，你认为一个函数开始并达到它执行的点后返回，同样你做的东西又在另外一个函数中执行，但又没有发生相应的变化。操作系统决定你代码的执行，任何时候,你的代码只能暂时”休眠”掉，然后让另外的代码开始运行。
Unity3D中的多线程及使用多线程
在这个例子中，在第一个线程将A的值加载到CPU寄存器中准备+1后被中断，第二个线程来读取A的值，并减去1000，这时A应该是-950，现在第一个线程重新开始，它在寄存器中的50+1的结果存储于A，A变成了51，而-950已经丢掉了。
从根本上说，要在用多个线程在同时对变量或内存访问时，要采取很多预防措施来确保不会发生这样的事。所以Unity决定从另外线程访问这些变量或者内存是无效的，只是为了避免所有系统和框架对象出现问题。所以要确保一次只有一个线程来修改变量，这不意味着你不能用多线程工作，你可以用”排序”来解决这个问题。
C#中有lock这个关键字,以确保只有一个线程可以在特定时间内访问特定的对象，这里说对象是因为。法锁定一个类型值(value type)或原型(primitive)。
int a = 50;
object guard = new object();
void ThreadOneCode()
{
//一些代码在这
lock(guard)
{
a = a + 1;
}
//其余一些代码在这
}
void ThreadTwoCode()
{
//一些代码在这
lock(guard)
{
a = a - 1000;
}
复制代码
所有都锁定在guard内，保证同一个时间只有一个线程通过guard访问它，你可以使用任何合适的对象。现在你可能会有各种各样的问题，比如你要锁定的不止一件事，可能是互相嵌套的。那我们该怎么办呢?
我们这个类叫Loom，让你可以轻松在另一个线程运行代码,这里有两个要注意的功能:
RunAsync(Action)-在另一个线程上运行的一组代码.
QueueOnMainThread(Action,float time)-运行在主线程的语句(可选延迟).
用Loom.Current访问Loom-创建一个看不见的GameObject用来处理游戏主线程的互动，下面这个例子用Loom来更新一个网格所有的顶点乘的结果。
//缩放一个网格在第二个线程
复制代码