努力加载中，稍等...
暂无新消息
努力加载中，稍等...
已无更多消息...
这些人最近关注了你
努力加载中，稍等...
已无更多消息
努力加载中，稍等...
已无更多消息
& 在Unity中提升2D移动游戏性能的46个提示和技巧
46 Tips & Tricks for 2D mobile Performance in Unity.
征集热心朋友翻译文章，奖励规则：每100汉字奖励10QB，30天内互动奖励0 - 50QB.
翻译请求：专家推荐
该文章来自用户转载
Unity’s a beast. I’m always impressed at how versatile and performant it can be. But like any beast it requires a little bit of taming (and in some cases some very counter intuitive trickery, but that’s where this metaphor falls apart). I’ve had a bit of a struggle getting Truck Toss to play smoothly on my 3GS, but here’s a nice big list of tips to help you on your way. If this is your first jump into the world of Unity, my first tip (this one’s a freebie) is to stop trying to use it like other languages and environments. You will be using GameObjects, you will be adding multiple script components, and you will have to think differently. When I first started, my approach was to largely ignore prefabs (or use them like Flash’s display list) and get a copy of Box2D running. Painful as it is to deviate, get ready to put in some work!Without further ado, let’s get started:Physics:-Use the built-in physics.It might seem like a waste of cycles to have a fully 3D physics engine running the show for a 2D game, but bear in mind that the Nvidia PhysX engine will be running in Unity’s native core. We’re talking about a hyper-optimised engine maintained by large professional teams, and not a hobbyist 2D engine. Freeze Z position and X/Y rotation for that 2D feel.
-Try to use a 1/1 scale. By this I mean, 1 unit = 1 meter.
You can use larger or smaller scales, but you’re likely to encounter some weirdness when it comes to collisions, and the speed at which objects fall. Remember, a grand piano without air resistance will fall as fast as a dead baby but if everything is large, it will seem slow. You can fiddle with gravity, but again, you’re running the risk of messing with collisions. I like to use a 1/32 scale compared to my sprites with a cam size of 160.-Get your object Mass right. Just like with scale, if you have a grand piano weighing 2gm or a dead baby weighing 500kg things are going to get unpredictable. Try to keep it realistic-ish. -Mesh colliders can be slow compared to primitive box/sphere colliders. While a sphere may have many more verts than say a cube, the uniform distance from the centre would make it massively easier to calculate than lots of individual triangles. -You can simulate more complex shapes by combining primitive colliders. If you have a parent object with say a Box Collider and Rigidbody component, you can add child objects with just a Box Collider. The entire object will collide like one solid multipart object. -Continuing from the above… Rather than having several of these linked together, you can add more child objects with RigidBodies and Colliders, and use Joints to connect them to the parent object. You could build a compound car for example with a parent body to move the entire thing. -Multiple basic joints are not supported on one game object… …but multiple configurable joints are. Rather than having a network of jointed objects you could for example have a spring and a slider from wheel to axle cutting down on a suspension object in between. -Objects with a collider but no RigidBody are considered static. Moving these is expensive, so if you’re creating them with code, add the collider and physics material (to the collider) after positioning.-While it’s considered good practice to keep your solver iterations constant……you might find it beneficial to use the full amount only every 2nd update. I.e.
8,4,8,4,8,4. If this alleviates some of the processor load the solver for example may not have to skip iterations, and will actually provide a more consistent simulation. I said it was going to be counter-intuitive.-While the use of Interpolation and Extrapolation on RigidBodies is discouraged en-masse..…in some cases you might find that turning these on, and reducing the overall solver iterations provides a better simulation. Fiddle. -Lower your timestep! If you’re aiming for an unrealistic 60FPS and the phone is constantly struggling, you’re best just to settle for a lower framerate and give it some breathing room. I like to use a 0.03 fixed timestep with a maximum of about 0.05. Again, it can be slightly counter intuitive decreasing timesteps to get higher framerates, but give it a shot.-Timescale scaling.This could help, depending on the feel your’e going for. It simply simulates more time passing between each iteration. Setting this too high will obviously mess with collisions, especially if an object has traveled say, a mile in one frame, it’s not going to hit a damn thing. Sprites & Textures My engine uses a hybrid system of Sprite Manager2/EZGUI and RageSpline for sprites, but I’ve used 2D Toolkit and much of the following still applies. -Easy on the fill rate! It might seem obvious but if you have a 64×64 image, with only the top left 32×32 filled, that’s still a 64×64 sprite. Trim your transparent images where possible. Lots of libraries will do this automatically.-Hide sprites you’re not using. Make a reference to them and set them active = They won’t be drawn when offscreen anyway, but something has to determine whether or not they’re visible and chances are you know best, especially when one sprite may be fully hidden behind another and is still drawn.-Batching is your friend. But not always. If you have 40 collectable coins in your level, all using the same sprite then batching will use the one texture source multiple times on a
giant mesh, saving on draw calls. Draw calls=time. In some very rare cases the batch calculations can be a hinderance, depending on how your game’s set up, but if that’s the case, chances are you’re doin’ it wrong. -Resize your sprite’s Quad (the sprite itself) rather than its transform. If you have say a sprite component on a GameObject, then resize the GameObject’s transform, you’re going to break batching on that sprite. Instead consider the next point. With SM2 for example, you’d just set the Sprite/PackedSprite’s “Width” and “Height” properties in the inspector.-If you have a 64×64 sprite, on a 6px wide cube… …then it’s going to look like a small version of your image, but upon zooming in, you’ll see that the full 64×64 sprite has been UV mapped to the cube in perfect detail. Remember what I said about fill rate. Unless your’e zooming in and out, you might not want to use such a large texture. -Use a Sprite Sheet/Atlas where possible. This one ought to go higher, but what the hell. A sprite sheet will allow you to use commonly grouped items like your character, coins, platforms, etc in a single image/texture. Why? Less draw calls! The same part of a texture can be UV mapped to different parts of a 3D shape multiple times. I.e. if you were modelling a red and white stripy candy cane, you’d draw one white and one red line, then apply them multiple times. This is a similar concept. -Use the right shaders! There’s no point using lit shaders if you’ve no lighting, and there’s no point using a transparent shader on a solid square sprite. You can find dedicated mobile shaders in the Unity Store, by googling and doing a little copy-pasta via MonoDevelop or using those that come with SM2/Unity. As of 3.5 I believe the default shaders do a pretty decent job. Coming from various other backgrounds it might be easy to underestimate the importance of these even in a 2D environment.-Do you really need antialiasing/filtering on your sprites? Be sure to check on your target device. Some things will look pretty horrific scaled up on your monitor, but absolutely fine on those tiny high-density screens. Give it a shot, and remember to apply changes to your Sprite Atlas where possible.-Easy on the compression! DXT (DirectX) compression will do a fantastic job on your PC, with hardware decoding, but mobile devices lack this hardware decoder and will have to do it in software. I.e. Slowly. Generally IOS devices will support hardware PVRTC compression and Androids ETC, and keep in mind what I said in the last point. DXT might be fine given that it offers better clarity during say level loads, but you certainly don’t want to be decompressing them during gameplay.-Do you need Mip Maps? Mip maps are scaled down versions of a texture stored within the compressed texture itself. So depending on how far away you are, a lower res copy can be used. Obviously this takes more memory and more decompression time. You probably don’t need ’em for a 2D game. -Conversely……rather than using giant sprites on a non retina display and tiny sprites on a
retina display, it might be worth your while making a small and large version of textures and using each accordingly. -Read/Write enabled textures generate a second copy. Second copy needs more memory. In most cases, you can just leave this turned off.-Tinting a sprite will break batching… …and create a new copy of the source texture in memory. Avoid where possible, or try to pre-make any colors you’ll need! E.g. if all your Numbers in a text sprite sheet are to be red.. do it in photoshop. Loading, Saving and Object Access: -Do you really need to recreate your GUI for each level? You can hide it and have it persist when loading different scenes, reducing loading time. -GameObject.Instantiate() is slow! One common technique (which proved absolutely vital in Truck Toss) is to create a pool of objects during loading. E.g. 4 of each enemy type. When an object’s no longer needed, disable it and shove it back in the pool instead of recreating it. So you’d have a function along the lines of MakePrefab(“path/to/prefab”); which will only only call Resources.Load() provided there are none in the pool.-Resources.Load() is even slower! This function does not cache, and involves reading from the device’s HD or equivalent. Ideally you want a hybrid pool system if you’re doing a lot of loading\unloading. I.e. your standard pool system which preloads objects,
but when the instantiate function is called, it keeps a different copy in a different list. Whenever instantiate’s called and there aren’t enough in the pool but there’s a copy in the spare list, Instantiate from that rather than doing a Resources.Load fresh again.
This is a balancing act of memory use and processor use, so target it for your device. -GameObject.Find() and GetCompoenent().. …are slow (You saw that one coming, right?). If you’re going to be using an object or component repeatedly, then it makes sense to create a reference to it in a local variable rather than looking it up repeatedly.-Reflective functions can be noticeably slower. Reflection is the ability for a language\code to look within itself and get method names\types\scope etc and potentially alter them. I.e. calling a function by string name, or using delegates. Try to avoid this kinda of behaviour for performance critical code. -The garbage collector is slower yet. It has to scan trees of objects looking for orphaned classes and objects, and ‘islands’ of objects with references only to each other, determine how long they’ve been that way, and then free up the memory. Sure you can call it manually, but that’s generally more of a hint to it than a command, and shouldn’t generally be used during gameplay. -Using too much memory……will cause IOS devices to crash\quit and your app won’t be accepted to the app store. That’s actually secondary to the point that when memory’s low, your game will slow down dramatically, especially during garbage collections and when you’re trying to instantiate new objects. Sounds: -Set your BG music to decompress on load. Anything you’ll be using a lot should probably be decompressed on load rather than streaming from the disk (which is slow and can be especially troublesome on Android.) This is another tradeoff situation however, given that decompression can take time and memory. Balance it!-Infrequently used clips… ..may be left compressed in memory, especially if there are lots of them. -Force to mono? Yes yes! Unless you really want stereo and you’ve got some bitchin’ music or sound effects, you’ll save yourself some space on this one. Remember the phone has a mono speaker-Hardware decoding is faster. Well, that’s a generalisation, but faster is better. UI: -Unity’s UI system is slow. Where possible try to use a plugin or sprite package that renders to meshes in 3D space.-OnGUI is slow! Even in a blank scene you can see it spike. Try to have no more than one of these in your code, and centralise branches out from it. It’s fairly easily done.-Try to keep your UI animations in FixedTimestep() functions.This way they’ll stay consistent across multiple devices and framerates. You might benefit from having all of your game logic for every class branch out form a single base call to FixedTimeStep();-Does your UI have to update *every* frame? You might gain a massive performance boost by deferring it to every 2nd or third frame. With truck toss, the game runs much smoother with the entirety of the game logic running on every second FixedUpdate. I know, right?-Moar Cameras! If your game does a lot of scaling\zooming, then why have to scale the UI and risk breaking batching? Add another camera for the UI, and set UI objects’ layers to that of the camera. Again, it sounds like a lot of extra blitting, but could potentially speed your game up with very little in the way of changes.Build Options: -Disable the accelerometer! In older Unities, that was done via #define kaccelerometer_frequency 0 in the AppControler class via XCode. Nowadays you can disable it from within Unity itself, and can free up 2-3 FPS.-In some cases OpenGL ES 1.0 or 2.0……will offer better performance on your device. This seems to vary between devices and Android\iOS. Try on as many devices as you can.-Strip things down! When your game’s running nice and stable, switch compatibility to the .NET 2.0 subset, Stripping Level to micro mscorlib and Script Call Optimisation to Fast but no Exceptions. This will generate a smaller binary with less redundant code and debug symbols. I successfully navigated that one without a stripper reference. Jugs.-Target iOS 5 where possible. There really is no discernible speed difference. However, make sure your XCode project’s settings match, or uploading to iTunes might fail. Perhaps it’s worth exporting another project. Bonus Content – Building Faster!:-Symlink Unity Libraries……from the build settings where possible, this will save copying more files over to xCode, by effectively creating a shortcut. Much love for symlinks.Set your “Debug Information Format”From within Xcode (Build Settings) to STABS, otherwise have fun watching DWARF taking ages. Stabs..dwarf… Lols…-Sometimes using “Build for “……within XCode will build and run faster. Delete the previous version on your device and give it a shot. I have no idea why this is so, but you’re welcome. Bonus Content 2 – Faster physics modelling: This is a fun little technique I use to convert edge chains to solid blocks!Create a fake edge chain, where each link between 2 points is actually a stretched out, rotated cube parented to something, forming the outline of shape of your choice (cloud\star\car\whatever). Hit play, and while the game is running, drag your chain back into the editor to make a prefab. You now have a group of parented objects you can fill in and make solid. This lets you use your own code to generate physics shapes. And finally, Break every rule. In the spirit of hacking away at things, you must fiddle and see what’s going on.If something seems like a silly idea at first, you might just not have thought about it from all angles. Let me know if you’ve anything interesting to add. Happy hacking!
This entry was posted in , , , , , . Bookmark the .
在Unity中提升2D移动游戏性能的46个提示和技巧
版权所有，禁止匿名转载；禁止商业使用；禁止个人使用。
译者：王磊(未来的未来) 审校：崔国军（星际迷航）Unity是一个怪兽。它总是能够用它的多才多艺和性能让我震惊。但是就像任何野兽都需要一点驯服一样(在某些情况下，一些技巧非常的与直觉不符合，但这就是一个比喻而已)。我花费了一点时间让Truck Toss能够流畅的在我的3GS 上运行起来，但是这是一个很棒的技巧列表来帮助你的开发。如果这是你第一次接触Unity的世界，我的第一个提示(这是免费的)是停止试图使用其他的语言和环境。你将使用GameObject，将添加多个脚本组件，并且你需要换一种思考方式。当我第一次开始使用Unity的时候，我的方法是尽可能的忽视预制件(或者像Flash的显示列表那样使用它们)并让一份Box2D的拷贝成功的运行起来。这个过程很痛苦，因为它是偏离标准流程的，让我们准备把其他一些工作放入进来!闲话少说，让我们开始吧:物理部分:-使用内置的物理部分。对于一个2D游戏来说，运行一个完全3D的物理引擎来负责游戏的表现似乎是非常浪费的一个事情。但是需要记住的是，Unity原生核心里面使用的是Nvidia的PhysX引擎。我们谈论的是一个高度优化过的引擎，并且由一个大型专业团队进行维护，而不是一个玩具般的2D引擎。如果想要得到2D的效果，可以不使用Z轴上的移动信息，也不使用X轴和Y轴的旋转信息。。 - 尽量使用1：1的比例。我的意思是，让一个单位= 1米。你可以使用更大或者更小的尺度，但是你可能会在碰撞或者物体下落的时候遇到一些不可思议的情况。记住，没有空气阻力的话，大钢琴会下落的速度跟一个小孩的速度一样快，但如果一切都很大的话，它会显得非常缓慢。你可以摆弄重力来让表现看上去很合理，但再一次提醒，这样做的话有可能会在碰撞的时候出现一些问题。相对我的精灵大小，我喜欢使用1/32作为单位大小，我的摄像机大小为160。 -给你的物体一个合适的质量。这个的道理就跟物体的大小是一样的，如果你让大钢琴的质量是2克或者让一个死婴重达500公斤，事情会变得不可预测。尽量让物体的质量和现实情况比较接近。
-网格碰撞体相比原生的盒子/球碰撞体计算起来更慢。虽然一个球体可能有比立方体更多的顶点，但是球体上的所有点到球心的距离都是一样的，这使得计算的时候相比较计算一堆独立的三角形要方便的多。 -你可以通过组合原始的碰撞体来生成更加复杂的形状。如果你有一个父对象比如说是立方体碰撞体，同时它上面有一个刚体组件，你可以给它添加子物体比如说还是一个立方体碰撞体。那么整个物体在碰撞的时候就会像是一个由多部分物体组成的刚体那样。 - 继续上面的话题。。。你也可以选择不让这么几个物体联系到一起，你可以通过RigidBodies和Colliders添加更多的子物体，然后使用Joint组件将它们与父物体相连。举个简单的例子来说，你可以使用一个父物体来构建一个比较复杂的轿车，然后让整个轿车进行移动。
-一个物体上不支持使用多个基本关节。。。。。。但多个可配置的关节就可以使用在同一个物体上。相比较使用一个网状的关节来连接物体，你可以使用其他的方法，举个简单的例子来说，你可以使用弹簧和一个滑块来将车轮连接到车轴从而减少悬挂对象。 -如果一个物体有碰撞体组件但是没有刚体组件，那么将被认为是static类型。移动这些物体是非常耗费资源的，所以如果你是用代码创建的它们，那么请在设定好这些物体的位置以后，再添加碰撞体和物理材质(给碰撞体添加的)。-有人说让solver的迭代次数尽量保持固定是一个良好的实践行为，但是我的看法则不然。。。。。。你可能会觉得每两次更新再做一个全量的迭代可能会对性能有好处。比如说8、4、8、4、8、4。但是这样的效果可能不如每次对固定的对象进行迭代，这可能是因为处理器可以在加载的时候减少一些负担，所以提供尽可能一致的迭代信息可能是有好处的。如果它（每两次进行一次完全迭代）可以减少处理器的负载，这样做会提供一个稳定的物理模拟。所以我说这个做法是违反直觉的。-有人说对刚体进行内插值和外插值是不鼓励的但是我的看法则不然。。。。。。 。。。在某些情况下，你会发现还不如每帧都更新全部刚体，然后对整体进行迭代更新可能会得到一个更好的结果，可见降低开销。- 降低你对物理单位时间段的要求如果你瞄准的是一个不切实际的60 fps的目标，而你的手机却在不断的挣扎，你最好是满足于一个较低的帧率，让手机有一些喘息的空间。我喜欢用一个固定的更新时间0.03秒，最高也就是0.05秒。再一次，可以把更新时间减少一点，反而能够得到更好的帧速率，这很违反直觉，但是值得试一试。-time scale的缩放。这可能会有帮助，这取决于你所希望得到的感觉。它只是模拟了每次迭代之间有更多时间流逝的感觉。把这个值设置过高显然会把碰撞弄得一团糟，特别是如果一个对象在一帧里面移动的特别快，举个简单的例子来说，一个物体一帧里面移动了1英里，那么它根本就不会发生碰撞。 精灵& 纹理我的引擎在精灵管理器方面使用了一个混合系统，既使用了EZGUI也使用了RageSpline来表示精灵，但我使用了2 d工具包，以下这些技巧仍然适用。
-别对填充率太苛刻!（其实作者的意思是要对填充率太苛刻）这个看上去可能挺明显的，但是如果你有一个64*64大小的图像，但是只有左上角的32*32的部分被填充了，但是它仍然是一个64*64大小的精灵。如果有可能的话修剪你的图像的透明部分。大量的库可以自动完成这个功能。- 隐藏那些你不使用的精灵。保留它们的引用，然后设置它们的active属性为false。这样的话，在离屏渲染的时候根本就不会绘制它们，但是有时候必须确定它们是否可见，而这些事情可能你知道的更加清楚，特别是一个精灵可能会完全被另外一个精灵遮挡住，但是它可能仍然被渲染了。-批次合并是你的朋友。但并非总是如此。如果在你的关卡中你有40个需要收集的硬币，它们都使用了相同的精灵，那么在这种情况下，批次合并会多次在一个巨大的三角形网格上使用同一个纹理图片，来节省对渲染的调用。对渲染的调用就等同于时间。在一些非常罕见的情况下，批次合并的计算可能会成为一个阻碍，这主要是依赖于你的游戏具体是如何设置的，但如果是这种情况的话，很有可能是你把什么事情给弄错了。 - 调整你的精灵所在的四边形（也就是精灵本身），而不是精灵的位移组件。假设你的一个游戏物体上有一个精灵组件，然后调整这个游戏物体的transform组件，那么这么做将打断对这个游戏物体上精灵组件的批次合并。让我们用SM2(渲染模型2)举个例子，你最好是在属性检视窗口设置精灵/打包精灵的“宽度”和“高度”属性。- 如果你有一个64*64大小的精灵，用于一个只有6个像素宽的立方体上。。。。。。然后它会看起来像是你的图片的一个缩小的版本，但是如果放大看的话，你会看到完整的64*64大小的精灵已经以完美的细节做了UV映射到立方体上。还记得我说过的填充率的问题么。除非你需要对立方体进行放大和缩小，否则你可能不需要使用这么大的纹理。 - 如果可能的话，使用纹理表或者打包图集。这一条提示应该放在文章更显著的位置，等到现在才提出来有点太晚了。一张精灵表将允许你将常用的精灵进行合并摆放，比如将你的角色、硬币、平台等等放在一张单独的图片或者纹理之中。为什么要这么做呢？主要是为了减少对渲染的调用！纹理的同一个部分可以通过UV多次映射到三维形状上的不同部分。让我们举个简单的例子，比如说你在建模一个有红色和白色条纹状的拐杖糖，你可能会画一条白线，然后画一条红线，然后多次应用这两条线。这是一个相似的概念。 - 使用正确的着色器！如果你的游戏中没有使用光照的话，那么就根本没有必要使用带有光照的着色器，对于一个不透明的方块精灵，也没有必要使用带有透明度通道信息的着色器。你可以在Unity商店找到各种专门用于手机的着色器，通过做一些搜索然后复制再在编辑器中做一点修改就能使用了，或者使用那些来自SM2或是Unity的着色器。我使用的是Unity3.5的版本，我相信默认的着色器已经非常棒了。即使是在2D环境下，从来自各方面的消息或者信息来看，这些（使用正确地着色器）的重要性很容易就被忽略了。- 你真的需要对你的精灵进行抗锯齿或是过滤操作么？一定要检查你的目标设备是什么。有些东西在显示器上放大以后看起来非常可怕，但是在那些细小的高密度屏幕上面就绝对是没问题的。尽量在你的目标设备上看效果，如果可能的话，要记得将修改应用到你的图集里面。-尽量少使用压缩！ DXT（DirectX）压缩在个人电脑上通过硬件解码做了非常出色的工作，但移动设备缺乏这种硬件解码器，将不得不通过软件进行解压缩。这会非常的慢。一般来说IOS设备将支持通过硬件压缩PVRTC，而安卓设备将支持通过硬件压缩ETC，而且要记住我在上一点里面说的内容。DXT压缩也许是可行的，考虑到在关卡读取的时候它可以执行解压缩的操作，但是如果在游戏运行中进行解压缩就是完全不可以接受的。-你需要mipmap么？mipmap是在压缩纹理自身内存储的缩小版本的一系列纹理。所以取决于你从多远看这个纹理，较低精度的纹理可以被使用。很显然，这需要更多的内存和更多的减压时间。可能对于一个2D游戏来说，可能这个功能并不需要。-反过来。。。。。。如果是在一个非retia显示器上显示一个巨大的精灵或者在一个retia显示器上显示一个很小的精灵，这就可能值的同时制作大小不一的各种版本的纹理，然后根据需要来选择合适的纹理进行显示。 -允许读取和写入的纹理会产生第二份拷贝。第二份拷贝需要更多的内存。在大多数情况下，你可以关闭这个选项。 - 给纹理一个不同的颜色将打断这个精灵的批次合并。。。。。。同时也会在内存中创建源纹理的一份新的拷贝。尽量避免可能的情况，或者提前准备好你需要的各种颜色！举个简单的例子来说，如果在文本精灵表中所有的数字都是红色的话，那么就提前在photoshop做这个事情。 加载、保存和物体访问： -你真的需要为每个关卡重新创建UI么？ 当加载不同的场景的时候，你可以隐藏这些关卡UI，并让它一直存在下去，这样可以减少加载时间。
-GameObject.Instantiate()函数是非常慢的! 一个通用的技巧（这在Truck Toss中已经证明过绝对有用了）是在加载的时候创建一个对象池。举个简单的例子来说，为每个敌人类型创建4个对象。当一个对象不再需要的时候，禁用它并把它放回到对象池而不是重新创建它。所以你应该有一个像MakePrefab（）这样的函数。这只会在对象池里面没有对应的空闲对象的时候才会调用Resources.Load()。 -Resources.Load() 甚至更慢! 这个函数根本就不会做任何的缓存，并且涉及从设备的硬盘或者其他存储空间里面进行读取。理想情况下，如果你需要处理很多有关加载或者卸载问题的话，你想要的是一个混合的对象池。举个简单的例子来说，你的标准对象池是用来预加载对象的，但是当实例化函数被调用的时候，它会让一个不同的拷贝保存在一个不同的列表里面。每当实例化函数被调用，并且对象池里面没有足够的空间，但是会有一个拷贝在备用列表里面，会从备用列表里面进行实例化而不是再次调用Resources.Load函数。这是使用内存和使用处理器之间的一个平衡，所以根据你的目标设备来进行调整。
-GameObject.Find()和GetCompoenent()。。 。。。这些函数很慢（你看到过这方面的例子，对吧？）。如果你打算对一个对象或组件反复调用这个函数的话，最好是创建用局部变量创建一个引用，而不是反复地进行查找。 -反射功能可能会非常非常的慢。反射是编程语言或者代码用来查找自身信息的一种能力，可以用来获取方法的名字、类型、作用域等等并有可能改变它们。举个简单的例子来说，可以通过字符串的名字来调用对应的函数，或者是使用委托进行对应的函数调用。尽量避免对性能敏感的代码来使用这种行为。
- 垃圾收集器也非常的慢。它必须扫描对象树来寻找孤立的类和对象，以及只有彼此引用形成孤岛的对象，确定它们已经处于这种状态有多久，然后释放内存。当然你可以进行手动的调用，但通常情况这不是一个指令，更像一个提示，垃圾收集在游戏中通常情况下不应该被使用。
-使用了太多的内存。。。。。。这将导致IOS设备崩溃或者闪退，这样你的应用程序就不会被苹果商店接纳。还有一个次要的影响就是如果内存只剩下很少的情况，你的游戏将会运行的非常非常慢，特别是在垃圾收集期间或者当你试图创建一个新的游戏物体的时候。 声音部分: -将你的背景音乐设置为在加载的时候解压。尽可能的使用“在加载的时候解压”而不是“从硬盘中进行流格式读取”（这种方法很慢，而且在安卓平台上可能会遇到很多问题）。但是这其实是另外一种权衡，因为解压会花费时间和占据内存。尽可能的平衡这两个! - 对于不频繁使用的音乐剪辑。。。。。。也许可以在内存以压缩格式保留，特别是如果它们很多的情况下。
-强制使用单一声道？是的是的!除非你真正想要的是立体声效果，或者你有一些非常特殊的音乐或者音效，通过这种设置，你可以为你的游戏节省一些空间。请记住，手机的播放器其实就是一个单一声道的播放器。 - 硬件解压缩更快。在通常意义上，确实如此。 UI部分: -Unity的UI系统非常的慢。在可能的情况下尽量使用插件或者精灵包来在三维空间里面渲染网格。 -OnGUI函数运行的很慢! 即使是在一个空白场景，你也可以看到它运行的很慢，尽量在你的代码不超过一个地方使用这个它，同时也尽量减少分支。这很容易做到。 -尽量在FixedTimestep()函数里面运行的你UI动画部分的代码。这样的话，UI动画部分可以在不同的设备和帧率上运行的一致。如果你的所有游戏逻辑代码都遵循对FixedTimeStep()的一个简单调用，你可能会因此而受益。 -你的UI部分的代码必须要每帧更新么？通过把每帧更新改为每两帧更新或者每三帧更新，你可能会获得巨大的性能提升。在truck toss，整个游戏逻辑只会在每2帧的FixedUpdate里面更新逻辑一次，这样整个游戏运行起来流畅的多。这会对你有帮助么？ - 使用更多的摄像机！如果你的游戏做了很多扩展\缩放，那么为什么要冒着风险对UI进行放缩呢？而这有可能会导致批次合并不能顺利的进行。给UI部分添加另外一个摄像机，并把UI物体的层级设为那个摄像机关注的层级。再一次，这听起来像是多做了一次绘制，但是这些非常微小的变化可能会极大的加速你们的游戏。 构建选项: -禁止整个加速器！ 在旧的Unity版本里面，这是通过在XCode里面的AppControler类使用使用定义宏来实现的。现在你可以在Unity引擎里面直接做这个事情，并且可以提高2 - 3帧/秒。 -到底是选择OpenGL ES 1.0还是2.0。。。。。。到底选择哪一个能够在你的设备上得到更好的性能。这看上去似乎会依据设备的不同以及平台的不同而有所变化。尽可能的在尽量多的设备上试验，然后做出你的选择。 - 尽量减少编译信息！在保证游戏运行稳定的前提下，可以切换到Net子集，将Stripping Level设为micro mscorlib，而将Script Call Optimisation设为Fast but noExceptions。这将生成一个更小的二进制包，没有冗余的代码和调试符号。我成功的生成过没有调试信息的安装包。 - 尽可能把目标设为iOS5。尽管这样做不会在运行速度上有明显的差异。但是，确保你的XCode工程设置上是匹配的，否则的话上传iTunes可能会失败。也许单独导出到另外一个工程是值得的。 奖励内容-构建的更快！-对Unity的库进行符号链接。。。。。。尽可能的在构建设置中这么做，这将通过有效的创建快捷方式来减少到xCode的文件拷贝。符号链接真的是太棒了。 -有些时候使用“Build for”。。。。。。在XCode下这样会构建和运行的更快一点。在你的设备上删除以前的版本，并仔细的看看这个的效果。我不知道为什么会这样，但是这样用也没关系。。。最后一部分，不要受到规则的约束。要有用于探索一切未知事物的精神，你必须通过实验来看看到底会发生什么。如果某个事情在一开始看上去似乎是一个愚蠢的想法，可能只是你没有从各个角度想过这个问题。如果你有什么有趣的规则需要添加，请让我知道。让我们一起快乐的尝试吧！ 【版权声明】原文作者未做权利声明，视为共享知识产权进入公共领域，自动获得授权。
分类：程序新手圈
请勿发表无意义的内容请勿发表重复内容请勿发表交易类内容禁止发表广告宣传贴请使用文明用语其它
淫秽色情政治倾向人身攻击抄袭剽窃广告刷屏恶意挖坟冒充他人其它
登录后参与讨论。点击