Tamsiree

前言最近开始进行Unity性能优化的工作，主要分为三类：CPU、GPU和内存。CPU的优化又分为渲染和脚本，本文将着重于脚本优化。 正文Unity性能优化 – 脚本篇一般来说，优化必须要知道性能热点在哪里，而知道性能热点则需要在目标设备去进行深度的profile。如果不进行profile，而是靠臆测去进行优化，往往会事倍功半，甚至适得其反。 本文所讲述的是已经经过验证的，通用的优化方法和思路，可以为大家节约一些profile时间。以下将从Unity API、C#、Lua、数据结构和算法等方面来详细阐述优化建议。 Unity APIGameObject.GetComponentUnity是基于组合的开发方式，所以GetComponent是一个高频使用的函数。每次调用GetComponent时，Unity都要去遍历所有的组件来找到目标组件。每次都去查找是不必要的耗费，我们可以通过缓存的方式来避免这些不必要的开销。 其中Transform是我们用到最多的组件，GameObject内部提供了一个.transform来获取此组件。然而经过测试（2017.2.1p1）我们发现缓存的效率依然是最高的 ...

前言这里是前言介绍。 正文什么是 .gitattributes ？当执行 git 动作时，.gitattributes 文件允许你指定由 git 使用的文件和路径的属性，例如：git commit 等。 换句话说，每当有文件保存或者创建时，git 会根据指定的属性来自动地保存。 其中的一个属性是 eol(end of line)，用于配置文件的结尾。本文将会深入了解如何配置文件的结尾行，这样的话，即使在不同的机器、操作系统 上都可以使得每个开发者都可以使用相同的值。 为什么是 .gitattributes（开发者之间的争议 ⚔️ ）?不是所有的开发者都是一样的，不能因为你是在 Windows 上使用 Visual Studio Code 开发的，就期望别的 Pull Request 也是基于相同的开发 环境完成的（在 MacOS 上可能用的是 Sublime Text2）。 正如上面提到的，开发者使用不同的操作系统，默认的文件结尾行就会不同。在 Windows 上默认的是回车换行（Carriage Return Line Feed, CRLF），然而，在 Linux/MacOS 上则是 ...

前言这里是前言介绍。 正文本文会实现以下几个需求 搭建自己的PackageManager服务器 安装nodejs 安装npm 部署verdaccio 将自己写的插件发布到PackageManager服务器上 配置自己的Package 注册 Verdaccio 服务器账号 登陆 Verdaccio 服务器 发布 Package 到 Verdaccio 服务器上 让项目可以使用Verdaccio服务器上的所有Package 修改项目的manifest.json 修改Unity编辑器的项目模板，让每个新建的Unity项目都可安装自己服务器上的插件 修改Unity编辑器项目模板的mainfest.json 使用peazip重新压缩为.tgz文件 本文需要用到的工具 Unity Editor 云服务器 Windows PowerShell PeaZip 参考文章：https://medium.com/@markushofer/run-your-own-unity-package-s ...

前言这里是前言介绍。 正文Profiler概述打开Unity Profiler Window->Analysis->Profiler。 Profiler可以确定需要在应用程序中优化什么，并确认优化产生了您期望的结果。默认情况下，Unity记录300帧游戏数据并呈现每一帧的详细信息。 Profiler Window Layout A：Profiler模块。这是可以在应用程序中配置的所有模块的列表。使用该区域顶部的下拉菜单从窗口中添加和删除模块。 B：Profiler控件。使用这些控件来设置从哪个设备进行配置，以及应该执行哪种类型的配置Unity，在帧之间导航，并开始记录数据。 C: 帧图表。这个区域包含了每个模块的图表。 D：细节面板模块。窗口这个区域的信息会根据您选择的模块而变化。 Profiler Controls 各个控件功能： AttachToPlay： 选择要对应用程序进行概要分析的目标。 默认情况下，这个设置为Playmode。还可以选择编辑器来配置Unity编辑器，并显示编辑器当前使用的资源。 Unity还可以自动检测任何运行在网络上或通过 ...

前言这里是前言介绍。 正文Unity Accelerate Solution 团队对 Unity 引擎的源代码了如指掌，可帮助客户们最大限度地利用引擎。团队的日常工作包括深入剖析客户项目，搜寻其在速度、稳定性与效率方面有待优化的部分。本次，我们请到了这支 Unity 最为资深的软件工程师团队来分享一些移动游戏优化方面的专业知识。 他们分享了非常多的锦囊妙计，以至于一篇博文很难涵盖所有内容。因此，我们将推出一个博文系列。作为此系列的首篇文章，我们将着重介绍怎样借助性能分析、内存优化和代码架构来提高游戏的性能。在未来的几周内，我们将再发表两篇文章：一篇讨论 UI Physics，另一篇讨论音频和资源、项目配置和图形。 话不多说，直接开讲！ 性能分析优化工作的第一个步骤便是通过性能分析来收集性能数据，这也是移动端优化的第一步。 我们要尽早在目标设备上进行性能分析，而且要经常分析。 **Unity Profiler **可提供应用关键的性能信息，因此是优化必不可少的一部分。尽早对项目进行性能分析，不要拖到发售前。对每一个故障或性能尖峰彻查到底。对你自己的项目性能有一个清晰的认知，可帮助你更轻松 ...

前言这里是前言介绍。 正文没想到Unity的音频会成为内存杀手，在实际的商业项目中，音频的优化必不可少。 Unity支持许多不同的音频格式，但最终它将它们全部转换为首选格式。音频压缩格式有PCM、ADPCM、Vorbis，不是所有平台都支持这些所有的压缩格式，有些平台，例如WebGL只支持AAC格式。 2.所有音频导入时，默认两项设置，LoadType是”Decompress On Load”，压缩格式是“Vorbis”，例如下图原始文件大小计算为35.9 MB，导入的大小计算为10.7 MB。这意味着这个音频剪辑将使您的游戏（存档）大小增加10兆字节，但播放它需要近36兆字节的RAM。 3.Load Type的各个选项 Compressed In Memory – 音频剪辑将存储在RAM中，播放时将解压缩，播放时不需要额外的存储。 Streaming –音频永久存在设备上(硬盘或闪存上) ，播放流媒体方式. 不需要RAM进行存储或播放。 Decompress On Load – 未压缩的音频将存储在RAM中。这个选项需要的内存最多，但是播放它不会像其他选项那样需要太多的C ...

前言这里是前言介绍。 正文转载自 ：Unity3D内存释放 最近网友通过网站搜索Unity3D在手机及其他平台下占用内存太大.这里写下关于unity3d对于内存的管理与优化. Unity3D里有两种动态加载机制：一个是Resources.Load，另外一个通过AssetBundle,其实两者区别不大。Resources.Load就是从一个缺省打进程序包里的AssetBundle里加载资源，而一般AssetBundle文件需要你自己创建，运行时 动态加载，可以指定路径和来源的。 其实场景里所有静态的对象也有这么一个加载过程，只是Unity3D后台替你自动完成了。 详细说一下细节概念：AssetBundle运行时加载:来自文件就用CreateFromFile(注意这种方法只能用于standalone程序）这是最快的加载方法也可以来自Memory,用CreateFromMemory(byte[]),这个byte[]可以来自文件读取的缓冲，www的下载或者其他可能的方式。其实WWW的assetBundle就是内部数据读取完后自动创建了一个assetBundle而已Create完以后，等于把硬盘 ...

前言这里是前言介绍。 正文一口气解决RenderQueue、Ztest、Zwrite、AlphaTest、AlphaBlend和Stencil知道吗，如果只是想要实现Xray效果的话，其实并不难。 实现上图的效果，原理就是对角色画两次。第一次是被遮挡住的效果(半透明、单色)，第二次是正常的效果(为了简化这里使用unlight只显示贴图) 这两个pass最大的区别，在于使用不同的Ztest(深度测试)。但是这一次我决定不仅仅只写关于Ztest的问题。反正我已经决定对抗懒癌晚期，那就干脆一口气把RenderQueue、Ztest、Zwrite、AlphaTest、AlphaBlend、StencilTest这些烂七八糟的东西都拎出来写一遍,因为这些东西有很多地方都是相通的，一起说明白反而省些力气。 不过说实话，这些东西确实是有点麻烦。我尽自己最大的努力去把这些东西说明白。但是鉴于个人能力实在有限，如果有哪里说得不对或者不清楚，还请见谅。 如上图，现在有三个多边形分别是红色盒子绿色盒子和蓝色盒子，在镜头里红色的盒子在最前面（距离摄像机最近），所以盖住了其他两个颜色的盒子。 按照我们的 ...

前言发现Application.temporaryCachePath和Application.persistentDataPath返回空字符串。便花时间认真研究了一下Unity3D的路径问题。 正文我们常用的是以下四个路径： Application.dataPathApplication.streamingAssetsPathApplication.persistentDataPathApplication.temporaryCachePath 根据测试，详细情况如下： iOS:Application.dataPath            /var/containers/Bundle/Application/app sandbox/xxx.app/DataApplication.streamingAssetsPath /var/containers/Bundle/Application/app sandbox/test.app/Data/RawApplication.temporaryCachePath /var/mobile/Containers/Data/Applicati ...

前言单例模式是软件工程学中最富盛名的设计模式之一。从本质上看，单例模式只允许被其自身实例化一次，且向外部提供了一个访问该实例的接口。通常来说，单例对象进行实例化时一般不带参数，因为如果不同的实例化请求传递的参数不同的话会导致问题的产生。(若多个请求都是传递的同样的参数的话，工厂模式更应该被考虑) C#中实现单例有很多种方法，本文将按顺序介绍非线程安全、完全懒汉式、线程安全和低/高性能集中版本。 在所有的实现版本中，都有以下几个共同点： 唯一的、私有的且无参的构造函数，这样不允许外部类进行实例化； 类是密封的，尽管这不是强制的，但是严格来讲从上一点来看密封类能有助于JIT的优化； 一个静态变量应该指向类的唯一实例； 一个公共的静态变量用于获得这个类的唯一实例(如果需要,应该创建它）； 需要注意的是，本文中所有的例子中都是用一个 public static Instance的变量来访问单例类实例，要将其转换成公共函数是很容易的，但是这样并不会带来效率和线程安全上的提升。 正文Version 1 - 非线程安全public sealed class Singleton { ...