unity云服务器（unity 云）

本文目录一览：

• 1、unityecs没有绘制
• 2、远程打开unity太卡
• 3、unity对服务器有什么要求么
• 4、unity3d如何把工程放在云主机上，以便我走到哪里都可以打开编写
• 5、腾讯云云开发-使用Unity开发服务器逻辑并自动部署

unityecs没有绘制

性能；

减少不必要的内存使用

放一张图，之前写了demo测试，对于使用ecs，不使用ecs，做instancing优化3中情况下，性能的差别。

可以看到如果你渲染的object在500以内，ecs性能并没有显著提升，当超过1000后，ecs性能有显著的优势，在10000obj下，差不多100的性能差距。

所以对于200内obj的游戏，是不是用ecs差别不大。

另外ecs这是unity提出的一个系统化的方案和标准，我们自己也可以或多或少使用传统方法做出类似的结果，没必要非ecs不可。

demo是如下图（Instancing），根据自带的rotate demo完成对应的instancing和传统方法版本，这个demo是1000个cube，有一个sphere旋转，撞到cube后，cube会自转一段时间，逐渐停止，所以需要1001个物体不停的update：

=========补充公司内分享的完整文章：

不再需要MonoBehaviour、Component和GameObject

以前MonoBehaviour承载了游戏逻辑和数据两部分功能，我们通过创建GameObject然后添加MB（MonoBehaviour，下同）然后通过Update来更新游戏逻辑，往往我们Update里就是更新一些数据，而MB的实现非常复杂，有很多不需要的功能都一股脑的被继承下来，这导致我们一个非常简单的任务可能需要浪费很多内存去应付那些不需要的功能，如果再无节制的使用MB，那基本就是游戏运行效率的噩梦。

之前的Component是继承自MB，大部分时候Component的作用就是提供数据，但是通过Component组织的数组是对CPU cache不够友好的，因为它并没有把需要多次重复计算更新的数据组织到一起，使得CPU在做计算时可能cache miss，如果游戏逻辑需要大量对象需要更新数据，可能这部分消耗是非常大的。

同时MB不能很好的解决执行顺序问题，对于动态创建的GameObject，MB的更新顺序是不确定的，我们往往系统某些MB的Update和Destroy在某些MB之后，以保证相互的依赖关系，但Unity的MB设计上没有更好的解决这个问题，通过调整Script Execution Order既麻烦也没啥卵用（之前测试对于动态创建的MB毫无作用，只能用于场景中静态的MB）。

还有，如果游戏中存在大量的GameObject，上面绑定大量的Component，那么执行大量的Update是非常耗时的，而且这些Update只能运行在主线程，无法并行。

为此，Unity 2018.2 引入了全新的ECS系统，用于解决上面提到的问题。

全数据化驱动

ECS的核心设计目标就是去掉传统的MB，GameObject，Component对象结构，而改为全数据化驱动的代码组织方式，通过这样的改变，可以解决2个问题：

1）将数据更有效的组织，提高CPU cache利用率；

2）并行化。

先简单看一个例子，这个是ECS sample自带的例子：

这个例子可以看到，虽然画面里有超过1000个物体，但并没有对应1000个GameObject，当球体碰到方块的时候，会产生自转后衰减，同时可以保持在300-600的fps运行帧率。这在以前，我们要实现类似的效果需要创建1000个GameObject，然后有1000个MB负责更新GameObject的transform信息，我按照这样的方法来实现，那么这个demo大概只有1/3的fps。

注意到上图会创建更多的GameObject，fps大概100-200fps之间，当然这么实现并不是最优化的，我们还可以使用Instancing优化drawcall，为了对比我又实现了Instancing的版本，对比如下：

fps大概150-300fps，可以看到instancing大概提高了1倍的fps，在1000 objs测试下，不同实现方法之间差别大概1-2倍，貌似差别不是很大，于是我又测试了更高obj数量的fps，在更高的objs测试下，得到如下图表：

可以看到在更高的obj数量下，ECS方法的优势就体现出来了，在10000 obj下，ECS任然可以做到350的高fps，而即便Instance优化，也只剩下4fps，差距几乎100倍。

现在我们回到开头，ECS解决了如下2个问题：

1）将数据更有效的组织，提高CPU cache利用率；

2）并行化。

但是如何解决的呢？

将数据更有效的组织，提高CPU cache利用率

传统的方法是将gameobject的数据放在Components上，比如可能是这样（参考1）：

using Unity.Mathematics;

class PlayerData// 48 bytes

{

public string public int[]

public quaternion

public float3

string name; // 8 bytes

someValues; // 8 bytes

}

PlayerData players[];

他的内存布局是这样：

而这样的设计对cpu cache是极度不友好的，当你试图批量更新float3数据时，cpu cache预测总是失败的，因为他们被分配到了内存中不连续的区域，cpu需要几次寻址跳转才能找到对应的数据并操作，如果我们能够将需要批量更新的数据连续的存放到一起，这将大大提高cpu cache的命中率，提升计算速度。

按ECS设计规范，就是将批量的更新的数据抽取出来，在内存中连续排列，从而在cache预读中能够将后续的数据一次性读取进来，提高cpu操作的效率，

在实际计算的时候，通过间接索引，来更新全部entity的各个类型的数据，而不是更新每个entity的全部数据，如图：

可以看到这里，最大的变化是：

在一个system（相当于以前的component）更新计算中，是将所有的entity的position放在一起批量更新的，因为这些position的float3数据在内中是连续的，cpu操作起来是最快的。

并行化

将数据单独提取出来后，接下来的任务就是将这些数据计算并行化，充分利用多核。在以前，几乎逻辑代码都是跑在主线程，当然也有项目组意识到了这个问题，会将一些和显示无关的逻辑放入多线程中并行，但都没有彻底的在数据上抽象形成一套完整的开发框架，而ECS解决了这个问题。

ECS开放了底层的job system系统，在上层提供了c# job system，它是一套多线程调度系统。如果不同的数据是无相互依赖的，仅需要将这些数据通过c# job system放入多个线程并行化计算就可以了，如：

public class RotationSpeedSystem : JobComponentSystem

{

struct RotationSpeedRotation : IJobProcessComponentDataRotation, RotationSpeed

{

public float dt;

public void Execute(ref Rotation rotation, [ReadOnly]ref RotationSpeed speed)

{

rotation.Value = math.mul(math.normalize(rotation.Value), quaternion.axisAngle(math.up(), speed.Value * dt));

}

}

protected override JobHandle OnUpdate(JobHandle inputDeps)

{

var job = new RotationSpeedRotation() { dt = Time.deltaTime };

return job.Schedule(this, 64, inputDeps);

}

}

如果不同的数据有依赖，需要其他的数据计算完才能完整计算，则可以设置任务依赖，c# job system会自动完成这样任务的调用和依赖关系排序。

混合模式

目前已经存在大量的传统方式开发的代码，如果想享受到ECS带来的高效，势必要将现有代码大幅改造，有没有相对简单的方法既能保持现有代码没有太大变动，又可以提高效率呢，答案是ECS提供一种兼容的混合模式。

例如如下代码（参考2）：

using Unity.Entities;using UnityEngine;

class Rotator : MonoBehaviour{

// The data - editable in the inspector public float Speed;

}

class RotatorSystem : ComponentSystem{

struct Group

{

// Define what components are required for this // ComponentSystem to handle them. public Transform Transform;

public Rotator Rotator;

}

override protected void OnUpdate()

{

float deltaTime = Time.deltaTime;

// ComponentSystem.GetEntitiesGroup // lets us efficiently iterate over all GameObjects // that have both a Transform Rotator component // (as defined above in Group struct). foreach (var e in GetEntitiesGroup())

{

e.Transform.rotation *= Quaternion.AngleAxis(e.Rotator.Speed * deltaTime, Vector3.up);

}

}

}

主要的修改是把MB的Update函数移到了ComponentSystem的OnUpdate函数中，同时增加了一个Group的struct，用于在MB和ComponentSystem之间交换数据，同时在原GameObject上添加一个GameObjectEntity组件，这个组件的用途是将GameObject其他全部的Component抽取出来并创建一个Entity，这样就可以通过GetEntities函数在ComponentSystem中遍历对应的GameObject了。

Unity会在启动的时候，把所有挂载了GameObjectEntity组件的GameObject，都创建对应ComponentSystem，这样你任然可是使用以前的GameObject.Instantiate方法来创建GameObject。只是原本MB的Update函数被替换到了ComponentSystem的OnUpdate函数中。

通过这样的修改，你可以混合ECS的部分能力又相对保持原本的代码结果，总结来说：

混合模式可以分离数据和行为，可以批量化更新对象的数据，避免每个对象的virtual方法调用（抽象到了一个函数中），任然可以继续使用inspector来观察GameObject的属性和数据。

但是这样修改并没有彻底改善什么，创建、加载的时间没有改善，数据的访问任然是cache不友好的，并没有把数据在内存中连续排布，也没有并行化。

只能说这样修改是为了进一步靠近纯ECS做的阶段性代码重构，最终还是要完全使用纯ECS才能获得最大的性能提升。

远程打开unity太卡

应该是你的电脑配置有点不足，运行大型的软件会占用大量内存和cpu。

游戏的运行与机器的硬件配置直接相关，像unity这类处理图形界面的东西都是需要消耗一些计算机资源的，所以需要的配置也相对好一些。好的配置可以节约时间，开机运行快，硬盘读取速率高(固态盘)，软件硬件运行快，不会因为软件运行环境差而崩溃，游戏娱乐的体验效果更好，看高清电影清晰度音效优越，配置高游戏运行快，配置好的显示器辐射更低，色彩更饱满更清晰，可视角度也更大。

Unity是一款由UnityTechnologies研发的跨平台2D/3D游戏引擎。它以交互的图型化开发环境为首要方式，编译器运行在Windows和MacOSX下，可发布游戏至Windows、Wii、OSX、iOS或HTML5等众多平台。此外，Unity还是被广泛用于建筑可视化、实时三维动画等类型互动内容的综合型创作工具。Unity主要分成免费的Starter版，付费的Pro版，以及免费试用30天Pro版全部功能的试用版。另有未来版本的Beta版提供给付费的Pro版使用者预先使用。不支持linux插件，代之以Nacl技术显示。默认不支持MIDI播放，得通过第三方套件才支持。

unity对服务器有什么要求么

服务器的功能主要是用来给客户端联机，提供积分、登录认证等服务。

所以对服务器的要求主要是根据你具体做的项目来定的，只要你不是大型项目，一般的都可以达到要求。

unity3d如何把工程放在云主机上，以便我走到哪里都可以打开编写

可以使用github或者其他第三方在线版本管理工具

可以让公司买个服务器，将版本管理软件架设在服务器上

腾讯云云开发-使用Unity开发服务器逻辑并自动部署

成亮 大中华区技术经理 Unity 余多 腾讯游戏云高级解决方案架构师 腾讯云