Unity 性能优化归纳
1、SimpleLOD :
除了同样拥有Mesh Baker所具有的Mesh合并、Atlas烘焙等功能,它还能提供Mesh的简化,并对动态蒙皮网格进行了很好的支持。
该插件可在Run-time和Editor中都可以使用,同时开放了源码,大家可以根据项目的实际情况而作修改。
http://download.csdn.net/download/jasonczy/10178526
一、
转载自 http://blog.csdn.net/game_jqd/article/details/51899000
使用Profiler工具分析内存占用情况
- System.ExecutableAndDlls:系统可执行程序和DLL,是只读的内存,用来执行所有的脚本和DLL引用。不同平台和不同硬件得到的值会不一样,可以通过修改Player Setting的Stripping Level来调节大小。
Ricky:我试着修改了一下Stripping Level似乎没什么改变,感觉虽占用内存大但不会影响游戏运行。我们暂时忽略它吧(- -)!
- GfxClientDevice:GFX(图形加速\图形加速器\显卡 (GraphicsForce Express))客户端设备。
Ricky:虽占用较大内存,但这也是必备项,没办法优化。继续忽略吧(- -)!!
- ManagedHeap.UsedSize:托管堆使用大小。
Ricky:重点监控对象,不要让它超过20MB,否则可能会有性能问题!
- ShaderLab:Unity自带的着色器语言工具相关资源。
Ricky:这个东西大家都比较熟悉了,忽略它吧。
- SerializedFile:序列化文件,把显示中的Prefab、Atlas和metadata等资源加载进内存。
Ricky:重点监控对象,这里就是你要监控的哪些预设在序列化中在内存中占用大小,根据需求进行优化。
- PersistentManager.Remapper:持久化数据重映射管理相关
Ricky:与持久化数据相关,比如AssetBundle之类的。注意监控相关的文件。
- ManagedHeap.ReservedUnusedSize:托管堆预留不使用内存大小,只由Mono使用。
Ricky:无法优化。
- 许多贴图采用的Format格式是ARGB 32 bit所以保真度很高但占用的内存也很大。在不失真的前提下,适当压缩贴图,使用ARGB 16 bit就会减少一倍,如果继续Android采用RGBA Compressed ETC2 8 bits(iOS采用RGBA Compressed PVRTC 4 bits),又可以再减少一倍。把不需要透贴但有alpha通道的贴图,全都转换格式Android:RGB Compressed ETC 4 bits,iOS:RGB Compressed PVRTC 4 bits。
- 当加载一个新的Prefab或贴图,不及时回收,它就会永驻在内存中,就算切换场景也不会销毁。应该确定物体不再使用或长时间不使用就先把物体制空(null),然后调用Resources.UnloadUnusedAssets(),才能真正释放内存。
- 有大量空白的图集贴图,可以用TexturePacker等工具进行优化或考虑合并到其他图集中。
- AudioManager:音频管理器
Ricky:随着音频文件的增多而增大。
- AudioClip:音效及声音文件
Ricky:重点优化对象,播放时长较长的音乐文件需要进行压缩成.mp3或.ogg格式,时长较短的音效文件可以使用.wav 或.aiff格式。
- Cubemap:立方图纹理
Ricky:这个一般在天空盒中比较常见,我也不知道如何优化这个。。。
- Mesh:模型网格
Ricky:主要检查是否有重复的资源,还有尽量减少点面数。
- Mesh:场景中使用的网格模型
Ricky:注意网格模型的点面数,能合并的mesh尽量合并。
1)ManagedHeap.UsedSize: 移动游戏建议不要超过20MB.
2)SerializedFile: 通过异步加载(LoadFromCache、WWW等)的时候留下的序列化文件,可监视是否被卸载.
3)WebStream: 通过异步WWW下载的资源文件在内存中的解压版本,比SerializedFile大几倍或几十倍,不过我们现在项目中展示没有。
4)Texture2D: 重点检查是否有重复资源和超大Memory是否需要压缩等.
5)AnimationClip: 重点检查是否有重复资源.
6)Mesh: 重点检查是否有重复资源.
1.Device.Present:
1)GPU的presentdevice确实非常耗时,一般出现在使用了非常复杂的shader.
2)GPU运行的非常快,而由于Vsync的原因,使得它需要等待较长的时间.
3)同样是Vsync的原因,但其他线程非常耗时,所以导致该等待时间很长,比如:过量AssetBundle加载时容易出现该问题.
4)Shader.CreateGPUProgram:Shader在runtime阶段(非预加载)会出现卡顿(华为K3V2芯片).
5)StackTraceUtility.PostprocessStacktrace()和StackTraceUtility.ExtractStackTrace(): 一般是由Debug.Log或类似API造成,游戏发布后需将Debug API进行屏蔽。
2.Overhead:
1)一般情况为Vsync所致.
2)通常出现在Android设备上.
3.GC.Collect:
原因:
1)代码分配内存过量(恶性的)
2)一定时间间隔由系统调用(良性的).
占用时间:
1)与现有Garbage size相关
2)与剩余内存使用颗粒相关(比如场景物件过多,利用率低的情况下,GC释放后需要做内存重排)
4.GarbageCollectAssetsProfile:
1)引擎在执行UnloadUnusedAssets操作(该操作是比较耗时的,建议在切场景的时候进行)。
2)尽可能地避免使用Unity内建GUI,避免GUI.Repaint过渡GCAllow.
3)if(other.tag == a.tag)改为other.CompareTag(a.tag).因为other.tag为产生180B的GC Allow.
4)少用foreach,因为每次foreach为产生一个enumerator(约16B的内存分配),尽量改为for.
5)Lambda表达式,使用不当会产生内存泄漏.
5.尽量少用LINQ:
1)部分功能无法在某些平台使用.
2)会分配大量GC Allow.
6.控制StartCoroutine的次数:
1)开启一个Coroutine(协程),至少分配37B的内存.
2)Coroutine类的实例 -> 21B.
3)Enumerator -> 16B.
7.使用StringBuilder替代字符串直接连接.
8.缓存组件:
1)每次GetComponent均会分配一定的GC Allow.
2)每次Object.name都会分配39B的堆内存.
.框架设计层面。
一个相对中大型的游戏,系统非常的多。这时候合理的适时的释放内存有助于游戏的正常体验,甚至可以防止内存快速到达峰值,导致设备Crash。
目前主流平台机型可用内存:
Android平台:在客户端最低配置以上,均需满足以下内存消耗指标(PSS):
1)内存1G以下机型:最高PSS<=150MB
2)内存2G的机型:最高PSS<=200MB
iOS平台:在iPhone4S下运行,消耗内存(real mem)不大于150MB
1.场景切换时避开峰值。
当前一个场景还未释放的时候,切换到新的场景。这时候由于两个内存叠加很容易达到内存峰值。解决方案是,在屏幕中间遮盖一个Loading场景。在旧的释放完,并且新的初始化结束后,隐藏Loading场景,使之有效的避开内存大量叠加超过峰值。
2.GUI模块加入生命周期管理。
主角、强化、技能、商城、进化、背包、任务等等。通常一个游戏都少不了这些系统。但要是全部都打开,或者这个时候再点世界地图,外加一些逻辑数据内存的占用等等。你会发现,内存也很快就达到峰值。
这时候有效的管理系统模块生命周期就非常有必要。首先将模块进行划分:
1)经常打开 Cache_10;
2)偶尔打开 Cache_5;
3)只打开一次 Cache_0。
创建一个ModuleMananger 类,内部Render方法每分钟轮询一次。如果是“Cache_0”这个类型,一关闭就直接Destroy释放内存;“Cache_10”这个类型为10分钟后自动释放内存;" Cache_5"这种类型为5分钟后自动释放内存。每次打开模块,该模块就会重新计时。这样就可以有效合理的分配内存。
1、 由于实时对战游戏的数据包数量巨大,早期版本的帧同步策略会导致比较明显的卡顿,通过进行数据包的合并与优化逐渐解决了卡顿问题;
2、 频繁创建和销毁的小兵对象让CPU爆表了,大量的小兵如果采用实时内存的分配和回收,会产生大量的内存碎片和系统开销,解决方法之一就是采用高效的对象池进行优化,对每个内存对象的状态进行操作即可;
3、 性能分析过程中,发现单人同屏和多人同屏时的开销都很大,通过视野裁剪技术,使得玩家视野外的不必要的特效和渲染可以全部关闭,极大降低了CPU、GPU和内存的开销;
4、 在高中低三档机型上玩游戏时,分别加载不同层次的特效包,这也有助于降低CPU和内存的开销;性能分析过程中发现副本内wwise音频组件占了30%的CPU时间,果断抛弃之,采用Unity自带音频功能,优化很明显;
5、 游戏内界面采用了UGUI的方式实现,但大量的实时UI变化使得副本内每帧会有230以上的drawcall,导致中低端机型感受到明显卡顿,最终采用UGUI+自研究UI的组合拳,重写了一套紧密结合游戏自身特性的UI来实现战斗血条和浮动文字的效果。
6、 资源使用总量是否在合理范围之内。
7、 一个场景内的资源重复率。
8、 资源对象拷贝的数量是否合理。
9、 场景切换时保留的资源详情。
10、 网格、纹理、音频、动画、GameObject等资源是否超标。
11、 贴图:
12、 l 控制贴图大小,尽量不要超过 1024x1024;
13、 l 尽量使用2的n次幂大小的贴图,否则GfxDriver里会有2份贴图;
14、 l 尽量使用压缩格式减小贴图大小;
15、 l 若干种贴图合并技术;
16、 l 去除多余的alpha通道;
17、 l 不同设备使用不同的纹理贴图,分层显示;
18、
19、 模型:
20、 l 尽量控制模型的面数,小于1500会比较合适;
21、 l 不同设备使用不同的模型面数;
22、 l 尽量保持在30根骨骼内;
23、 l 一个网格不要超过3个material;
24、 动画:
25、 l N种动画压缩方法;
26、 l 尽量减少骨骼数量;
27、 声音:
28、 l 采用压缩MP3 和 wav;
29、 资源方面的优化:
30、 l 使用 Resource.Load 方法在需要的时候再读取资源;
31、 l 各种资源在使用完成后,尽快用Resource.UnloadAsset和UnloadUnusedAsset卸载掉;
32、 l 灵活运用AssetBundle的Load和Unload方法动态加载资源,避免主要场景内的初始化内存占用过高;(实现起来真的很难…)
33、 l 采用www加载了AssetBundle后,要用www.Dispose 及时释放;
34、 l 在关卡内谨慎使用DontDestroyOnLoad,被标注的资源会常驻内存;
35、 代码的优化:
36、 l 尽量避免代码中的任何字符串连接,因为这会给GC带来太多垃圾;
37、 l 用简单的“for”循环代替“foreach”循环;
38、 l 为所有游戏内的动态物体使用内存对象池,可以减少系统开销和内存碎片,复用对象实例,构建自己的内存管理模式,减少Instantiate和Destory;
39、 l 尽量不使用LINQ命令,因为它们一般会分配中间缓器,而这很容易生成垃圾内存;
40、 l 将引用本地缓存到元件中会减少每次在一个游戏对象中使用 “GetComponent” 获取一个元件引用的需求;
41、 l 减少角色控制器移动命令的调用。移动角色控制器会同步发生,每次调用都会耗损较大的性能;
42、 l 最小化碰撞检测请求(例如raycasts和sphere checks),尽量从每次检查中获得更多信息;
43、 l AI逻辑通常会生成大量物理查询,建议让AI更新循环设置低于图像更新循环,以减少CPU负荷;
44、 l 要尽量减少Unity回调函数,哪怕是空函数也不要留着;(例如空的Update、FixedUpdate函数)
45、 l 尽量少使用FindObjectsOfType函数,这个函数非常慢,尽量少用且一定不要在Update里调用;
46、 l 千万一定要控制mono堆内存的大小;
47、
48、 unity3D 对于移动平台的支持无可厚非,但是也有时候用Unity3D 开发出来的应用、游戏在移动终端上的运行有着明显的效率问题,比如卡、画质等各种问题。自己在做游戏开发的时候偶有所得。对于主要影响性能的因素做个总结。
49、
50、 主要因素有:
51、 1. Savedby batching 值过大 ---- > 这个值主要是针对Mesh的批处理,这个值越高,应用就越卡
52、 2. Drawcall值过大 ---- > Drawcall 值过大,所需要的 GPU 的处理性能较高,从而导致CPU的计算时间过长,于是就卡了
53、 3. 点、面过多 ----> 点、面过多,GPU 根据不同面的效果展开计算,并且CPU计算的数据也多,所以效果出来了,但是卡巴斯基
54、 由于 Saved by batching 和 Drawcall 值过大所引起的卡的问题我所做的优化方式有:
55、 1. 对于模型 :Mesh 合并,有个不错的插件(DrawCallMinimizer ---> 直接上AssetStore 下载即可,免费的,而且有文档,很容易上手)
56、 2. 对于UI : 尽量避免使用Unity3D自带的 GUI 换用 NGUI或者EZGUI;因为这两个UI插件对于UI中的图片处理是将UI图片放置在一个 Atlas中,一个 Atlas 对应一个Drawcall
57、 3. 对于灯光: 可以使用 Unity3D 自带的 Lightmapping插件来烘焙场景中的灯光效果到物体材质上
58、 4. 对于场景: 可以使用 Unity3D 自带的 OcclusionCulling 插件把静止不动的场景元素烘焙出来
59、 4. 对于特效:尽量把材质纹理合并
60、 对于Unity3D 在移动终端上支持的Drawcall 数到底多少,主要是跟机子性能有关的,当然也不是说值小性能就一定没问题(本人亲测,也有17就卡的,主要是模型材质纹理过大所引起的),目前我做的是70左右的,还OK,挺正常的
61、
62、 由于点、面过多所导致的性能问题,最好用简模,用四面体来做复杂的模型,但是面、点也别太多,至于Unity3D 到底支持多少点、面的说法各异,我也搞不懂,总之少些肯定OK
63、
64、
65、
66、 检测方式:
67、 一,Unity3D 渲染统计窗口
68、 Game视窗的Stats去查看渲染统计的信息:
69、 1、FPS
70、 fps其实就是 framesper second,也就是每一秒游戏执行的帧数,这个数值越小,说明游戏越卡。
71、
72、 2、Draw calls
73、 batching之后渲染mesh的数量,和当前渲染到的网格的材质球数量有关。
74、
75、 3、Saved by batching
76、 渲染的批处理数量,这是引擎将多个对象的绘制进行合并从而减少GPU的开销;
77、 很多GUI插件的一个好处就是合并多个对象的渲染,从而降低DrawCalls ,保证游戏帧数。
83、 6、Used Textures 当前帧用于渲染的图片占用内存大小
85、 7、Render Textures 渲染的图片占用内存大小,也就是当然渲染的物体的材质上的纹理总内存占用
87、 8、VRAM usage 显存的使用情况,VRAM总大小取决于你的显卡的显存
89、 9、VBO Total 渲染过程中上载到图形卡的网格的数量,这里注意一点就是缩放的物体可能需要额外的开销。
91、 10、VisibleSkinned Meshes 蒙皮网格的渲染数量
95、 1,运行时尽量减少 Tris 和 Draw Calls
96、 预览的时候,可点开 Stats,查看图形渲染的开销情况。特别注意 Tris 和 Draw Calls 这两个参数。
99、 Draw Calls 保持在 20 以下,有待考证。
100、 2,FPS,每一秒游戏执行的帧数,这个数值越小,说明游戏越卡。
101、 3,Render Textures 渲染的图片占用内存大小。
102、 4,VRAM usage 显存的使用情况,VRAM总大小取决于你的显卡的显存。
107、 function Update() {DoSomeThing(); }
109、 function Update() { if(Time.frameCount% 5 == 0) { DoSomeThing(); } }
110、 2. 定时重复处理用InvokeRepeating 函数实现
111、 比如,启动0.5秒后每隔1秒执行一次 DoSomeThing 函数:
113、 function Start() {InvokeRepeating("DoSomeThing", 0.5, 1.0); }
115、 3. 优化 Update,FixedUpdate, LateUpdate 等每帧处理的函数
118、 function Update() { var pos:Vector3 = transform.position; }
120、 private var pos: Vector3;function Update(){ pos = transform.position; }
124、 function Update() {if(Time.frameCount % 50 == 0) { System.GC.Collect(); } }
127、 比如,如果可以避免使用浮点型(float),尽量使用整形(int),尽量少用复杂的数学函数比如 Sin 和 Cos 等等
132、 使用 GetComponent或内置组件访问器会产生明显的开销。您可以通过一次获取组件的引用来避免开销,并将该引用分配给一个变量(有时称为"缓存"的引用)。例如,如果您使用如下的代码:
134、 transform.Translate(0, 1, 0);
139、 var myTransform : Transform;
144、 myTransform.Translate(0, 1, 0);
152、 Slow and Safe – Mono内部默认的处理异常的调用
159、 如上文所述,您应该尽量避免分配操作。但是,考虑到它们是不能完全杜绝的,所以我们提供两种方法来让您尽量减少它们在游戏运行时的使用:
162、 if (Time.frameCount % 30 == 0)
167、 但是,您应该小心地使用这种技术,并且通过检查Profiler来确保这种操作确实可以降低您游戏的垃圾回收时间
173、 var tmp = newSystem.Object[1024];
177、 for (var i : int = 0; i <1024; i++)
187、 游戏中的暂停是用来对堆内存进行回收,而一个足够大的堆应该不会在游戏的暂停与暂停之间被完全占满。所以,当这种游戏暂停发生时,您可以显式请求一次垃圾回收:
191、 另外,您应该谨慎地使用这一策略并时刻关注Profiler的统计结果,而不是假定它已经达到了您想要的效果。
195、 导入 3D 模型之后,在不影响显示效果的前提下,最好打开 Mesh Compression。
196、 Off, Low, Medium, High 这几个选项,可酌情选取。
197、 2,避免大量使用 Unity 自带的 Sphere 等内建 Mesh
198、 Unity 内建的 Mesh,多边形的数量比较大,如果物体不要求特别圆滑,可导入其他的简单3D模型代替。
200、 1不是每个主流手机都支持的技术(就是如果可以不用就不用或有备选方案)
207、 1.不使用或少使用动态光照,使用light mapping和light probes(光照探头)
208、 2.不使用法线贴图(或者只在主角身上使用),静态物体尽量将法线渲染到贴图
210、 4.不使用fog,使用渐变的面片(参考shadowgun)
211、 5.不要使用alpha–test(如那些cutout shader),使用alpha-blend代替
212、 6.使用尽量少的material,使用尽量少的pass和render次数,如反射、阴影这些操作
213、 7.如有必要,使用Per-LayerCull Distances,Camera.layerCullDistances
214、 8.只使用mobile组里面的那些预置shader
218、 对于相邻动态物体:如果使用相同的shader,将texture合并
219、 对于静态物体,batching要求很高,详见Unity Manual>Advanced>Optimizing Graphics Performance>Draw Call Batching
222、 1. 每个模型只使用一个skinnedmesh renderer
227、 1.真实的物理(刚体)很消耗,不要轻易使用,尽量使用自己的代码模仿假的物理
228、 2.对于投射物不要使用真实物理的碰撞和刚体,用自己的代码处理
230、 4.在edit->projectsetting->time中调大FixedTimestep(真实物理的帧率)来减少cpu损耗
232、 1.尽量不要动态的instantiate和destroyobject,使用object pool
233、 2.尽量不要再update函数中做复杂计算,如有需要,可以隔N帧计算一次
234、 3.不要动态的产生字符串,如Debug.Log("boo"+ "hoo"),尽量预先创建好这些字符串资源
235、 4.cache一些东西,在update里面尽量避免search,如GameObject.FindWithTag("")、GetComponent这样的调用,可以在start中预先存起来
236、 5.尽量减少函数调用栈,用x= (x > 0 ? x : -x);代替x = Mathf.Abs(x)
238、 String的相加操作,会频繁申请内存并释放,导致gc频繁,使用System.Text.StringBuilder代替
239、 functionConcatExample(intArray: int[]) {
240、 varline = intArray[0].ToString();
242、 for(i = 1; i < intArray.Length; i++) {
243、 line+= ", " + intArray[i].ToString();
248、 在函数中动态new array,最好将一个array、传进函数里修改
249、 functionRandomList(numElements: int) {
250、 varresult = new float[numElements];
252、 for(i = 0; i < numElements; i++) {
261、 fixed / lowp -for colors, lighting information and normals,
262、 half / mediump -for texture UV coordinates,
263、 float / highp -avoid in pixel shaders, fine to use in vertex shader for position calculations.
266、 1.不要使用内置的onGUii函数处理gui,使用其他方案,如NGUI
269、 1.贴图压缩格式:ios上尽量使用PVRTC,android上使用ETC
1.为什么需要针对CPU(中央处理器)与GPU(图形处理器)优化?
CPU和GPU都有各自的计算和传输瓶颈,不同的CPU或GPU他们的性能都不一样,所以你的游戏需要为你目标用户的CPU与GPU能力进行针对开发。
GPU一般具有填充率(Fillrate)和内存带宽(Memory Bandwidth)的限制,如果你的游戏在低质量表现的情况下会快很多,那么,你很可能需要限制你在GPU的填充率。
往往渲染(Rendering)并不是一个问题,无论是在GPU和CPU上。很可能是你的脚本代码效率的问题,用Profiler查看下。
关于Profiler介绍:http://docs.unity3d.com/Documentation/Manual/Profiler.html
需要注意的是:
在GPU中显示的RenderTexture.SetActive()占用率很高,是因为你同时打开了编辑窗口的原因,而不是U3D的BUG。
CPU和GPU对顶点的计算处理都很多。GPU中渲染的顶点数取决于GPU性能和SHADER的复杂程度,一般来说,每帧之内,在PC上几百万顶点内,在移动平台上不超过10万顶点。
CPU中的计算主要是在蒙皮骨骼计算,布料模拟,顶点动画,粒子模拟等。GPU则在各种顶点变换、光照、贴图混合等。
为了渲染物体到显示器上,CPU需要做一些工作,如区分哪个东西需要渲染、区分开物体是否受光照影响、使用哪个SHADER并且为SHADER传参、发送绘图命令告诉显示驱动,然后发送命令告诉显卡删除等这些。
假设你有一个上千三角面的模型却用上千个三角型模型来代替,在GPU上花费是差不多的,但是在CPU上则是极其不一样,消耗会大很多很多。为了让CPU更少的工作,需要减少可见物的数目:
a.合并相近的模型,手动在模型编辑器中合并或者使用UNITY的Draw call批处理达到相同效果(Draw call batching)。具体方法和注意事项查看以下链接:
Draw call batching :http://docs.unity3d.com/Documentation/Manual/DrawCallBatching.html
b.在项目中使用更少的材质(material),将几个分开的贴图合成一个较大的图集等方式处理。
如果你需要通过脚本来控制单个材质属性,需要注意改变Renderer.material将会造成一份材质的拷贝。因此,你应该使用Renderer.sharedMaterial来保证材质的共享状态。
有一个合并模型材质不错的插件叫Mesh Baker,大家可以考虑试下。
c.尽量少用一些渲染步骤,例如reflections,shadows,per-pixel light 等。
d.Draw call batching的合并物体,会使每个物体(合并后的物体)至少有几百个三角面。
假设合并的两个物体(手动合并)但不共享材质,不会有性能表现上的提升。多材质的物体相当于两个物体不用一个贴图。所以,为了提升CPU的性能,你应该确保这些物体使用同样的贴图。
另外,用灯光将会取消(break)引擎的DRAW CALL BATCH,至于为什么,查看以下:
e.使用相关剔除数量直接减少Draw Call数量,下文有相关提及。
最基本的两个优化准则:
a.不要有不必要的三角面。
b.UV贴图中的接缝和硬边越少越好。
在移动设备上和低端电脑上尽量不要在场景中用真光,用光照贴图。这个方法大大节省了CPU和GPU的计算,CPU得到了更少的DRAWCALL,GPU则需要更少顶点处理和像素栅格化。
Lightmapping : http://docs.unity3d.com/Documentation/Manual/Lightmapping.html
http://docs.unity3d.com/Documentation/Components/class-Texture2D.html
图片压缩将降低你的图片大小(更快地加载更小的内存跨度(footprint)),而且大大提高渲染表现。压缩贴图比起未压缩的32位RGBA贴图占用内存带宽少得多。
之前U3D会议还听说过一个优化,贴图尽量都用一个大小的格式(512 * 512 , 1024 * 1024),这样在内存之中能得到更好的排序,而不会有内存之间空隙。这个是否真假没得到过测试。
http://docs.unity3d.com/Documentation/Components/class-Texture2D.html
跟网页上的略缩图原理一样,在3D游戏中我们为游戏的贴图生成多重纹理贴图,远处显示较小的物体用小的贴图,显示比较大的物体用精细的贴图。这样能更加有效的减少传输给GPU中的数据。
8.LOD 、 Per-Layer Cull Distances 、 Occlusion Culling
摄像机分层距离剔除(Per-Layer Cull Distances):为小物体标识层次,然后根据其距离主摄像机的距离判断是否需要显示。
Level Of Detail :
http://docs.unity3d.com/Documentation/Manual/LevelOfDetail.html
Occlusion Culling :
http://docs.unity3d.com/Documentation/Manual/OcclusionCulling.html
实时阴影技术非常棒,但消耗大量计算。为GPU和CPU都带来了昂贵的负担,细节的话参考下面:
http://docs.unity3d.com/Documentation/Manual/Shadows.html
a.需要注意的是有些(built-in)Shader是有mobile版本的,这些大大提高了顶点处理的性能。当然也会有一些限制。
写Shader优化的小提示:
http://docs.unity3d.com/Documentation/Components/SL-ShaderPerformance.html
a.对Draw Call Batching的优化
http://docs.unity3d.com/Documentation/Manual/DrawCallBatching.html
c.角色模型的优化建议
用单个蒙皮渲染、尽量少用材质、少用骨骼节点、移动设备上角色多边形保持在300~1500内(当然还要看具体的需求)、PC平台上1500~4000内(当然还要看具体的需求)。
http://docs.unity3d.com/Documentation/Manual/ModelingOptimizedCharacters.html
U3D的渲染是有顺序的,U3D的渲染顺序是由我们控制的,控制好U3D的渲染顺序,你才能控制好DrawCall
1.渲染A,使用材质1
2.渲染B,使用材质1
3.渲染C,使用材质2
在这种情况下是2个DrawCall,在下面这种情况下,则是3个DrawCall
1.渲染A,使用材质1
2.渲染C,使用材质2
3.渲染B,使用材质1
因为我们没有控制好渲染顺序(或者说没有去特意控制),所以导致了额外的DrawCall,因为A和B不是一次性渲染完的,而是被C打断了,所以导致材质1被分为两次渲染
那么是什么在控制这个渲染顺序呢?首先在多个相机的情况下,U3D会根据相机的深度顺序进行渲染,在每个相机中,它会根据你距离相机的距离,由远到近进行渲染,在UI相机中,还会根据你UI对象的深度进行渲染
1. 更新不透明贴图的压缩格式为ETC 4bit,因为android市场的手机中的GPU有多种,
每家的GPU支持不同的压缩格式,但他们都兼容ETC格式,
2. 对于透明贴图,我们只能选择RGBA 16bit 或者RGBA 32bit。
4. 当我们设置了FPS后,再调整下Fixed timestep这个参数,
这个参数在ProjectSetting->Time中,目的是减少物理计算的次数,来提高游戏性能。
5. 尽量少使用Update LateUpdate FixedUpdate,这样也可以提升性能和节省电量。
多使用事件(不是SendMessage,使用自己写的,或者C#中的事件委托)。
在右侧面板中可以找到VSync Count,把它选成Don't Sync。
<ignore_js_op>
这就关闭了VSync(垂直同步),现在在运行场景看看,帧速率是不是提高很多。
现在来说说什么是垂直同步,要知道什么是垂直同步,必须要先明白显示器的工作原理,
显示器上的所有图像都是一线一线的扫描上去的,无论是隔行扫描还是逐行扫描,
显示器都有两种同步参数——水平同步和垂直同步。
需要注意的是:需要合并的纹理应该是物体在场景中距离相近的,如果物体在场景中的距离较远,
则不建议合并纹理,因为这样做很有可能非但起不到优化的作用,反而降低了运行效率。
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 |
|
后
<ignore_js_op>
========================================分割线====================================
这是因为角色的动作大多数都是事先设定好的,并不需要经过IK操作来进行实时计算(Rogdoll除外),所以在模型导入时,不要将IK结点一起导入。
在静态实体上附加Animation部件虽然对结果没有影响,但却会增加一定的CPU开销来调用这一组件,所以尽量去掉该组件。
建议生成Mipmap。虽然这种做法会增加一些应用程序的大小,但在游戏运行时,系统会根据需求应用Mipmap来渲染,从而减少内存带宽。
如果可以的话,尽量不用MeshCollider,以节省不必要的开销。如果不能避免的话,尽量用减少Mesh的面片数,或用较少面片的代理体来代替。
尽可能地使用prefab的实例化物体,以降低内存带宽的负担。检查实体的PrefabType,尽量将其变成PrefabInstance,而不是ModelPrefabInstance。
========================================分割线====================================
因此做手机游戏的开发,优化的方向,与力度对比PC游戏都有所区别。
目前在手机上面,还不能够像PC游戏那样追求高质量渲染效果,为了让手机不那么容易发烫,还要控制cpu,gpu,不能让他们全速运算。
UV坐标控制在0到1之间,人物模型面数控制在1500内,骨骼控制在30个以内。
尽量减少alphaTest和alphaBlend材质的使用。在手机上,这是很杀效率的。
如果要做插值,考虑使用四元数(表示旋转)和向量(表示位移)来做插值。
========================================分割线====================================
光照
像素光。
像素光可以让你的游戏看起来效果很牛逼,但是不要使用过多的像素光。
在你的游戏中可以使用质量管理器来调节像素光的数量来取得一个性能和质量的均衡点.
性能占用顺序:聚光灯>点光源>平行光。
一个好的点亮场景的方法就是先得到你想要的效果,然后看看哪些光更重要;
在保持光效的前提下看看哪些光可以去掉。
Shaders
多重效果的shader就比看起来样式很单一的shader要更耗费资源。
同样在一个拥有贴图和光反射的物体上,使用VertexLit Diffuse shader无疑是最省资源的。
========================================分割线====================================
在美术制作场景的过程中,会使用到大量的粒子系统。
比如场景中的火把。在我们的一个地下城场景中,美术们放置了大量的火把。整个场景中的各个地方,有100来个火把。
unity中,在摄像机范围外的粒子系统虽然不会被绘制。
但是update是一直持续的。这也就意味着,这100多个火把,不论是否可见都在更新。
这个设计应该是很不合理的,在我看过的其他引擎中,都会有一个开关,来控制不可见的粒子系统是否需要update。
有的粒子系统在不可见的时候需要更新,比如爆炸。有的不需要更新,比如火堆火把。
为了避免不必要的update开销,尤其是最后游戏是要发布到页游平台(web player只能使用一个cpu的核)。
于是写了一个脚本,控制不可见的粒子系统就不更新。
该脚本主要是用到了2个MonoBehaviour的函数。
OnBecameInvisible() 当变为不可见 和 OnBecameVisible() 当变成可见。
在Start() 的时候,把最GameObject的scale设置为很小,以保证该cube不被看见。
其实遍历所有的child,把active设置为false。
在OnBecameVisible 中 遍历所有child,把active设置为true。
在OnBecameInvisible中 遍历所有child,把active设置为false。
========================================分割线====================================
对于复杂的静态场景,还可以考虑自行设计遮挡剔除算法,减少可见的物体数量同时也可以减少Draw Call。
总之,理解Draw Call和Draw Call Batching原理,根据场景特点设计相应的方案来尽量减少Draw Call次数才是王道,其它方面亦然。
6、 Using different material instances will cause batching to fail.
使用不同材质的实例化物体(instance)将会导致批处理失败。
Static batching is only available in Unity iOS Advanced.
静态批处理目前只支持Unity iOS Advanced。
备注:最近一直在研究Unity3D的性能优化问题,这段时间可能会多翻译这方面的文章。
首先是一些优化常识。针对图形方面的优化主要包括三角形数量,纹理所占内存,以及Shader,前两项基本没什么好讲的,针对设备机能的限制制定相应的指标即可,所以Shader就成为了图形性能优化的关键。
带动态效果的天空盒(Shader Scroll 2 Layers Multiplicative)
通过两张贴图的混合和移动产生云的动态效果。
1、.NET数据绑定只支持数据绑定,使用属性可以获得数据绑定的好处;
2、在属性的get和set访问器重可使用lock添加多线程的支持。
二、readonly(运行时常量)和const(编译时常量)
1、const只可用于基元类型、枚举、字符串,而readonly则可以是任何的类型;
3、const比readonly效率高,但失去了应用的灵活性。
三、is与as
1、两者都是在运行时进行类型的转换,as操作符只能使用在引用类型,而is可以使用值和引用类型;
2、通常的做法是用is判断类型,然后选择使用as或强类型转换操作符(用operater定义的转换)有选择地进行。
四、ConditionalAttribute代替#if #endif条件编译
1、ConditionalAttribute只用于方法级,对其他的如类型、属性等的添加都是无效的;而#if #endif则不受此限制;
2、ConditionalAttribute可以添加多个编译条件的或(OR)操作,而#if #endif则可以添加与(AND)[这里可以完全定义为另一个单独的符号];
3、ConditioanlAttribute定义可以放在一个单独的方法中,使得程序更为灵活。
五、提供ToString()方法
2、使用IFormatter.ToString()方法提供更灵活的定制,如果添加IFormatProvider 和ICustomFormatter接口则更有意义的定制消息输出。
六、值和引用类型的区别
1、值类型不支持多态,适合存储应用程序操作的数据,而引用则支持多态,适用于定义应用程序的行为;
3、值类型具有较少的堆内存碎片、内存垃圾和间接访问时间,其在方法中的返回是以复制的方式进行,避免暴露内部结构到外界;
4、值类型应用在如下的场景中:类型的职责主要是用于数据存储;公共接口完全由一些数据成员存取属性定义;永远没有子类;永远没有多态行为。
七、值类型尽可能实现为常量性和原子性的类型
2、初始化常量的三种策略:在构造中;工厂方法;构造一个可变的辅助类(如StringBuilder)。
八、确保0为值得有效状态
2、枚举类型的0不应为无效的状态;在FlagsAttribute是应确保0值为有效地状态;
3、在字符串为为空时可以返回一个string.Empty的空字符串;
九、相等判断的多种表示关系
1、ReferenceEquals()判断引用相等,需要两个是引用同一个对象时方可返回true;
2、静态的Equals()方法先进性引用判断再进行值类型判断的;
3、对于引用类型的判断可以在使用值语义时使用重写Equals()方法;
4、重写Equals()方法时也应当重写GetHashCode()方法,同时提供operater==()操作。
十、理解GetHashCode()方法的缺陷
1、GetHashCode()仅应用在基于散列的集合定义键的散列值,如HashTable或Dictionary;
2、GetHashCode()应当遵循相应的三条规则:两个相等对象应当返回相同的散列码;应当是一个实例不变式;散列函数应该在所有的整数中产生一个随机的分布;
十一、优先使用foreach循环语句
1、foreach可以消除编译器对for循环对数组边界的检查;
2、foreach的循环变量是只读的,且存在一个显式的转换,在集合对象的对象类型不正确时抛出异常;
3、foreach使用的集合需要有:具备公有的GetEnumberator()方法;显式实现了IEnumberable接口;实现了IEnumerator接口;
4、foreach可以带来资源管理的好处,因为如果编译器可以确定IDisposable接口时可以使用优化的try…finally块;
十二、默认字段的初始化优于赋值语句
1、字段生命默认会将值类型初始化为0,引用类型初始化为null;
十三、使用静态构造器初始化静态成员
1、静态构造器会在一个类的任何方法、变量或者属性访问之前执行;
2、静态字段同样会在静态构造器之前运行,同时静态构造器有利于异常处理。
十四、利用构造器链(在.NET 4.0已经用可选参数解决了这个问题)
1、用this将初始化工作交给另一个构造器,用base调用基类的构造器;
2、类型实例的操作顺序是:将所有的静态字段都设置为0;执行静态字段初始化器;执行基类的静态构造器;执行当前类型的静态构造器;
将所有的实例字段设置为0;执行实例字段初始化器;执行合适的基类实例构造器;执行当前类型的实例构造器。
十五、利用using和try/finally语句来清理资源
在IDisposable接口的Dispose()方法中用GC.SuppressFinalize()可通知垃圾收集器不再执行终结操作。
十六、尽量减少内存垃圾
2、减少分配对象数量的技巧:经常使用的局部变量提升为字段;提供一个类,用于存储Singleton对象来表达特定类型的常用实例。
十七、尽量减少装箱和拆箱
1、关注一个类型到System.Object的隐式转换,同时值类型不应该被替换为System.Object类型;
2、使用接口而不是使用类型可以避免装箱,即将值类型从接口实现,然后通过接口调用成员。
十八、实现标准Dispose模式
3、为需要多态的类型添加一个受保护的虚方法Dispose(),派生类通过重写这个方法来释放自己的任务;
4、在需要IDisoposable接口的类型中,即使我们不需要一个终结器也应该实现一个终结器。
十九、定义并实现接口优于继承类型
1、不相关的类型可以共同实现一个共同的接口,而且实现接口比继承更容易;
2、接口比较稳定,他将一组功能封装在一个接口中,作为其他类型的实现合同,而基类则可以随着时间的推移进行扩展。
二十、明辨接口实现和虚方法重写
1、在基类中实现一个接口时,派生类需要使用new来隐藏对基类方法的使用;
二十一、使用委托表达回调
1、委托对象本身不提供任何异常捕获,所以任何的多播委托调用都会结束整个调用链;
2、通过显示调用委托链上的每个委托目标可以避免多播委托仅返回最后一个委托的输出。
二十二、使用事件定义外部接口
1、应当声明为共有的事件,让编译器为我们创建add和renmove方法;
2、使用System.ComponentModel.EventHandlerList容器来存储各个事件处理器,在类型中包含大量事件时可以使用他来隐藏所有事件的复杂性。
二十三、避免返回内部类对象的引用
1、由于值类型对象的访问会创建一个该对象的副本,所以定义一个值类型的的属性完全不会改变类型对象内部的状态;
3、定义接口将访问限制在一个子集中从而最小化对对象内部状态的破坏;
5、希望客户代码更改内部数据元素时可以实现Observer模式,以使对象可以对更改进行校验或相应。
二十四、声明式编程优于命令式编程
可以避免在多个类似的手工编写的算法中犯错误的可能性,并提供清晰和可读的代码。
二十五、尽可能将类型实现为可序列化的类型
1、类型表示的不是UI控件、窗口或者表单,都应使类型支持序列化;
2、在添加了NonSerializedAttribute的反序列化的属性时可以通过实现IDeserializationCallback的OnDeserialization()方法装入默认值;
3、在版本控制中可以使用ISerializable接口来进行灵活的控制,同时提供一个序列化的构造器来根据流中的数据初始化对象,在实现时还要求SerializationFormatter异常的许可。
二十六、使用IComparable和IComparer接口实现排序关系
1、IComparable接口用于为类型实现最自然的排序关系,重载四个比较操作符,可以提供一个重载版的CompareTo()方法,让其接受具体类型作为参数;
2、IComparer用于提供有别于IComparable的排序关系,或者为我们提供类型本身说没有实现的排序关系。
二十七、避免ICloneable接口
1、对于值类型永远不需要支持ICloneable接口使用默认的赋值操作即可;
2、对于可能需要支持ICloneable接口的基类,应该为其创造一个受保护的复制构造器,并应当避免支持IConeable接口。
二十八、避免强制转换操作符
通过使用构造器来代替转换操作符可以使转换工作变得更清晰,由于在转换后使用的临时对象,容易导致一些诡异的BUG。
二十九、只有当新版积累导致问题是才考虑使用new修饰符
三十、尽可能实现CLS兼容的程序集
1、创建一个兼容的程序集需要遵循两条规则:程序集中所有公有和受保护成员所使用的参数和返回值类型都必须与CLS兼容;任何与CLS不兼容的公有和受保护成员都必须有一个与CLS兼容的替代品;
2、可以通过显式实现接口来避开CLS兼容类型检查,及CLSCompliantAttribute不会检查私有的成员的CLS兼容性。
三十一、尽可能实现短小简洁的方法
1、JIT编译器以方法为单位进行编译,没有被调用的方法不会被JIT编译;
2、如果将较长的Switch中的Case语句的代码替换成一个一个的方法,则JIT编译器所节省的时间将成倍增加;
3、短小精悍的方法并选择较少的局部变量可以获得优化的寄存器使用;
4、方法内的控制分支越少,JIT编译器越容易将变量放入寄存器。
三十二、尽可能实现小尺寸、高内聚的程序集
1、将所有的公有类以及共用的基类放到一些程序集中,把为公有类提供功能的工具类也放入同样的程序集中,把相关的公有接口打包到他们自己的程序集中,最后处理遍布应用程序中水平位置的类;
2、原则上创建两种组件:一种为小而聚合、具有某项特定功能的程序集,另一种为大而宽、包含共用功能的程序集。
三十三、限制类型的可见性
1、使用接口来暴露类型的功能,可以使我们更方便地创建内部类,同时又不会限制他们在程序集外的可用性;
2、向外暴露的公有类型越少,未来扩展和更改实现所拥有的选择就越多。
三十四、创建大粒度的Web API
这是在机器之间的交易的频率和载荷都降到最低,将大的操作和细粒度的执行放到服务器执行。
三十五、重写优于事件处理器
1、一个事件处理器抛出异常,则事件链上的其他处理器将不会被调用,而重写的虚方法则不会出现这种情况;
2、重写要比关联事件处理器高效得多,事件处理器需要迭代整个请求列表,这样占用了更多的CPU时间;
3、事件能在运行时响应,具有更多的灵活性,可以对同一个事件关联多个响应;
三十六、合理使用.NET运行时诊断
1、System.Diagnostics.Debug\Trace\EventLog为运行时提供了程序添加诊断信息所需要的所有工具,EventLog提供入口时的应用程序能写到系统事件日志中;
2、最后不要写自己的诊断库,.NET FCL 已经拥有了我们需要的核心库。
三十七、使用标准配置机制
1、.NET框架的System.Windows.Application类为我们定义了建立通用配置路径的属性;
2、Application.LocalAppDataPath和Application.userDataPath 会生成本地数据目录和用户数据的路径名;
3、不要在ProgramFiles和Windows系统目录中写入数据,这些位置需要更高的安全权限,不要指望用户拥有写入的权限。
三十八、定制和支持数据绑定
1、BindingMananger和CurrencyManager这两个对象实现了控件和数据源之间的数据传输;
2、数据绑定的优势:使用数据绑定要比编写自己的代码简单得多;应该将它用于文本数据项之外的范围-其他显示属性也可以被绑定;对于Windowos Forms 数据绑定能够处理多个控件同步的检查相关数据源;
3、在对象不支持所需的属性时可以通过屏蔽当前的对象然后添加一个想要的对象来支持数据绑定。
三十九、使用.NET验证
1、ASP.NET中有五种控件来验证有效性,可以用CustomValidator派生一个新类来增加自己的认证器;
2、Windows验证需要子System.Windows.Forms.Control.Validating些一个事件处理器。
四十、根据需要选用恰当的集合
1、数组有两个比较明显的缺陷:不能动态的调整大小;调整大小非常耗时;
2、ArrayList混合了一维数组和链表的特征,Queue和Stack是建立在Array基础上的特殊数组;
3、当程序更加灵活的添加和删除项时,可以使更加健壮的集合类型,当创建一个模拟集合的类时,应当为其实现索引器和IEnumberable接口。
四十一、DataSet优于自定义结构
1、DataSet有两个缺点个:使用XML序列化机制的DataSet与非.NET 代码之间的交互不是很好;DataSet是一个非常通用的容器;
2、强类型的DataSet打破了更多的设计规则,其获得的开发效率要远远高于自己编写的看上去更为优雅的设计。
四十二、利用特性简化反射
通过设计和实现特性类,强制开发人员用他们来声明可被动态使用的类型、方法和属性,可以减少应用程序的运行时错误,提高软件的用户满意度。
四十三、避免过度使用反射
1、Invoke成员使用的参数和返回值都是System.Object,在运行时进行类型的转换,但出现问题的可能性也变得更多了;
2、接口使我们可以得到一个更为清晰、也更具可维护性的系统,反射式一个很强大的晚期绑定机制.NET框架使用它来实现Windows控件和Web控件的数据绑定。
四十四、为应用程序创建特定的异常类
1、需要不同的异常类的唯一原因是让用户在编写catch处理器时能够方便地对不同的错误采取不同的做法;
四十五、优先选择异常安全保证
1、强异常保证在从异常中恢复和简化异常处理之间提供了最好的平衡,在操作因为异常而中断,程序的状态保留不变;
2、对将要修改的数据做防御性的复制,对这些数据的防御性复制进行修改,这中间的操作可能会引发异常,将临时的副本和原对象进行交换;
3、终结器、Dispose()方法和委托对象所绑定的目标方法在任何情况下都应当确保他们不会抛出异常。
四十六、最小化互操作
1、互操作有三个方面的代价:数据在托管堆和非托管堆之间的列举成本,托管代码和非托管代码之间切换的成本,对开发人员来说与混合环境打交道的开发工作;
2、在interop中使用blittable类型可以有效地在托管和非托管环境中来回复制,而不受对象内部结构的影响;
3、使用In/Out特性来确保最贴切的不必要的多次复制,通过声明数据如何被列举来提高性能;
4、使用COM Interop用最简单的方式实现和COM组件的互操作,使用P/Invoke调用Win32 API,或者使用C++编译器的/CLR开关来混合托管和非托管的代码;
四十七、优先选择安全代码
1、尽可能的避免访问非托管内存,隔离存储不能防止来自托管代码和受信用户的访问;
2、程序集在Web上运行时可以考虑使用隔离存储,当某些算法确实需要更高的安全许可时,应该将那些代码隔离在一个单独的程序集中。
四十八、掌握相关工具与资源
1、使用NUnit建立自动单元测试(集成在VS2010 中了);
2、FXCop工具会获取程序集中的IL代码,并将其与异族编码规则和最佳实践对照分析,最后报告违例情况;
3、ILDasm是一个IL反汇编工具,可以帮助我们洞察细节;
4、Shared Source CLI是一个包含.NET框架内核和C#编译器的实现源码。
Unity 性能优化归纳相关推荐
- Unity性能优化分析思路
1)Unity性能优化分析思路 2)Unity2020后Paticle子节点旋转并把ScalingMode设置为Hierarchy后,对根节点进行缩放时表现不正常 3)FBX默认会冗余lit.mat ...
- Unity性能优化 – 脚本篇
最近开始进行Unity性能优化的工作,主要分为三类:CPU.GPU和内存.由于我们游戏的核心战斗是计算密集型,所以主要是受限于CPU.CPU的优化又分为渲染和脚本,本文将着重于脚本优化. 一般来说,优 ...
- Unity性能优化(2)-官方教程Diagnosing performance problems using the Profiler window翻译
http://www.cnblogs.com/alan777/p/6135703.html Unity性能优化(2)-官方教程Diagnosing performance problems using ...
- 【Unity性能优化】静态资源优化——Audio优化
文章目录 写在前面 1. 前言 2. 使用Asset Checker进行资源检测 3. Audio优化 3.1 启用Force to Mono 3.2 压缩格式与采样率 3.3 音乐加载类型 3.4 ...
- Unity性能优化 :合批篇
前言 本系列为一些性能优化的小知识,是日常游戏开发中与性能表现的一些点,本篇为该系列文章的第二篇,前篇链接: 第一篇: Unity性能优化:资源篇 在早期Unity中,对于合批的处理手段主要是下面三种 ...
- Unity 性能优化:资源篇
Unity性能优化 大的方面来说,通过Unity对于项目的性能优化大概可以分为下面几个部分: 资源 渲染 程序 项目配置 而在这个部分中,资源的性能优化属于最基础.最有效的优化手段,也是游戏开发者日常 ...
- Unity 性能优化(力荐)
开始之前先分享几款性能优化的插件: 1.SimpleLOD : 除了同样拥有Mesh Baker所具有的Mesh合并.Atlas烘焙等功能,它还能提供Mesh的简化,并对动态蒙皮网格进行了很好的支持. ...
- Unity性能优化之编辑器检查——贴图
优化选项 图片资源一般可做如下优化设置 打包图集 mipmap不必要时选择关闭 Read/Write Enabled不必要时关闭 纹理压缩 图集打包的可以参考Unity性能优化之图集打包:mipmap ...
- Unity性能优化---音频
Unity性能优化-音频 摘自–传送门 向unity导入音频时,会默认将音频文件压缩为"Decompress On Load"&"Vorbis",如下图 ...
- Unity - 性能优化 - 包体,内存 - 偏静态资源的优化
文章目录 静态资源优化 - AssetPostprocessor Texture 压缩 Model 网格.动画 压缩 音频压缩 纹理的优化经验 尺寸 通道 发布出来的包资源再次分析 如何工具快速定位静 ...
最新文章
- LeetCode简单题之检查两个字符串数组是否相等
- java lamdba表达式效率_java8新特性Lambda表达式为什么运行效率低
- backup ram不稳定 stm32_STM32学习笔记
- zoj 3812 状压dp
- WPF控件textBox多行输入设置
- leetcode贪心算法题集锦(持续更新中)
- 图灵原版计算机科学系列,图灵原版计算科学系列
- Android VNC Server New
- 01-Flutter移动电商实战-项目学习记录
- python 生成器装饰器_4.python迭代器生成器装饰器
- 公交站台被圈进养鸭场
- android 开发怎么让程序生成的图片文件不会被系统扫描到
- python等值面追踪_等值线的追踪算法(2)
- 浅说物联网之一:物联网圈子的三个玩家
- 深入理解 MySQL 主键和唯一(unique)索引
- 二进制与十进制转换器
- 计算机课excel,计算机excel教学课件.doc
- 微信小程序for循环
- 什么是持续集成的自动化测试
- LeetCode(49)Anagram
热门文章
- 近世代数概论------有理数与域
- 莱斯利Leslie种群模型 python sympy
- java坦克大战 素材_坦克大战 游戏源码 素材 文档(了解面向对象的具体编程)
- java读取excel图表模板,修改选值范围
- 国密 GmSSL 版本及安装
- 如何在HTML中输入英语音标符号,电脑上如何输入国际音标?
- 【java】java 安全 jaas 文件 何时 解析 以及 怎么解析的
- MySQL - 常见SQL笔试题整理(长期更新)
- java简历项目经验大全(java商城项目经验简历)
- WIN10系统 Indirect Display 虚拟显示器之特殊应用