在已经过去的两个月中花了3周，总结了下龙2中的优化内容，目标是为了新的项目做前期的规划；涉及相关的项目中细节内容，不详说，说下哪些可以规避的问题

一.工具类开发

1.查找重复或冗余未使用的资源
2.查找超过1024尺寸的图片工具并加入每日检查
3.添加对于资源检查的工具
对于美术资源的检测，对于资源的规范性的检测，可以减少一些资源是否合理的检测代码。

一.什么是钩子函数？

先来看一段百科：钩子函数是Windows消息处理机制的一部分，通过设置“钩子”，应用程序可以在系统级对所有消息、事件进行过滤，访问在正常情况下无法访问的消息。钩子的本质是一段用以处理系统消息的程序，通过系统调用，把它挂入系统。

早上在翻个人博客文件夹的时候，发现这篇18年10月30日写完的，再去翻了个人博客里，确实没发出来。随便把当时写的手稿也发上来。

游戏同步：帧同步和状态同步

帧同步：服务器负责转化客户端的操作，每个客户端在固定的逻辑帧执行该帧所有客户端的操作命令，通过在严格一致的时间轴上执行同样的命令序列得到同样的结果。主流的老牌RTS游戏都是帧同步：星际争霸、war3

状态同步：服务器承载所有计算，客户端只做表现。主流的大型MMO游戏都采用状态同步。

一时兴起，写了这一篇文章。在实际开发中为了更好的表现，需要在一段动画播放后，再做别的行为

这篇文章3月6日开始定题，3月22日写完初稿，5月4日再补充一点，今天发布。

一.不同的动画组件

1. 动画美术直接编辑动画，定位到要变化挂点的帧（比如24帧），在Events里添加一个动画事件， 名字规范成 TakeWeapon

这个方案

优：让美术准确控制帧数， 可以个性化
劣：所有模型该动作都要加一下。

目前在做其他项目，之前维护接近一个月的逻辑工程，觉得写点什么才能对的起这段时光。当然来说，我也觉得做的不够好。既有经验的问题，也有在思考需求的不明确。在时间紧迫情况下，会有动作变形。

一.接手前的状况

客户端主要逻辑逻辑是使用C#写，但是逻辑工程是把客户端中抽出了一些逻辑部分的内容，2月份才开始做了第一版本。当时已经到4月低的版本，中间更新能编译成功，但不清楚是否有效。

我接手的时候已经到6月初了。当时7月给腾讯的版本中，有一项内容是战后做逻辑验证。逻辑工程要保持更新到最新，要在服务端可以启用。

之前项目的主程说优化口诀，优化就三样。算法优化，把CPU的事情放到GPU,都不行了就开多线程干。
经历目前这个项目的优化，加上看了一些UWA的文章。

一.优化的目的

对程序员来说，提高“性能”；性能是关于计算机所需花费的时间和内存空间占用，宏观上保持保持每一帧的流畅，最终目标是对给player优质的体验。
对于Ta和美术-自由发挥艺术设计的“空间”。 最终目标就是给Player视觉上“炫炫炫”。
对于运营和发行来说，就是更多地玩家同屏人数，服务器可承载更多的玩家。对于初始包体要很小。

二.优化的背后知识体系

基础图形原理
计算机常用的算法和数据结构
对移动平台的硬件有充分了解（CPU，GPU，内存，I/O…）
对Unity在Mobile Device上的.net实现环境有所了解（mono or il2cpp)

三.优化的效果指标

详细可以看到wetest给予各项指标图，wetest的unity深度测试。

四.优化的工具

• wetest
• uwa got tool
• Profiler
• Memory Profiler
• Mali Graphics Debugger(基于Arm显卡的工具)
• Snapdragon Profiler

  五.优化是一件坚持记录和对比的过程

  优化是可以看到这个团队在配合程度，只有前期很好制定了美术资源在不同的级别制作标准，才能在后期适配更多的手机。
  记录当前版本的问题，毕竟改进的后数据记录。很多团队都选择用Excel来做记录。

项目是用帧同步做的项目，之前做了一点战斗相关的功能，对于帧同步有一些认识。

一.宝箱对应的标识并没有消失

详细内容：接手新的空投改版任务，修改一个版本结束后，一直报第一圈第一个宝箱开启，场景中的模型消失，但对应的UI层的标识没有消失。

跟着下来是FixVec3转Vector3,再转FixVec3。数值已经和之前的完全不一样的。

反思为嘛之前没有出现转换出现的这样的问题，之前设计是方形的作为基本使用，当然数值上也是加上一个整数。

现在引入扇形，需要进行正弦余弦计算，小数点后保留6位，在转换后出现数值差异。以上图可见第3位上出现数值不同。

思考，是否可以避免使用FixVec3作为key，看了之前的代码确实难以改动。解决方案就是在原来类中加FixVec3存一份作为key值使用。

二.空投的模型，有莫名消失

详细内容：一直觉得是UI上没清理对应的标识，觉得是AOI管理上，把对应的模型删除，但是没有确认。和做AOI模块的同事沟通，也觉得不受影响。后来在空投箱子销毁的地方加Log，看了下调用栈，确实在视野处理的时候，把空投宝箱的模型删除了。在加了空投宝箱的标识后，问题修复了。

当初设计空投宝箱的时候，AOI并没有使用，后来处理视野里可以见得内容，并没有把空投宝箱算进去

三.总结反思

1.测试功能，没想清楚，明明可以改配置，快速测试，实际花了很多时间在等待过程。
2.因为是接手别人的功能修改，加宏看log,但是他个人的log代码，没有提交，自己打log重新看，比较聪明的做法是直接要一份他的log代码
3.和策划沟通，需要二次确认，有时策划听内容的时候，但是有没有认真听，很难确定，后期修改的，幸好代码基本没啥改动量。
4.关于帧同步的项目做视图和逻辑分离，注意一些数值转换后并不能再使用了。
5.如果新的功能开发，还是需要去沟通是否影响现有功能的内容。AOI管理了场景中的实体，空投的实体并没有被管理到。在处理的时候就删除了。

接到的任务需求是在将3d模型的内容在UI上显示

前言

梳理了目前有3个种方式，当然没有好坏之分，只有合适与否。在开源项目中SomeTips的Scenes文件夹中,加入3DUIWayNo1-3的场景，看到以上的实现方式。

UI和场景的混合实现

Camer是skyBox直接与UI混合。如果在放在UI节点下，因为在同一层级下，通过控制Z值设置前后的关系。

RenderTexture

使用Rendertexur,Camera单独照模型，摄像机的内容放到RenderTexure,在UI界面上放入Raw Image。要设置渲染层都为RenderTexture。
renderTexture的方式，可以满足在两个不同的层级之间的需求。问题是美术效果上，需求要对于效果做shader上处理。用Camera和原来的在Camer下有色差，以及如果涉及粒子特效。粒子的效果的衰减。也有研究自己写shader解决Alpha的问题。

原因在于默认的粒子效果使用到的shader中使用了ColorMask RGB,所以只有RGB三个通道的值被存入了缓冲，而没有写入A通道的值, 所以我们得到的texture其实没有粒子的alpha信息，由於使用了ZWrite Off,所以也沒有粒子的深度信息，当我们把这张纹理拿出来显示的时候，由于某些粒子所在位置alpha值为0，所以通过alpha预存得到的RGBA值是（0, 0, 0, 0），所以最后也就看不到颜色了。

对用的解决办法是将shader中的ColorMask RGB改为ColorMask RGBA，写入粒子的alpha信息就行了。

Camera混合

使用多个摄像机混合，但要同时要求Camera都是深度模式，需要脚本去改变camera的depth值。另外渲染的camera的depeth要大于UICamera的。好处在于用的时候加载，在不用的时候就卸载了。方便自己的管理。

总结

自己项目中选择第三种，原因是在需要在不同的场景下打开，如果是美术效果最好，当然是单独场景最好。而且背景上有更大的美术发挥空间。问题在于场景Loading会有点奇怪，不合乎策划设计的初衷，体验上有转场的感受。
研究了下守望先锋的宝箱，其实在同一个场景里，切到了场景某个点，进行操作的，没有加载的过程。如果在场景某个点作为开启的位置，目前多个场景都要处理。带来更多的美术工作量。后期需要美术管理反而变多了。

这一篇文章是3月初开始写的初稿的，在听了公司邀请Wwise的人来演讲后，继续完善这篇文章。首发于(http:zhutaorun.win)

一.为什么使用第三的插件

• 因为unity本身做的音效系统做的不够好，对于了很多的声音效果确实没办法满足，需要更多复杂的效果原生满足不了
• 因为第三插件，让程序与音效师之间的配合更方便多了，原来的合作方式是程序需要很多的工作，而音效师能够发挥的空间有限，准确的说，Wwise提供了一套音效师与程序配合的流程
• 方案成熟，以Wwise为例，从事音效这块很多年，2000年公司成立，到2015年王者荣耀使用，很多项目选择使用，端游守望先锋

4月21和22日在青松城酒店，参加uwa的大会。

前言

uwa作为在unity优化方向的专业团队，在支持各个公司的产品优化的基础上，也等到了一些很有意思的内容。

目前在使用uwa的unity版本分布情况，目前主要使用的版本还是5.3-5.6居多
还有游戏类型也有不同的变化，有卡牌三消=》arpg=》moba=》沙盒游戏（吃鸡等等）