第一篇：unity开发游戏的优缺点
Unity做游戏的几个优势：
1、跨平台，平台相关的功能Unity都已经帮你实现好了。即便有些Unity没有实现，也有插件帮你实现。
2、基于Unity的酷炫的粒子光效编辑。Unity本身就是一个功能强大的粒子编辑器。之前我还认为cocos2d-x的粒子系统的功能足够了，但是跟专业的编辑器比起来，远远不够。粒子系统要跟粒子特效编辑器配合起来，其功能远远不是之配置一个粒子系统的几个参数就可以的。cocos2d-x本身的粒子系统是很鸡肋的功能，只能拿来做一些简单的光效，不可能用来做复杂的技能特效。
3、由于框架和架构的优势，Unity的游戏可以极大程度避免崩溃和闪退。由于代码都是c#写的，并且是组件结构，所以即便出了错误也只是个异常而已，而不会影响到系统流程。
4、强大的性能分析工具，可以轻易的找到内存和cpu的瓶颈。支持Android和iOS的真机运行分析。
5、编辑器可以方便的进行扩展，不需要像传统游戏公司一样，有一个专门写编辑器的部门。无论是场景编辑器还是技能编辑器都可以轻松搞定。如果想玩高科技的话，还可以把技能编辑器做成可拖拽的模块化结构，策划可以像搭积木一样来编辑技能。最重要的是，这些都是所见即所得的。
6、方便的资源管理系统。使用Unity，你不用特意维护几份资源（比如原始资源、打包后的资源、iOS版本资源、Android版本资源等等），只要一份资源，然后Unity里面可以设置它的具体参数，比如使用纹理压缩、最大限制在512x512大小等等。Unity发布游戏的时候会自动根据平台相关的导出选项导出正确的资源。
7、丰富的插件。有大量的功能我无论拿cocos2d-x还是Unity都不知道怎么实现。比如一些shader特效、物件碎裂的特效、场景破坏和变形的特效等等，这些在Unity插件中都可以找到对应的实现。而且很多Unity的游戏都可以反编译，无形中又可以学到很多东西。
8、熟悉之后确实感觉Unity很简单。很多功能都是成体系的自然而然的。比如物理、碰撞检测、导航寻路、场景管理、场景烘焙。这些无论拿哪个出来都是相当有技术的功能，但是在Unity中几个按钮、几步操作就可以实现对应的功能。
至于缺点也有一些：
1、最主要的，无论是Unity还是插件都是要收费的。（破解版，等赚钱了再考虑回馈）
2、由于iOS平台的一些限制，Unity很难做动态代码更新。而cocos2d-x有lua这个比较成熟的方案。（如果程序稳定了，需要频繁更新代码的机会不多，更多的是更新配置和资源）
3、可能有些人不熟悉Unity，从而选择了开源的cocos2d-x。适应Unity的框架、工作方式需要一定的时间。（相信我，不会很长，要知道一个8岁的孩子都能拿Unity来做游戏，并且上架，如果有程序员说搞不定Unity，那干脆转行卖烧饼吧）
4、对应上面的第6点，由于Unity中资源对应的配置有很大的重要性，所以一个Unity功能就是资源+代码的整合，你很难分出一个资源包。这样你的Unity项目可能很大。（使用AssetsBundle打包后可能避免这个问题，但是项目初期资源变动大，经常打包很不方便）
5、Unity很多设计都是为可视化编辑考虑的，举个例子，2D的动画可以方便的拖几张图片就可以搞定。但是如果我每张图片都有一定的偏移，那就麻烦了，需要自己重新实现帧动画功能，自己加载配置文件来实现。（这个严格说来不是引擎的问题，毕竟引擎不是为了一家游戏公司设计的，大众化的简易的操作方式是唯一需要考虑的。但是很多时候确实感觉有些不爽）
第二篇：IT部开发优缺点分析
ＩＴ部内部开发的优缺点对比
优点：
1内部沟通；内部员工沟通比较方便，顺畅；
2熟悉公司业务情况；内部开发IT部开发人员较为熟悉公司业务情况，能够减少调研时间；
3持续优化方便；知根知底的工作，如果业务或者管理模式发生变化，那么公司可以较好的应对这些变化；
4核心数据和架构不受牵制于其他企业，易整合；
缺点：
1IT部开发人员较少，项目任务较多；开发进度较为缓慢，影响进度；
2缺少制度化管理；内部做需求管理，由于没有设计到精确的成本计算，所以用户会轻易不停的修改需求，产生无数变更，这明显会使项目周期延长；
3工作繁忙，技能培训较少：IT部工作量大，内部人员经常加班，较少时间能进行技能培训，接触到更先进的技术方便用到工作之中；
4内部结算较为麻烦；流程较多，没有外部结算方便；
第三篇：Unity之工作总结
图片格式
----------1 DrawCall
-----------2
图片格式：
NGUI生成的图集的图片格式是PNG格式，但是无论是什么格式的图片 Unity都会自己生成一套格式，并且打包的时候不会用文件夹下面的格式，而是Unity自己格式。
如果你用的UITexture 你可以对每一张图来修改格式，比如颜色数比较少的图片可以使用16bit，如果没有透明，可以使用pvr或者etc 这样图片会小很多。如果是UISprite 只要有透明的 就必须使用RGBA32 要不然UI会很难看。
除去 UITextuer和Atlas的图片之外（因为有透明），其余的贴图必须是2的幂次方。因为只有2的幂次方图片，并且没有透明通道的才会被压缩。Ios会被压缩成pvr格式，Andriod会压缩成etc格式。压缩之后会小很多。
人物贴图 场景题图 特效贴图 一定要是2的幂次方。
贴图透明通道分离，压缩格式设为ETC/PVRTC 最初我们使用了DXT5作为贴图压缩格式，希望能减小贴图的内存占用，但很快发现移动平台的显卡是不支持硬件解压DXT5的。因此对于一张1024x1024大小的RGBA32贴图，虽然DXT5可将它从4MB压缩到1MB，但系统将它送进显卡之前，会先用CPU在内存里将它解压成4MB的RGBA32格式（软件解压），然后再将这4MB送进显存。于是在这段时间里，这张贴图就占用了5MB内存和4MB显存；而移动平台往往没有独立显存，需要从内存里抠一块作为显存，于是原以为只占1MB内存的贴图实际却占了9MB！
所有不支持硬件压缩格式都有相同的问题。解决方案：
现在Andriod硬件最广泛支持的时Etc ,IOS上支持的时PVRTC。但这两种格式都是不带透明（Alpha）通道的，因此我们需要将每张原始贴图的透明通道分离出来，写进另一张贴图的红色通道里，这两张特图都采用Etc/Pvrtc压缩。渲染的时候 将两张贴图都送进显存。同时 我们修改了NGUI的shader 在渲染时第二张贴图的红色通道写入到第一张贴图的透明通道里恢复原来的颜色：
1.2.3.4.5.6.} fixed4 frag(v2f i): COLOR {
fixed4 col;
col.rgb = tex2D(_MainTex, i.texcoord).rgb;col.a = tex2D(_AlphaTex, i.texcoord).r;return col * i.color;
这样，一张4MB的1024x1024大小的RGBA32原始贴图，会被分离并压缩成两张0.5MB的ETC/PVRTC贴图（我们用的是ETC/PVRTC 4 bits）。它们渲染时的内存占用则是2x0.5+2x0.5=2MB。
DrawCall 当两个renderQueue相邻的DrawCall使用了相同的贴图、材质和shader实例时，这两个DrawCall就可以合并。但需要注意的是DrawCall合并不见得会提高性能，有时反而会降低性能
如果是UIGeometry为了渲染绘制准备数据，那么UIDrawCall其实是定义了渲染绘制需要的基本组件。这里拿煮菜做个比喻帮助理 解：UIGeometry好比为煮菜准备食材，UIDrawCall好比是煮菜的工具（锅，炉子等），UIPanel就是大厨了决定着什么时候该煮 菜，UIWidget（UILabel，UISprite和UITexture）是这道菜怎么样的最终呈现。
UIWidget分别用UpdateGeometry和WriteToBuffers对UIGeometry的ApplyTransform和 WriteToBuffers进行封装调用，ApplyTransform是根据UIPanel的坐标调整Vertices的坐 标，WriteToBuffers将UIGeometry的Vertices，UVs和Colors添加进UIPanel的Vertices，UVs和 Colors的BetterList中。
这里还有一个细节就是：UIGeometry中的Vertices，UVs和Colors的BetterList的buffer什么时候得到，因为这些都 是UIWidget或其子类的信息，所以在UIWidget的子类UILabel，UISprite和UITexture中OnFill函数生成 UIGeometry的BetterList的buffer。
UIWidget这个脚本中的两个函数：WriteToBuffers，OnFill，UpdateGeometry。
WriteToBuffers和OnFill这两个函数都是将Vertices，UVs和Colors等add进参数的List中去，查看 WriteToBuffers的调用出发现其参数是UIPanel的Vertices，UVs和Colors，而OnFill的参数是 UIGeometry的Vertices，UVs和Colors。
WriteToBuffers只是对UIGeometry的封装调用，也就是说将UIGeometry的Vertices，UVs和Colors等信息add进UIPanel的对应List中。
UIGeometry的脚本，一直有一个疑问：UIGeometry的Vertices，UVs和Colors的List没有看到add方法的执行，只有在WriteToBuffers被add。直到看到了OnFill才恍然大悟，虽然UIWidget的OnFill是虚函数，没有具体实现，看了下 UISprite重写的OnFill函数，就是把Vertices，UVs和Colors 添加到UIGeometry的Vertices，UVs和Colors中。所有UI组件的Vertices，UVs和Colors都汇集到UIPanel的Vertices，UVs和Colors去了，然后 UIPanel指定给UIDrawCall渲染就行了
UIWidget的一些实现细节，MakePixelPerfect():对gameObject的localPosition和locaScale进行微调和纠正。SetDirty():调用UIPanel的SetDirty()对组件的变更进行重建（rebuilt)。Uiwidge UIGeometry& UIDrawCall 的关系：
UIWidget 中有两个变量UiDrawCall mDrawcall 和UIGeometry mGeo 的verts uvs cols 的BetterList,然后UiWidget 的UpdateGeometry函数对UIGeometry 的ApplyTransform()和WriteToBuffer()调用进行更新.每一个UIwidget都有一个UIGeometry 但是不都有一个UIDrawCall,而是通过Batch合并达到减少DrawCall的数量，UiDrawCall是有UiPanel生成的。
DrawCall的数量优化
根据上述描述可以得出一个结论：使用相同material的连续的Uiwidget(UILable UiSprite)公用一个UIDrawcall。通过这个结论我们可以得到一个解决DrawCall过多的问题，UIPanel生成DrawCall时是Fill()方法。Fill 方法对UiWidget.list进行检测把使用相同Material的连续的Uiwidget合并生成一个DrawCall ,UIWidget.List 的排序是根据UiWidget的Depth进行的。所以解决方案有两种：
1.修改UiWidget(UiLable UIwidget)的Depth,限定UIwidget.List的排序 2.重写Uiwidget的CompareFunc()方法。（重写UIWidget的CompareFunc也是可以的，按照Material的name优先排序，只有当material一样是才考虑depth进行排序：）
3.无重叠时自动重排。绘制顺序按照Hierarchy
采用第二种方式减少DrawCall: Material leftMat = left.material;Material rightMat = right.material;if(leftMat == rightMat){ if(left.mDepth < right.mDepth)return-1;else if(left.mDepth > right.mDepth)return 1;else return 0;} if(leftMat!=null & rightMat!= null)return string.Compare(leftMat.name,rightMat.name);if(leftMat!= null)return-1;if(rightMat!= null)return 1;
return(leftMat.GetInstanceID()< rightMat.GetInstanceID())?-1 : 1;
夹层问题：
因为Material使用的Shader使用了透明，这样就不能做深度测试，也就是Mesh的“深度”是不影响的，这样最终的显示就跟Shader的 renderQueue有关了，即renderQueue越大，显示的越靠前面（重叠的图层，renderQueue越大，越靠前）。当然现在只有增加一 个DrawCall（如多使用一个UIPanel或用另外一个Material)来做到Material的夹层效果。
特效层级：
粒子系统的渲染顺序列默认为3000 而NGUI的渲染顺序默认是从3000开始，当有嵌套的Panel或者Deoth更高的panel时，NGUI的渲染顺序会高于3000
解决方案：
1.修改Ngui中的panel脚本中的默认RenderQueue 调整到3000以下，这样就不会挡住粒子特效。当窗口显示在特效上面时把窗口的RenderQueue调整到3000以上，就解决了。
2.使用另外一个摄像机显示特效，但是Ui窗口切换时不太好控制
3.修改例子特效的shader中的RenderQueue的值（需要考虑特效中的层级关系）一级界面 二级界面..浮动窗口
1.不同图集
项目中做到复杂一些的界面，经常会用到多个图集，以技能界面为例，项目中常用的图片放到共用图集中，这是一个图集，技能界面本身独有的元素，比如跟技能职业相关的背景，算作第二个图集，还有一些技能图标，图标单独归类到一个图集中，再一个就是字体的图集。基本一个界面如此分法，最多需要4个图集。NGUI的图集之间的 处理，默认是靠调整控件的Z值来区分的，但是这里他可以调整同一个图集每个一个控件的Z值，其实不是很好。经常会出现图层相互遮挡的情况，尤其对于控件比较多的界面，一段时间回过来再修改界面的时候，整个要崩溃。
解决方案：在UIPanel中，为每一个Material添加一个layer的变量，当同一图层靠depth来决定前后关系，不同图层靠 layer来决定前后关系，在绘制UIDrawCall的时候，根据layer对跟节点做一定偏移。这样就能从Z值中解放出来。如果大家也有碰到图层的问题，可以参考这样的做法，以此种方法来处理图层关系，简单，做过项目的圈套UI，还未有不能解决的情况。
UI自适应
Scaling Style 的作用是制定UiRoot的缩放类型，如果是PixelPerfect ,Minimum Height 和Maximum Height 才起作用，scaling style 选择的是
Pixelperfect 要对Minimum Height和Maximum Height进行设置。(如果是PixelPerfect缩放类型，当屏幕的分辨率大于Maximum Height，则以Maximum Height 为基础缩放，反之，如果屏幕分辨率小于Minimum Height 则以Minimum Height为基础进行缩放。例如，如果屏幕高度为1000，而设置的Maximum Height值为800，则UI界面整体放大为原来的1000/800=1.25倍。)FixedSize : 跟Manual Height有关
FixedSizeOnMobiles :跟Manual Height有关
只是针对IOS和Android上的判断，也就是说只有IOS和Android平台下FixedSizeOnMobiles才起作用.FixedSize或FixedSizeOnMobiles，则缩放只以Manual Height为参考，屏幕分辨率的高度值不同于此设置值时，则根据其比例（即Screen Height / Manual Height）对整棵UI树的进行“等比”缩放（宽度的缩放比也是此比例值）。
注释：如果设置FixedSize,UIWidget.height（以UiRoot默认值进行高度缩放）是不会改变的，不管实际屏幕分辨率的像素是多少，Anchor Stretch的背景图片高度始终是manualHeight.UIRoot下的UIWidget的height参数一直都是实际的值
UIRoot 是基于高度进行缩放的如何做以宽度适配。
UIRoot是基于高度放缩的，即放缩的比例是以高度为参考的，所以UIRoot有一个manualHeight的参数。那么对于横版游戏显然不行，要是 能实现基于宽度放缩。所以可以通过设置一个“manualWidth”的参数来做。比如我们项目中使用的是 1024 作为UI的宽屏尺寸，通过换算设置manualHeight的值：
int height = Mathf.Max(2, Screen.height);manualHeight = Screen.height * 1024 / Screen.width;//基于宽度的屏幕分辨率自适应
注释：UIRoot其实就做了一件事情：根据Screen.height和UIRoot.activeHeight的比例来调整UIRoot的 loaclScal，从而保证UIWidget（UISprite，UILabel）可以按照其本身的大小进行设置，而不用经过复杂的换算过程。
资源分离打包与加载
资源分离打包与加载是最有效的减小安装包体积与运行时内存占用的手段。一般打包粒度越细，这两个指标就越小。但打包粒度也并不是越细就越好。如果运行时要同时加载大量小bundle，那么加载速度将会非常慢——时间都浪费在协程之间的调度和多批次的小I/O上了。此需要有策略地控制打包粒度。一般只分离字体和贴图这种体积较大的公用资源。
关闭贴图的读写选项
Unity中导入的每张贴图都有一个启用可读可写（Read/Write Enable）的开关，对应的参数是TextureImporter.isReadable。选中贴图后可在Import Setting选项卡中看到这个开关。只有打开这个开关才可以对贴图使用Textuer2D.GetPixel，读取或改写贴图资源的像素，但这就需要系统在内存中保留一份贴图的拷贝，以供Cpu访问，但是一般游戏运行过程中不会有这样的需求，因此我们对所有贴图都关闭这个开关，只在中做贴图导入后处理（比如对原始提贴图分离透明通道）时需要打开这个选项。这样，上文提到的1024x1024大小的贴图，其运行时的2MB内存占用又可以少一半，减小到1MB。Texture图片空间和内存占用分析
纹理大小影响：
可以将其他（非二的幂-“NPOT”）纹理大小用于 Unity非二的幂纹理大小通常占用的内存稍多一点，由 GPU 进行读取的速度可能较慢，因此考虑到性能，最好尽可能使用二的幂大小。如果平台或 GPU 不支持 NPOT 纹理大小，则 Unity 会缩放纹理并将其填补为下一个二的幂大小，这甚至会使用更多内存并使加载更慢
Iphone：
空项目
空间占用量42.3M
ipa包10M 10张1200*520 无压缩Texture 单张图占用量2.8M
空间占用两70.2M ipa包 22.9M 10张1200*520压缩成1024*1024 PVRTC4 单图占用量0.5M 空间占用量47.3M ipa包 13.2M 10张1024*1024 无压缩Texture
单图占用量4M
空间占用量82.M
ipa包14.6M 10张1024*1024压缩为PVRTVC4格式
单张图占用量0.5M 空间占用量 47.3M ipa包 11.6M
综上所述：
1.2的N次方大小的图片会得到引擎更大的支持，包括压缩比率，内存消耗 打包压缩大小，而且支持的力度非常大。
2.减小图片的占用大小和内存方式有：图片大小变化（Maxsize）,色彩位数变化（16位色 32位色），压缩PVRC格式
3.U3D对于图片的格式是自己生成的，而并不是你给它什么它用什么格式。一张1024*1024图在无压缩的格式下，他会被U3D无压缩文件像是存放，也就是说U3D 里的Texture Perview 里显示的占用大小**M 不只是内存占用的大小，还是空间占用大小。
Unity 图片压缩格式介绍：
U3D 的内部机制为自动生成图片类型来替代我们的图片在图片的压缩方式需要进行谨慎的选择。几种比较主要的压缩格式：
RGBA32 BIT/AutomaticTurecolor(256*256 256k)
格式为无压缩最保真格式，最消耗内存和空间的格式。RGBA16 BIT/
格式为无压缩16位格式，比32位节省一半的空间和内存，与Automatic16 相同。RGBA Compressed PVRTC 4bits格式为PVRTC 图片格式，它相当于把图片更改了压缩方式新生成了一个图片来替换原来的图片格式
贴图格式：
3D游戏中贴图的的分类：
UI贴图
ui是按照 1280*853比例出的图
3D场景贴图 主要是因为多重采样的缘故。3D游戏一般来说都是受摄像机远近大小改变而采取不同的采样大小，如果不设置多重采样的话，在远处有非常多的白色噪点。
2D游戏
所有都不需要勾选多重采样，具有3D性质的贴图，我们都需要勾选上GENERATE MIP MAPS，这样会使贴图大小增加25%这样。
正方贴图与非正方贴图也要区分: 非正方贴图只有16位的压缩（相当于真彩色减半），所以最好游戏中都是正方的贴图。正方贴图： IOS：
普通不透明： RGB PVRTC 4 BITS
普通透明： RGBA PVRTC 4 BITS(256*256 32kb)Androis:
普通不透明： RGB ETC 4 BITS(256*256 32kb)
普通透明：因为没有通用的兼容模式，所以一般情况是用RGBA 16 BITS 或是针对不同的GPU选择 DXT5/ATC8 BITS/ETC2 8BITS。如果技术支持，可以采用 RGB ETC 4 BITS 加一张Alpha 8的贴图来实现透明效果。
非正方形：
一般采用16位压缩，16位色会带来颜色损失，如果本来美术就按16位色画的话，就不会带来损失。日本的很多2D游戏都是采用那个16位来画的。少渐变 和艳色。
不透明贴图： RGB 16 BIT（256*256 128KB）
透明贴图： RGBA 16 BIT（256*256 128KB）
高清不压缩贴图：
RGBA 32 BIT(256*256 256kb)
对于不重要的贴图，模糊度低的贴图，建议不仅要采取像素压缩，还要直接压缩其大小。如光照贴图压到512或256。如背景原本1024的图直接压到256。玩家不注意到就可以了。
注意：
U3D所有图片的压缩格式都会以另一种方式存储，不会以你给的方式存储，只有你指定了某种格式，他才会转换成你要的格式。而且在Andriod 里的并不一定有效，因为Andriod的机型多，GPU的渲染方式也不一样，RGBA16 适应于所有机型
GameObject数量
场景中GameObject的数量也是衡量性能的重要指标，频繁的创建 和销毁GameObjec 是非常耗时，场景中存在的GameObject会占用内存，如果GameObject上挂有物体的话，每个GameOject的脚本都需要实力化。
整理图集
整理图集的主要目的是节省运行时内存（虽然有时也能起到合并DrawCall的作用）。从这个角度讲，显示一个界面时送进显存的图集尺寸之和是越小越好。一般有如下方法可以帮助我们做到这点： 1)在界面设计上，尽量让美术控件设计成九宫格拉伸，即UiSprite的类型是Sliced.这样美术素材可以切出一张很小的图片在unity中做拉伸。当然一个九宫格也就意味着其定点数量会从4个增加到16个（如果九宫格的中心格子采用Tiled做平铺类型的话，定点数会更多），构建DrawCall的开销会更大。但一般只要DrawCall安排合理就不会出问题 2)同样在界面设计上 尽量设计成对称的形式，这样在切图的时候美术切图的时候就可以只切一部分，我们在Untiy中将完整的图案拼出来，比如一个圆形图案我们可以只切四分之一，不过与上述第一点类似这样会增加定点个数，同时也会增加场景中GameObject的个数，因为GameObject的数量增多时会占用跟多的内存，所以只对尺寸较大的图案采用这种方法。3)4)确保不要让不必要的贴图素材驻留内存，更不要在渲染时将无关的贴图素材送进显存。为此需要将图集按照界面分开，按模块划分图集，一个界面中的UISprite也不要使用别的界面的图集。数量庞大 且数量不固定的物品不要使用图集 要采用UITexture 减少图集中的空白地方。完全透明的像素和不透明的像素所占用的空间是一样的，因此在像素量不变的情况下，要尽量减少图集中的空白。比如有时一张1024x1024的图集中，素材所占的面积还没超过一半，这时可以考虑将这张图集切成两张512x512的图集。（可能有人会问为什么不能做成一张1024x512的图集，这是因为iOS平台似乎要求送进显存的贴图一定是方形。）当然，两张不同图集的DrawCall是无法合并的，但这并不是什么问题。5)
根据各个UI控件的设计安放Panle,隔开DrawCall 在合并DrawCall时需要注意，如果将会移动变化的UI控件和一个静止不变的UI控件的DrawCall合在一起，当其中一个UI控件（UiWeight）的位置 大小 或颜色等属性发生变化时，UIPanle就需要重建这个Panle上的所有DrawCall。有时重建一个DrawCall会消耗不少的CPU，它需要计算这个DrawCall上的所有顶点信息，包括顶点位置 UV和颜色等，如果很多的控件都集中在同一个DrawCall上，那么其中一个控件上有一点点变化，这个DrawCall上的所有的顶点就都需要遍历一遍。而如果我们的UI又大量的采用九宫格拉伸，使控件的顶点数量就会变得更多。因此重建一个DrawCall 的开销会更大。
因此需要将UI控件分组，将一段时间内会发生变化的控件----比如怪物头顶的血条和伤害跳字放在同一个Panle上，并且这些Panle上只有这些控件，其余基本不变的控件放在别的控件Panle上，这样两类控件就隔开到不同的DrawCall在不同的Panle中，当一个控件发生变化而导致DrawCall重建时，就不需要遍历那些没有变化的控件。因为在美术设计上，一段时间内在变化的控件总是少数，所以优化效果十分明显，节省的CPU占用率能达到25%。
优化锚点内部逻辑，使其只在必要时更新
在上一点优化了Panel的DrawCall重建效率之后，我们发现NGUI锚点自身的更新逻辑也会消耗不少CPU开销。即使是在控件静止不动的情况下，控件的锚点也会每帧更新（见UIWidget.OnUpdate函数），而且它的更新是递归式的，使CPU占用率更高。因此我们修改了NGUI的内部代码，使锚点只在必要时更新。一般只在控件初始化和屏幕大小发生变化时更新即可。不过这个优化的代价是控件的顶点位置发生变化的时候（比如控件在运动，或控件大小改变等），上层逻辑需要自己负责更新锚点。
降低贴图分辨率
这一招说白了其实就是减小贴图素材的尺寸。比如对一张在原画里尺寸是100x80的贴图，我们将它导入Unity后会把它缩小到50x40，即缩小两倍。游戏实际使用的是缩小后的贴图。不过这一招是必然会显著降低美术品质的，美术立马会发现画面变得更模糊，因此一般不到程序撑不住的时候不会采用。
界面的延迟加载和定时卸载
如果一些界面的重要性较低，并且不常被使用，可以等到界面需要打开显示的时候才从bundle加载资源，并且在关闭时将自己卸载出内存，或者等过一段时间再卸载。不过这个方法有两个代价：一是会影响体验，玩家要求打开界面时，界面的显示会有延迟；二是更容易出bug，上层写逻辑时要考虑异步情况，当程序员要访问一个界面时，这个界面未必会在内存里。因此目前为止我们仍未实施该方案。目前只是进入一个新场景时，卸载上一个场景用到但新场景不会用到的界面。
避免频繁调用GameObject.SetActive 我们游戏的某些逻辑会在一帧内频繁调用GameObject.SetActive，显示或隐藏一些对象，数量达到一百多次之多。这类操作的CPU开销很大（尤其是NGUI的UIWidget在激活的时候会做很多初始化工作），而且会触发大量GC。后来我们改变了显示和隐藏对象的方法——让对象一直保持激活状态（activeInHierarchy为true），而原来的SetActive(false)改为将对象移到屏幕外，SetActive(true)改为将对象移回屏幕内。这样性能就好多了。
NGUI性能消耗点汇总
使用LinkedList
BetterList是一个数组 LinkedList
NGUI节点查找非常耗时。
代码中非必要的堆分配
1)
我们应避免使用foreach循环 ：一般建议是避免使用foreach循环，尽量使用for或者while循环，我在Unity论坛遇到很多人提到这个建议。这背后的原因咋一看似乎是合理的，foreach只是语法封装，因为编译器处理代码的流程大体是下面这样：
foreach（SomeType s in someList）s.DoSomething（）;转换为：
using（SomeType.Enumerator enumerator = this.someList.GetEnumerator（））{
while（enumerator.MoveNext（））{
SomeType s =（SomeType）enumerator.Current;s.DoSomething（）;} } 每次使用foreach时 都会创建一个enumerator 对象，一个System.Collections.IEnumerator的接口实例。但是创建在堆栈上还是堆上是都可能的 几乎所有的System.Collections.Genric(list
2)应该避免使用闭包和LINQ吗？
匿名方法和lambda表达式会引起内存泄露吗？答案是：这取决于C#编译器，有两种区别很大的方式来处理
int result = 0;void Update（）{
for（int i = 0;i < 100;i++）{
System.Func
现在我们在托管定义方式上做一些小小的改变：
System.Func
通过把“p”替换为“i++”，我们已经局部定义方法转变成一个真的闭包（闭包是函数编程的一大支柱。它把数据和函数联系到一起，更准确的说是非局部变量在函数之外定义。）在myFunc中，p是一个局部变量但i是一个非局部变量，属于Update()方法。C#编译器现在不得不将myFunc转换成可访问、甚至是可修改，包含非局部变量的方法。它通过声明一个全新的类表示myFunc创建的引用来实现这一功能。For循环每次执行都要分配一个类的实例，瞬间产生大量的内存泄露（在我的电脑上每帧26KB）闭包概念在C#3.0 的时候被引入主要原因是LINQ。如果闭包回引起内存泄露
3)协程
通过StartCoroutine()运行一个协程，会隐式分配Unity Coroutine类（系统上占用21字节）和Enumerator(占用16个字节)，所以在游戏运行时尽量少用StartCoroutine()
4)字符串
C#和Unity内存问题必须会提到字符串。从内存角度，字符串很奇怪，因为，他们是堆分配且不变的。当你连接两个字符串时（无论是变量还是常量）：运行时不得不分配至少一个新的字符串对象存储新的结果。String.Concat()有效地通过调用FastAllocateString()分配新对象，但是必定会产生多余的堆分配（上面例子在我的系统上占用40字节）。如果你需要在运行时修改或者连接字符串，最好使用 System.Text.StringBuilder
5)装箱
尽量减少装箱
6)库方法
各种库方法也会隐式分配内存。捕捉它们最好的方法是分析。我之前已经写过的 foreach-循环，大多数标准泛型集合不会导致堆分配。Dictionary
查找堆分配的两种方式 1.使用Unity profiler 2.反编译自己的代码
在CIL中查找内存分配
CIL代码的优势在于堆分配代码不会被隐藏。相反，完全可以在反编译的代码中找到堆分配的三种指令。
1)
newobj
2)
newarr <元素类型>：在堆上创建一个数组。元素类型在参数中指定。
3)
box <值类型标记>：装箱（传递数据）专用指令，在第一部分已经介绍过。
Unity脚本执行顺序和编译顺序 1)脚本执行顺序
Unity 在后台会把每个脚本的 Awake、Start、Update、LateUpdate、FixedUpdate 等等，所有的方法合并到一起。然后按照 代码的执行顺序进行执行。
编译顺序
首先从脚本语言类型来看，Unity3d支持3种脚本语言，都会被编译成CLI的DLL 如果项目中包含有C#脚本，那么Unity3d会产生以Assembly-CSharp为前缀的工程，名字中包含”vs”的是产生给Vistual Studio使用的，不包含”vs”的是产生给MonoDevelop使用的。
对于每一种脚本语言，根据脚本放置的位置(其实也部分根据脚本的作用，比如编辑器扩展脚本，就必须放在Editor文件夹下)，Unity会生成4中后缀的工程。其中的firstpass表示先编译，Editor表示放在Editor文件夹下的脚本。
Assembly-CSharp-filepass-vs.csproj Assembly-CSharp-Editor-filepass-vs.csproj Assembly-CSharp-vs.csproj Assembly-CSharp-Editor-vs.csproj 根据官方的解释，它们的编译顺序如下：
(1)所有在Standard Assets、Pro Standard Assets或者Plugins文件夹中的脚本会产生一个Assembly-CSharp-filepass-vs.csproj文件，并且先编译；
(2)所有在Standard Assets/Editor、Pro Standard Assets/Editor或者Plugins/Editor文件夹中的脚本产生Assembly-CSharp-Editor-filepass-vs.csproj工程文件，接着编译；
(3)所有在Assets/Editor外面的，并且不在(1),(2)中的脚本文件(一般这些脚本就是我们自己写的非编辑器扩展脚本)会产生Assembly-CSharp-vs.csproj工程文件，被编译；
(4)所有在Assets/Editor中的脚本产生一个Assembly-CSharp-Editor-vs.csproj工程文件，被编译。
之所以按照这样建立工程并按此顺序编译，也是因为DLL间存在的依赖关系所决定的。好了，到此为止，我们可以很容易地判断出上面举的实例中，脚本的编译顺序(实际上，我已经把顺序写在了脚本的文件名中了)一个Unity3d的工程中，最多可以产生多少个工程文件呢？
4*3*2=24
4个文件 3中编译器 2种平台 1 个工程
IOS平台崩溃的几种情况。
1．在协程中要判断对象是不是为空(list GameObject)在每次调用的时候都学要调用（因 为协程不能保证即使调用如果对象已销毁但是依然使用时会卡死）。
2． Delegate的判断（IOS 尽量使Event）
3． 如果引用静态的static Compent的组件会出现卡死
4． Unity中的OnEnable Start Awake Disable Destory()都回延迟一帧 5． Unity在Ios对反射的支持不完整。
6． Awake 和Start函数执行时机, Awake 函数在这个脚本在场景中加载时就会调用，需要注意的是，Start函数也不是一定立即执行的，它是在该脚本第一次调用Update函数之前调用的，也就是说，如果这个脚本一开始的状态是disable的，那么直到它变成enable状态，在Update函数第一次执行前，才会执行Start函数。
7．Linq TO XML
untiy中配置文件需要注意的点：
pc端不区分文件大小写。
Andriod不区分大小写
Ios移动端区分文件大小写。
需要注意文件名称大小写。
资源优化(内存优化)：
1．代码中申请的内存，一般是New 或者Instantiate操作 Instantiate中也是调用了New 2．及时设置释放标识符 变量设置为Null 超出变量作用域 Destory()3．及时Gc释放内存 需要注意
Gc时会造成游戏短时间的卡顿，影响游戏体验 需要选择合适的时间Gc 4．尽可能的重用资源（贴图 材质 网格）
5．一般图片资源占用的内存最大，优化效果最明显（降低贴图分辨率，在效果和大小之间找一个平横点）
6．程序中的内存池 对象池 必要时主动释放内存
7．做AssetBundle资源的关系以来打包 动态加载
卸载
8．C#中Struct数据在栈上 Class在堆上 局部数据尽量用Struct 减少Gc的频率 9．按C++ 的思想来管理内存，比如使用的内存池，对象池 手工卸载 主动Gc 注意在内存和帧率之间做好平衡。
10．www 下载时需要注意变量声明和要注意申请的内存堆上的无用内存
11． Unity资源（加载/更新）
1.Resources
-打包集成到.asset文件里面及引用的资源as后se一个文件里面面可读不可写无
-只能用WWW类下载
StreamingAssets文件夹也是一个只读的文件夹，但是它和Resources有点区别，Resources文件夹下的资源会进行一次压缩，而且也会加密，不使用点特殊办法是拿不到原始资源的。但是StreamingAssets文件夹就不一样了，它下面的所有资源不会被加密，然后是原封不动的打包到发布包中，这样很容易就拿到 里面的文件。所以StreamingAssets适合放一些二进制文件，而Resources更适合放一些GameObject和Object文件。StreamingAssets 只能用过www类来读取。
最后凡是在Hierarchy视图对象引用过的资源文件也会被无条件打包到发布包中。如果有一部分文件可能没有在Resources文件 夹下也没有在StreamingAssets文件夹下，也没有被Hierarchy视图游戏对象引用，那么这类资源是不会被打包到发布包中的。
3.PersistentDataPath无
-清除手机缓存文件会一并清理这里的东西
-随意弄，可作为本地目录让WWW下载、也可以自己用FileInfo乱整
4.WWW.LoadFromCacheOrDownload
Unity常用目录对应的Android && iOS平台地址
IOS:
Application.dataPath : Application/xxxxx/xxx.app/Data Application.streamingAssetsPath : Application/xxxxx/xxx.app/Data/Raw Application.persistentDataPath : Application/xxxxx/Documents Application.temporaryCachePath : Application/xxxxx/Library/Caches
Android:
Application.dataPath : /data/app/xxx.xxx.xxx.apk Application.streamingAssetsPath : jar:file:///data/app/xxx.xxx.xxx.apk/!/assets Application.persistentDataPath : /data/data/xxx.xxx.xxx/files Application.temporaryCachePath : /data/data/xxx.xxx.xxx/cache
Unity的Android和IOS上相关的目录结构
Android:
-assets 游戏内容相关的都在这里了res 图标之类的
-AndroidManifest.xml Android配置文件resources.arsc Java编译后的二进制文件
IOS:
-level0/level1… Scene
-sharedassets0/shaedassets1/… Scene相关的东西resources.assets Resources里面的东西-Raw StreamingAssets里面的东西
第四篇：Hamlet --- The unity of controverasal
Hamlet
---The combination of contradiction
As the saying goes, one thousand readers, there are one thousand Hamlets.Others may think he is a soldier, a hero or a thinker.However, in my mind, he is an immature teen-age youth who is the combination of contradictions.Firstly, as a prince, he is an idealist.He lives a luxurious life and is educated by humanism.Without knowing the dark aspects of the society, he is favored by his parents and respected by his people.We can see in the play that he believes the true, the good and the beautiful and he is a real perfectionist, which can also explain why he is so shocked by the things happen on him and doesn’t know how to deal with it perfectly.Experiencing the death of his father, the usurping the throne of his uncle and the remarriage of his mother, Hamlet’s dream turns into bubbles.He falls in to hell from the heaven and goes on the trip of revenge.The prince has to have common people’s feeling, sadness, hatred, disappointment, hypocrisy and so on.Secondly, he is definitely a great thinker but also an ordinary people who hesitates to practice his thought.He begins consider himself and his people after he listen to his dead Father King’s words.He even says “To be or not to be, this is a question: was bear the slings and arrows of outrageous fortune, or to take arms against a sea of troubles world, through the clearing their struggle, these two kinds of behavior, which is a more noble.” He falls in to deep thought and condemns himself.His father is murdered and the ghost of his father urges him to take the revenge.He doesn’t do anything.He wonders: how a coward or a indecent woman I am.He not only thinks of his own fate, but also considers everyone’s existence.There is no doubt that he is the great man of mind.“Now I clearly have reason, have the determination and have the strength, have a way of can start to do what I have to do, but I still in touted said: 'it needs to do.'But never expressed in action…” is the evidence for his hesitation.When his enemy is praying and he plans to kill him, he should consider that killing a man who is praying will allows him to go to haven, which makes him lose the chance to kill his uncle and commit the tragedy.Thirdly, he believes the true, the good and the beautiful, but he doesn’t believe his friends and his lover.It is his behavior that makes Ophelia dead.He pretends to be mad and kill her father by accident.Ophelia can’t bear the reality and goes to the place where she dates with her prince madly… His ignorance of others’ care and arrogance kill other four innocent people.Last but not least, he is the combination of the goodness and evil.On the one hand, he is pious to his parents, his girlfriend and his friends in a way.He bears the responsibility to take revenge on his uncle and to save the ordinary people.He tries his best to satisfy everyone but he also hurts many people.He takes his revenge on his uncle by hook or by crook.He kills Rosencrantz and Guildenstern.He is cold when he kills Polonius and heartless to Ophelia.Not merely does he lead to his own tragedy, but also leads to the whole play’s tragedy.All in all, the dejected prince wants to take revenge on his uncle, but he can’t find a proper way and his ability is not equal to his ambition.He is an idealist who has to face the cruel reality.As a great think who believes the true, the good and the beautiful, he hesitates to take the action and doubt everyone around him.He is the saver and also the destroyer.He is a giant and also an ordinary people.He is a noble prince and also an immature teen-age youth.
第五篇：管理信息系统五种开发方法优缺点评析
管理信息系统的五种常见开发方法及其优缺点阐述
1.把系统的建立看作是一种生命物种的成长过程。由6个开发阶段组成：系统定义-> 需求分析-> 系统设计-> 编写代码-> 安装调试-> 系统维护 优点：
这种开发方法把管理信息系统开发的全过程按其生存周期分成若干阶段，每个阶段有相对独立的任务，然后逐步完成各个阶段的任务。在每一阶段的开始与结束都规定了严格的标准。前一个阶段的结束标准就是后—阶段开始的标准，而每个阶段任务相对独立而且比较简单，便于不同人员分工协作，从而降低了整个软件工程开发的困难程度。在软件生命周期的每个阶段都采用科学管理和良好的技术方法，而且在每个阶段结束之前都从技术与管理两个角度进行严格审查，合格之后才开始下一阶段工作。这就使得软件开发全过程以一种有条不紊的方式进行，保证了软件质量，提高了软件的可维护性。这样不仅可以大大提高软件开发的成功率，软件开发的生产率也会明显地提高。且简单明了，结构清晰。
同时把文档资料作为每个阶段的产品之一，而且加以标准化，作为每个阶段结束的重要标准。它保证了在系统开发结束时有一个完整准确的软件配置交付使用。文档资料是通讯的工具，它清楚地说明了到这个时候为止关于该项工程已经知道或做了什么，同时确定了下一步的工作基础。文档资料也起着备忘录的作用，如果文档不完整或与上一阶段的文档不相衔接则一定在工作上有不完整的地方。文档资料另一重要作用是有利于与用户交流，检查错误，用户评价。文档资料也是系统维护的依据，通过每一阶段生成的文档资料，使得开发人员和用户易于使用维护。不足：
这种开发方法的不足具体表现在以下几方面
第一，阶段回溯不可避免，延长系统开发的时间。结构化生命周期法并没有解决软件开发研制时间过长的严重危机，在计算机硬软件技术相通讯技术日新月异发展的时代，很容易使刚建立起来的管理信息系统迅速变得陈旧，生命周期很短，所以系统开发周期过长将导致系统运行时间变短。
第二，使用过程化语言，没有以根本上改变个体手工编程的工作方式。
第三，专业开发人员开发用户使用的系统开发模式，开发人员与用户都要化时间去掌握对方专业领域的知识以期产生共同语言，导致用户系统分析不充分，理解不透彻，或表达的二义性，造成软件生命周期中越早潜入的错误发现越晚，系统分析时引入的错误往往要到运行时才发现，其修正的代价是相当昂贵的。
第四，用户热情没有自始至终调动，不能从根本上解决让用户参加系统开发的问题。系统维护就十分困难。且文档资料缺乏实用价值，特别是早期的系统规格说明——专业知识的缺乏使得用户难以理解文档的内容，文档资料没有起到应有的作用，反而延长了开发时间。
2.：
快速地创建出管理信息系统的测试版(可用来演示和评估),借助这种测试版本挖掘用户的需求，然后在此版本的基本上进修改、增强。由4个开发阶段组成: 确认基本需求-> 开发原型系统-> 使用原型系统 <-> 修改增强原型 优点：
快速原型法突出一个“快”字，采用结构化生命周期法作系统分析时要反复和用户讨论，这种讨论费时费力，而且终究是“纸上谈兵”，原型法则是“真枪实弹”，能够使用户立刻与想象中的目标系统作出比较。开发人员向用户提供一个“样品”，用户迅速向开发人员作出反馈，提高系统的质量，快速原型法要求在获得一组基本的用户需求后，快速地实现新系统的一个“原型”，可以说是以用户需求为中心，又不完全依赖于用户需求，它对用户需求的定义采用启发的方式，引导用户在对系统逐渐加深理解的过程中作出响应，鼓励用户参与到系
统的设定与开发中去，更加便于系统的维护和使用。不足：
快速原型法，虽然能够积极调动用户参与到系统开发与设计中去，但起局限性在于，只能适用于中小型企业的管理信息系统开发，而大型企业，管理信息系统本身十分复杂，各种不确定性因素多变，对那些简单的数据操作和记录管理的应用比较适合用原型法开发。而对那些批处理或大量计算和有着复杂过程逻辑的系统一般不适合用原型法处理。原型法更适合较小的应用开发，对大型系统就须分成几部分，一部分一部分地分别建立原型。如果缺乏用传统方法进行透彻的需求分析，就无法对大型系统进行划分，因为一开始很难分辨系统各部分之间存在哪些相互的影响。如果冒昧使用快速原型法，会导致管理信息系统出现漏洞。
3.应用软件包法：
通过购买商品化软件包并在此基本上进行系统的开发方法。由4个阶段组成：系统分析-> 系统设计-> 系统修正->系统维护 优点：
从软件包开发者手中直接购买企业需要的应用软件包，市场出售的应用软件包非常多而且应用范围广，可以给企业管理者更多的选择，使用商业化的应用软件包就不必自己再编写程序或者只需写少量的程序，因此可以说省时又省力，且效果立竿见影。不足：
应用软件包法虽然方便，但是同样需要系统分析，设计，测试，转换和维护等开发过程，而且由于此种方法是购买商业软件包，因此导致企业内部专业人员无法参与到系统开发中去，容易受制于软件开发者，它不是一个完全独立的系统，不易维护，不易更新，更不易于修改。而且软件包是基于商业化开发的，软件包不可能满足一个组织的全部需求，相对来说，它更适用于所有组织中比较通用的一些需求。为了使其市场最有吸引力，软件包力求满足所有组织最共同的需求。势必不能完全适应于企业方方面面的实际情况。企业如想进一步改进系统，需要投入一部分的额外资金培养人才。
用户自己采用开发工具开发自己需要的各种系统。由3个阶段组成一个循环开发过程： 系统分析-> 系统开发-> 系统维护->回到系统分析 优点：
这种方法的优点在于克服了应用软件包法开发系统时企业无法自主的不足，由企业的开发人员根据企业的实际需要去开发和维护管理信息系统，可以适应企业的实际情况，用户对自己设计和开发的系统更容易接受并乐于使用，对应变突发事件有好处，同时通过重复分析、开发 维护、再分析的几个步骤，可以加深企业工作人员对管理信息系统的认识和理解，这样有利于系统的开发和维护。而且由于开发系统的责任由信息系统专业人员转给了最终用户，所以用户开发的系统有助于减少应用系统后备资源。不足：
第一，由于缺乏规范的信息系统分析，用户开发的应用系统就缺乏独立的外部评审，缺乏独立的问题分析或可选方案的来源，用户就很难完整并全面地说明其需求。
第二，由企业内部人员自主开发管理信息系统，由于企业从业人员的专业水平参差不齐，且开发的系统常常快速地建立，没有一套正规的开发方法，这类系统往往缺乏适当的标准、控制和质量保障过程，可能也没有用于测试和提交文档的规范。用户开发的系统还可能缺乏对输入和更新审计记录的完整性及合法性的控制，缺乏操作控制、目标控制和各子系统之间稳定的接口标准的控制。
第三，数据难以控制。
第四，用户能用开发工具建立自己专用的“私用”信息系统，这类系统可对组织的其他成员隐蔽一些信息。一旦系统的开发者离开其岗位，这种非文档化的私用系统将无法容易地移交
给他人使用。
5.将所需要的系统，委托企业外部的人员或组织进行开发。它只是一种信 息系统开发策略，这些开发依然要选择如何使用前面4种开发方法。由3个阶段组成：用户需求-> 外包信息系统-> 最终系统 优点：
在经济方面，由于负责系统开发服务的外部开发商是信息系统服务和技术方面的专家，所以靠专业化和规模经济，他们能以低于内部成本的费用向组织提供同样的服务和价值。服务质量方面，因为一旦外部开发商提供的服务不够满意，那么他将会失去自己的客户，所以企业对外部开发商的影响比对自己员工的影响更大。从而使企业能以较低的成本从开发商那里获得高质量的服务。再一点，由于企业与外部开发商事先针对不同层次的服务所对应的费用进行了签约，因此可大大减少成本的不确定性。外包信息系统具备一定的灵活性，在组织的信息系统基础设施不发生重大变化的情况下，能适应业务量的增长。当信息技术渗透整个企业价值链时，由于成本和性能可按变化的需求不断进行调整，所以外部开发商可提供较强的业务控制和适应能力。外包信息系统同时也可以解放人力资源，将较少且昂贵的高层次人才集中到具有较高价值和回报的活动中。不足：
第一，失控：当一个企业将开发、运行其信息系统的责任承包给另一个组织时，它可能失去对信息系统职能的控制。如果开发商成为企业运行和开发信息系统的惟一选择，那么企业将不得不接受开发商所提供的任何技术，这种从属关系最终将导致产生较高的成本，并可能失去对技术管理的控制。
第二，战略信息易损：由于企业信息系统由外部人员运行、开发，所以商业秘密或业主信息可能会泄漏给竞争对手；若允许外部开发者开发或操作使企业具有竞争优势的应用系统，那将更有害。
第三，依赖性：企业会随开发商对企业信息系统的开发、运作而变得对开发商的生存能力更加依赖，那么开发商的财政问题或服务上的衰减都可能对企业产生严重的影响。
点击咨询 