卡顿问题的处理
- 如果玩家触发卡顿，先上传这个玩家的log，看他的帧率，然后定位帧率低的时间玩家做了什么操作。
- 如果是能复现的卡顿，执行profile（用于记录一帧所有函数的执行时间），复现卡顿，然后根据profile结果进行分析。
- 如果是帧率没有突变的地方，是一直都很低，则优先确定是否有定时器使用不当。
- 如果是以前没有卡顿，最近才出现的卡顿，可以查svn记录，看最近改动的内容。
游戏相关算法
- 分离轴算法：用于实现多边形碰撞检测（引擎自带的碰撞检测效率低，并且对于速度过快物体会出现穿透现象）
- 碰撞检测将物体分为N叉树：一个场景有很多碰撞体，但是不可能让所有物体两两进行碰撞检测，因此需要把场景的物体按N叉树划分开来，这样可以减少碰撞检测的次数。
- 基于有向距离场（SDF）地图碰撞系统：类似于王者荣耀那种物理移动效果的实现。一般开发时，不会使用unity自带的物理碰撞系统（因为不可控并且效率低）。
- Two-pass跳到最大联通区域算法：一般用于随机生成迷宫的游戏，迷宫会有阻挡，为了避免玩家卡在阻挡位置，因此需要用这个算法让玩家跳到最大联通区域。
- 时间轮算法：一般用于定时器的实现。我们每新建一个定时器，都需要放入一个列表中，然后每帧计算哪些定时器需要执行。如果通过遍历所有定时器的方式来确认哪些定时器需要执行，那么效率太低了。而使用时间轮算法就可以不遍历定时器就能获取那些定时器需要执行。
- A*寻路算法：自动寻路AI，主角寻路到NPC必不可少的算法。
- 射线检测算法：射击游戏、某些碰撞检测、各种图形学算法等地方都会用到。
- RVO避障算法：用于避免多个角色重叠一起。
游戏相关性能优化常用手段
- 闲时加载（异步加载）：当一帧的逻辑过多时，把部分可以延迟执行的逻辑放到空闲的帧执行，避免卡顿。
- 场景分块加载：对于大场景，进入游戏是不会把整个场景所有物体都加载进来的，而是根据玩家当前位置，选择附近的物体加载。
- 遮挡剔除：当多个物体发生重叠时，玩家实际上能看到的只有最前面的物体，后面被遮挡的物体是看不到的，这个时候就可以把那些被遮挡的物体剔除，提高运行效率。
- 协议管理：对服务端返回的协议进行管理，对于不需要立刻执行的协议，可以使用闲时加载的方式来执行（处理不好容易出各种bug）。
- 合图、合批：一个界面有多个图片，我们如果一张图一张图的读取，那么cpu和gpu的交互次数会很多。但是如果把多个图片合成为一张图，那么cpu和gpu就只需要交互一次（当然这不一定一次，主要看合图是否包含所有图片），就可以把所有的图片都读取到。同理，针对3D模型网格的合批也是这个意思。
- 对象池：每次实例化一个对象，都会有较大的消耗，因此需要使用对象池，对于反复创建的对象，销毁时不真正的销毁（仅隐藏对象）而是放入池中，当再次需要使用的时候，直接从池里获取。
- 复用滚动框（滚动视图）：一般我们看到的滚动框都是复用滚动框，就是说滚动框里的Item的个数实际上是只显示我们看到的那么多个，并不是有多少个条目就有多少个Item。
- 预加载：对于一些资源加载时可能比较耗时，容易在触发时造成卡顿（例如一个华丽的技能，释放的时候加载很多特性导致卡顿），那么可以提前加载好，然后隐藏。需要的时候直接显示。
- GPU Instancing：对于相同的网格，假如要渲染1w个，那么就需要向GPU传1w次数据。如果使用合批，那么只需要传1次数据，但是传的数据量不变还是1w条数据。但是这1w条数据是一样的，所有完全可以传1条数据给GPU，然后GPU直接渲染1w个出来即可。
内存优化手段
- 触发内存预警时，自动清理掉部分资源缓存。（主要是纹理，也就是图片）
- 资源引用为0时，立刻清理掉资源。（但是这个资源可能很快又用到，需要根据情况来选择处理方式）
- 尽可能减少粒子数量。
调试手段
- 进游戏就黑屏，那就看本地的log文件。
- Ios可以通过爱思软件看log文件。
- 安卓可以直接连接adb查看游戏的实时log。
- 本地调试真机代码的时候，可以直接用热更替换的方式进行调试。（因为改一次代码就打一次包或者补丁太慢了，直接热更调试快一些）
- 对于收到热更代码前的调试（热更代码是服务端下发的，这里指服务端下发热更代码前），可以在游戏进入的时候，默认读取本地的一段代码文本直接执行。
- Shader执行的时候没法加打印，如果想看数据可以用因特尔gpa查看。
调试技巧
- 最直接的就是加打印看一个函数是否被调用，还有执行到这里时的数值。
- 要定位一个功能的代码，可以先触发这个功能，然后看多了哪些打印，接着通过console选中打印往回追溯，就可以定位到触发这个功能的时候相关的代码走向。（类似断点，但是断点会把进程卡主，并且执行下一断点后，无法跳回去前一个断点查看）
- 对于没有打印的功能，要先联想他最终结果的涉及的一些功能，例如npc走路的函数我不知道是在哪里，但是我知道它最终结果是npc走路，也就是必定会对npc执行SetPos函数，那我就可以重写它的SetPos函数，并加上打印，然后就可以通过console反查npc走路是怎么执行下来的。
- 定位一些界面所在的代码位置时，可以直接ctrl+鼠标左键点击界面跳转到该界面对应的代码。（这个功能是自己实现的，其实只要监听点击，然后获取点击到的界面对象，就可以获取到这个对象的类，然后直接跳转ide）
- 对于打印过多，但是只想分析一个对象时，可以设置符合这个对象的数据才打印。
- 加打印可以多加一些显眼的字母，方便我们找到自己的打印。（可以用console过滤）
其他问题
- ios无端端杀进程，一般是游戏内存占用过高。
- Pc上没问题，真机有问题，可以检查补丁是否包含修改内容，还有逻辑是否有环境判断。
- 安卓没问题，ios有问题（或者安卓有问题，ios没问题），这种一般是资源问题较多，需要检查一下各个平台读取的资源是否一致，还要检查云效自动化生成的资源是否有问题。
- 不稳定的功能外放的时候，可以选择随机一定概率做灰度测试，这样就算出问题，玩家只要重登就有一定几率切换回正常的状态。
- 外挂检测不应该检测出来就直接封号，检测出来之后应该推迟几天再封，这样让外挂制作人不方便调试。
- 一个界面第一次打开不显示某图片，第二次打开正常显示，这种一般是异步加载导致的。异步加载资源加载完成之后没有设置回去或者还没加载完就调用设置函数。
- 一个界面打开之后无法关闭，这种一般是界面的引用出问题，没有把引用归0导致的。
- 游戏内存占用十分高，这一般是某些资源循环引用或者引擎打印了大量错误提示导致的。
- GPU Instancing要求网格相同，相当于一份网格数据给到GPU绘制多次。合批不要求网格相同，他是把所有网格数据汇总起来一次性发给GPU，让GPU绘制。
- 存在存盘的操作的函数必须要容错，因为总有部分用户的设备存盘的时候会出现异常。
坛友补充
- 闪退问题优先从原生代码层去寻找问题，一般js层代码不会出现闪退问题
- LOD（Level of Detail，多细节层次技术）：根据距离判断显示高模、中模、低模。内存换性能。例如远景可以换低模减少内存占用，靠近再换上高模，提高模型精细度。
- 脏标识模式：代码可以通过标记避开无需计算的部分。用于判断数据是否有更新，打上脏标记的数据需要重新计算更新，没有则不需要重新计算。
- 各种排序：排序用途很广，一般不追求性能直接用js自带的即可。如果追求性能，那就需要根据场景挑选不同排序算法，例如：堆排序、冒泡排序、快速排序等。
- 寻路算法预计算：寻路算法是比较耗性能的，可以预先把点位生成出来预先计算好，这样寻路的时候就不需要执行寻路算法，而是直接获取到寻路结果。
- 自动化工作流：对于一些繁琐重复的工作可以自动化，提高工作效率。例如：excel转json、预制体节点获取代码自动生成等（推荐用python实现，python自动化工作流比较强）
- 没有透明通道的图片用jpg，常用字体可以使用BMFont、图片来代替，sprite相对友好一点。
- 内存越来越大也可以打快照（如谷歌的memory），可以看到有多少个占用。比如怀疑A弹窗没销毁，就打开前和关闭后分别快照，看是否残留。
- 对于console打印，可以封装多一层，读取当前设置为调试模式、日志模式、警告模式对应打印哪些，可避免打印太多或去除上线打印
- 不要相信策划的誓言（例如：这个功能绝对不会改，写死就行），永远要考虑程序的拓展性。
- 保留好策划文档细节，方便日后定位问题、理解需求，还有预防对方甩锅。
- 问题调试永远是编辑器最方便，策划、测试如果能复现问题最好也是用编辑器复现调试。
- 预制体如果比较简单，可以直接用代码创建，可以减少包体大小，并且不需要加载。
- tween不擅长处理会被中途打断的动画，角色的移动、或者是可能暂停的动效，一般根据距离、速度计算好总时间，在update里面根据时间进度来做移动。
还有什么开发经验、常见问题的处理方法、常用算法等，欢迎大家补充！
个人联系方式：
