foreach为什么在unity不建议用

首先看片文章

https://www.zhihu.com/question/30334270

里面有张图

这里解释了在每个foreach循环之后会有一个boxing的过程,什么是boxing?(详细看这里:http://www.cnblogs.com/xiaoshi/archive/2008/05/28/1208902.html

简单来说就是把值类型转换成引用类型。

这里的第二行就是boxing过程

第三行就是unboxing过程

也就是说每次使用foreach会在结束的时候在堆上申请一段引用内存(40Bytes,对list的引用)

而引用内存多了后会在GCCollect时候回收。

回收的过程会卡。

所以unity不要用foreach的原因是,会产生垃圾内存,导致卡顿

时间: 2024-10-20 13:39:00

foreach为什么在unity不建议用的相关文章

《Unity Shader 与 计算机图形学》第二章

提示:本篇将会非常长~ 本系列文章分为 硬件 编程入门 工程实践 上一篇 主要介绍了GPU的特征工作原理 以及渲染的底层流程 其实对于新架构而言还有所不同 Shader描述了如何渲染物体的信息,包括: Texture Setup.纹理设置 Material Property.材质设置 Render State.渲染状态 Blend Setup.混合设置 Pixel Shader.像素着色 Vertex Shader.定点着色 Render Target Setup 渲染目标设置 Shader并不

学习Unity

IOC:英文全称:Inversion of Control,中文名称:控制反转,它还有个名字叫依赖注入(Dependency Injection).作用:将各层的对象以松耦合的方式组织在一起,解耦,各层对象的调用完全面向接口.当系统重构的时候,代码的改写量将大大减少.理解依赖注入:    当一个类的实例需要另一个类的实例协助时,在传统的程序设计过程中,通常有调用者来创建被调用者的实例.然而采用依赖注入的方式,创建被调用者的工作不再由调用者来完成,因此叫控制反转,创建被调用者的实例的工作由IOC容

Shader编程学习笔记(三)——三大主流编程语言 HLSL/GLSL/Cg

三大主流编程语言 HLSL/GLSL/Cg Shader Language Shader Language的发展方向是设计出在便携性方面可以和C++.Java等相比的高级语言,“赋予程序员灵活而方便的编程方式”,并“尽可能的控制渲染过程”同时“利用图形硬件的并行性,提高算法效率”. Shader Language目前主要有3种语言:基于OpenGL的OpenGL Shading Language,简称GLSL;基于DirectX的High Level Shading Language,简称HLS

Unity3d Android SDK接入解析(二)Unity3d Android SDK的设计与两种接入方式

一.前言 上篇说清楚了Unity和Android调用的方式,但很多实际接入的部分没有讲的很详细,因为重头在这篇,会详细讲述具体接入Android SDK的方式,和怎么去做一个方便Unity接入的SDK. 传送门: 前篇:Unity3d 与 Android之间的互相调用 http://blog.csdn.net/yang8456211/article/details/51331358 后篇:Unity3d Android SDK接入解析(三)接入Android Library的理解 http://

Scala--第四天

一.迭代器 iterator 适合Scala中所有集合的遍历 1 var a = List(1, 2, 3, 4) 2 var b = a.iterator 3 //hasNext:判断迭代器是否由下一个元素 next:获取下一个元素 4 while (b.hasNext) { 5 println(b.next) 6 } 7 //结果 8 //1 9 //2 10 //3 11 //4 二.函数式编程 用处:Scala 针对集合的操作,简化代码 1.遍历 froeach 1 //完成写法 for

Unity Mono foreach BUG性能测试

# 环境 - Unity 4.6.4 / Windows # 测试代码 # 结果数据 # 结论 foreach存在bug,会导致GC,并且效率低下: 使用GetEnumerator代替,没有GC,并且速度快10倍! 建议迭代操作中,List使用for,Dictionary使用GetEnumerator 来自为知笔记(Wiz)

使用Unity的50个建议

关于这些建议 这些建议并不适用于所有的项目 这些建议是基于我与3-20人的小团队项目经验总结出来的 结构.可重复使用性.明晰度都是有价的——团队规模和项目规模决定了是否值得付这个价. 一些建议也许公然违抗了传统的Unity开发.例如:使用专业化的组合而不是使用实例就很不像Unity的作风,价格也很高.即使看上去挺疯狂的,但我还是看到了这些建议给开发者带来了利益. 过程方面 1.避免分支资产 对于任何资产我们应该只有一个版本.如果你非要把一个预设,场景,或网格分支开来,那么情遵循一个过程,这个过程

编写高质量代码改善C#程序的157个建议——建议17:多数情况下使用foreach进行循环遍历

建议17:多数情况下使用foreach进行循环遍历 由于本建议涉及集合的遍历,所以在开始讲解本建议之前,我们不妨来设想一下如何对结合进行遍历.假设存在一个数组,其遍历模式可以采用依据索引来进行遍历的方法:又假设存在一个HashTable,其遍历模式可能是按照键值来进行遍历.无论是哪个集合,如果他们的遍历没有一个公共的接口,那么客户端在进行遍历时,相当于是对具体类型进行了编码.这样一来,当需求发生变化时,必须修改我们的代码.而且,由于客户端代码过多地关注了集合内部的实现,代码的可移植性就会变得很差

Unity 几种优化建议

转: http://user.qzone.qq.com/289422269/blog/1453815561?ptlang=2052 最简单的优化建议: 1.PC平台的话保持场景中显示的顶点数少于200K~3M,移动设备的话少于10W,一切取决于你的目标GPU与CPU.2.如果你用U3D自带的SHADER,在表现不差的情况下选择Mobile或Unlit目录下的.它们更高效.3.尽可能共用材质.4.将不需要移动的物体设为Static,让引擎可以进行其批处理.5.尽可能不用灯光.6.动态灯光更加不要了