win 2008 iis建立网站,wordpress手机端显示,价格优化网站建设,廊坊智能模板建站字符串和文本#xff1a;在Unity项目中#xff0c;处理字符串和文本经常会产生性能问题。在C#中#xff0c;字符串是不变的。任何对字符串的操作都会重新分配新的字符串#xff0c;这个代价是非常昂贵的。如果在多重循环中重复地执行字符串连接操作#xff0c;就会造成性能…字符串和文本在Unity项目中处理字符串和文本经常会产生性能问题。在C#中字符串是不变的。任何对字符串的操作都会重新分配新的字符串这个代价是非常昂贵的。如果在多重循环中重复地执行字符串连接操作就会造成性能问题特别是对长的字符串或者大的数据集操作的时候。因此把N个字符串连接起来就会分配N-1个中间的字符串这样连续的操作就会对堆内存产生压力。当我们需要在多重循环中或者每一帧对字符串进行操作时记得使用StringBuilder来操作字符串。StringBuilder也还能被重用以进一步减少内存的分配。关于字符串的使用详细内容也可以参考微软发布的文档Best Practices for Using Strings in .NETdocs.microsoft.com地域限制和顺序比较与字符串相关代码的一个核心问题就是无意中会使用默认的、慢的字符串API。这些API的目的是为了一些商业化的应用能够处理出现在文本中的有关不同文化和语法规则的字符。比如下面的代码在一些使用美式英语的地区运行时会返回true。在欧洲地区运行时返回false。提示Unity脚本都是基于美式英语来运行的。对于大多数的项目这个完全没有必要。而且我们简单对每个字符进行比较判断两个字符串是否相等这速度大约会比使用上面的方式快10倍。当然我们也可以调用String.Equals方法然后设置比较类型StringComparison.Ordinal来实现低效率的内置字符串API:除了上面讲的顺序比较外也有一些C#的字符串的API效率比较低。比如String.FormatString.StartsWith和String.EndsWith。以下是Unity给出的一些测试数据可见如果是我们自己实现String.StartsWith和String.EndsWith执行效率会高的多。实现方法也可以参考下图正则表达式在字符串匹配和操作字符串方面正则表达式是非常消耗性能的。而且C#类库也实现了正则表达式。所以即使是调用IsMatch这样简单的函数都会临时分配很多的内存。我们在开发中出了初始化会临时分配内存外应该不允许在其他地方临时分配较多内存。如果一定要用正则表达式的话注意不要使用静态的Regex.Match和Regex.Replace方法。这两个方法会动态的编译正则表达式但不会缓存生成的对象。下面是使用正则表达式的一个例子每一次以上的代码被执行它都会生成5kb的内存垃圾。为了减少垃圾的生成我们需要对以上代码进行重构在这个例子中每一次调用myRegExp.Match只会产生320b的内存垃圾。对于简单的字符串匹配而言它对内存的消耗依旧有点多但与之前的例子相比这已经是很大的改进了。因此如果正则表达式是不变的字符串常量那么把它们当作第一个参数传递给Regex的构造器来预编译它们会更加有效。这些Regex对象也是可以被重用的。XML, JSON和其他的长篇文本解析在loading时解析文本通常是一项耗时的操作。有些情况下解析文本所花的时间会超过loading和实例化Assets的时间。这原因取决于我们用的文本解析器。C#内置的XML解析器是非常灵活的但是它不能对一些特殊的数据布局进行优化。许多第三方解析器都是基于反射构建的。虽然在开发中使用反射是一个不错的选择(因为它能很好的适应数据布局的变化)但用反射是非常慢的。Unity已经引入了一个带有内置JSONUtility API(可参考如果在文本解析中遇到性能问题可以考虑以下的解决方案1.在Build时进行解析当我们需要解析文本时最好避免在游戏中进行这一步的操作。我们可以在Build的时候把文本解析成二进制文件。以加快读取时的速度。2.数据分割和延迟加载第二种情况情况是我们需要把能解析成小块的数据分割开来。一旦分割数据解析就可以在不同时间进行。在理想的情况下我们确定哪部分数据是会用到的然后只加载用到的那部分数据。3.线程对于那些不需要用Unity API来操作的数据可以在另外的线程中来解析它们。这可以提高多核CPU的利用率是相当有用的。当然我们在写代码时需要注意避免死锁。
