上周末，极光网络赞助的第一期“极光客厅”正式开门迎客。在这个时候“2D小游戏开发实战技术沙龙”上，极光网络客户经理陈策、极光网络项目总监陈远与与会者分享“大型H5如何登录微信游戏”以及“游戏性能优化”大量R&D干货。
以下是两位嘉宾的干货安排：
陈策:大型H5如何登录微信游戏
随着公司业务的发展，我们的项目经常要落地各种平台，微信游戏就是这些平台中的一个。
微信游戏是微信小程序的一个类别，这是点击播放，无需下载安装，体验轻松，可以和微信里的朋友一起玩，比如PK，围观等。
但是我想让我的游戏登陆微信游戏，会有一些限制，下面主要说一下《大天使之剑H5》该项目落地微信游戏的主要局限及解决方案。
一、《大天使之剑H5》主要受微信游戏限制
1.所有分包规模不得超过8M：分包是指微信开发工具中上传的所有资源，包括JS代码和资源，总计不得大于8M；
2.单个包的大小不得大于4M：在上传的文件中，不能超过4M的文件；
3.JS必须将其置于分包合同中，然后才能运行，装入JS文件将仅被视为文本：加载JS文本，无法转换为可执行脚本。
《大天使之剑H5》在登录微信游戏之前，整个项目规模约为400多M，光JS代码部分大约有10M。除逻辑代码以外的其他资源（图片、音效、配置等），可以在游戏运行的时候加载，不要在开发工具里上传，但约10M的JS所有代码部分都必须上传。因此，《大天使之剑H5》想登录微信游戏，必须减少JS代码的大小。
二、现有压缩工具UglifyJS一些函数的介绍
Layabox在引擎中AS3部分世代JS将被优化，该功能应基于UglifyJS去实现。优化内容主要包括：
1.从代码中删除无效的空白字符
2.从代码中移除注释
如图所示：
3.缩短方法中的局部变量名
如图所示：
4.代码格式优化 （将代码改为更节省字符的方式）
如图所示：
5.压缩属性名 （默认情况下不打开）
我们先来看这个例子，这是一门课，在工具默认情况下不打开压缩属性名称时，在示例中，该工具将仅按压两个橙色点X和Y，因为这是一个参数，也就是刚刚提到的方法中定义的变量，this.x,this.y这个不急，因为这是属性名。如果类名Point，方法名setTo，属性名X，Y压了，然后其他使用的地方也要一起换，如果代码中调用了反射，那就不能叫了。所以压缩这些名字是有风险的，这就是为什么默认不按工具的原因。那么该功能就没用了？不会，该工具还提供了许多参数，以便您可以设置未压缩名称的列表，正则表达式也允许你定义压缩的名字等等，其实还可以用，还是说你只需要先为你自己的项目想出一个名字数据，编译后的未压缩名称集应该与代码同步维护，这将更加困难，所以《大天使之剑H5》项目中不使用此功能。
小结：
《大天使之剑H5》现有项目AS3代码输入Layabox生成JS代码时，上面提到的前四个优化点已经默认执行：
- 从代码中移除无效的空白字符
- 从代码中移除注释
- 方法中局部变量名的缩短
- 代码格式优化
但是生成的JS代码有10M左右，还没达到微信游戏的要求，因此，为了减少代码量，我们需要更多地了解我们的AS3再做一些代码优化，从而减少代码量。
三、减少程序代码
减少代码量，最直接的方法就是减少代码中的字符，这部分是优化的，它在我们的项目中AS3代码部分的优化，这些优化包括以下内容：
1.将接口布局的数据更改为外部加载
Layabox的UI编辑后，会生成相应的UI类文件，其内容如图所示：
这里的主要内容是UI布局数据，不涉及逻辑，可以提取。另存为文本文件，当其对应的接口初始化时重新加载，在Layabox中，我们可以修改它UI来调整模式：
我们可以随意创造一个UI去做测试，如图所示：
我们可以看到，创建一个新的TestPageUI界面，使用嵌入式模式生成TestPageUI.as文件共享3283字节，使用拆分模式时，生成的文件只有579字节。图中右侧的绿色部分显示了代码的减法部分，为我们缩小合同范围80%左右的UI相关布局代码。
而在《大天使之剑H5》中，UI该布局目前有931个，使用这种方法帮助我们减少了1.8M的代码。
2.删除类中未使用的导入
当我们发展的时候，手误import中输入的某些项目不使用的类，需要这些吗import删除。如：import Sprite3D 类，2D游戏没用3D相关的事情，不需要导入。
3.将在方法中this替换为局部变量
成为我们的AS3代码转换JS后，方法中类的属性名的访问形式，将在之前this. 这里的this能减少吗？如下图所示：
上面有几种方法this。如果把this用局部变量替换它，那就是下面的方法。这就是了。这里的局部变量是一个单字符变量，因为最后，我们的项目将使用UglifyJS来压，方法中定义的所有变量，只要不超过54个，将是单字符变量。先看优化前，一共四个this，他们占领了16个字符。优化后，四个this分成四份n，是4个字符，还有一个附加的赋值语句，该语句中间包含一个空格，手后面的分号，一共是11个字符，加上四个n就是15个字符，比优化前少一个字符。如果我给这个方法再加一个this,优化前的代码，会增加4个字符，并且只需要添加优化的代码1个字符，所以在该方法中this越多，就越能减少。因此：
总而言之，只要方法this关键字超过3个，可以节省字符数。而且this越多，你存的越多。我正在编译它JS在代码中搜索，总共有将近18号个this，这样可以节省很多。但是这个优化要注意，每个function是一个范围，在每个范围内this所有参考都不一样，所以在每个不同的范围内this分开计算，换句话说，如果该方法中有一个函数，那是在计算方法中this数量时，函数中出现的内容不应该计算this。第二个，有一些方法，已经写了内部变量赋值是this的，然后你可以使用这个现有的变量，可以进一步减少字符。这种优化最终节省了0.3M。这种优化不仅优化了代码的大小，因为在JS里，局部变量的调用比this要高的，所以也可以加快游戏的运行效率。
4.压缩包名称、类名、方法名、属性名
你在这一步做什么，是把UglifyJS默认压力的名称，我们用自己的方式打败了他。
① 同名按同简称，输入代码中出现的相同名称，按相同的短名称。
② obj.abc 与 obj[“abc”] 区别对待：
默认压缩规则：obj.abc 写入的属性名称将被压缩，obj[“abc”] 书写的字符串部分不会被压缩。
这样想着，主要是因为UglifyJS考虑到一些属性名称被压缩，某些属性可能无法访问，UglifyJS方法是提供一个未按下的配置名称列表，但这只是一个配置列表，我们无法通过这个列表定位这些属性名在代码中的使用位置，有一定的局限性，因此，通过obj.abc 与 obj[“abc”] 区别对待，我们在写代码的时候可以用不同的方式告诉编译器，您想在这里按属性名吗。
有人会有疑问，用obj[“abc”]的写法，会比obj.abc文字上还有三个字。别担心，因为在最后UglifyJS当被压缩时，会将[]语法转换.语法的。
③ 自定义标签 /*[ZIP-JSON]*/
为了不打破程序员的编程习惯，现在我们必须用字符串的形式来。
当访问该属性时，想到了下面的解决办法：在字符串前添加/*[ZIP-JSON]*/
如：
在我们常用的慢动作类的用法中，上图的“x”和“y”是属性名，默认情况下，字符串不会被压缩。此时，我们可以添加/*[ZIP-JSON]*/标签，如：
这样，“x”“y”它将被压缩成相应的名称。
通过这些过程，我们的代码将以下列形式编写：
形式1：label 该属性名，不会被压缩，在访问时，它也用自己的原名访问
形式2：label该属性名在定义时就被压缩了，可以通过并且会被压缩.语法访问
形式3：label该属性名在定义和访问时都有被压缩
当然，/*[ZIP-JSON]*/作为注释块，在最后AS3被转成JS时，UglifyJS会帮助我们清除评论区，别担心加了注释块反而代码会大的问题。
④ 特殊待遇
诸如 hasOwnProperty、propertyIsEnumerable 等方法，以及Layabox 里的 __JS__ 方法。
方法中传递的字符串，其实就是一个属性名。因为默认的属性名将被压缩，并且字符串不被压缩，所以这些方法中的名字，我们默认压缩。但是应该压缩成什么样的名字呢？
我们上面说的，哪些名字应该按，按压时的一些注意事项，最后，这些名字，你想怎么烫？当然压力越小越好，最低是多少？一个角色是最好的。先来看看要造的名字，有什么限制。名称可以由字母组成，字母区分大小写，也可以用数字，并加下划线，还有一个不常用的$符号，应该注意的是，名称的第一个字符不能是数字。如果我们在一个字符中使用所有的名字，能有多少个名字？26小写字母，26大写字母，10数字没有用，添加两个符号，就是54个。两个字的名字呢，就有3456个，三个字符是22万个。当然这里会少几个可用的，为什么？比如，像as,is,if,for这样的名字，也是二字三字，但都是关键词，名称不能与关键字相同，但是这样的关键词并不多，不多于10个。三个字符可以有22一万个名字，这对我们来说够了吗？
上图是《大天使之剑H5》中使用的名称字数分布图，一共有4一万个名字，两个字的那个3一千肯定不够，三字的22一万可以完全满足。让我们看看这些名字有多长，你可以从里面看到，95％以上的名称是大于三字的，那么优化的空间就更大了。在我们最终项目的名字被压缩之后，全面下降1.9M。下面是压缩后的名字，大部分工作都是用编辑工具完成的，一部分是修改源代码，还写了一个工具来处理，尽量用工具做，否则，您必须手动修改它，工作量会变得巨大。
以上五点是对的《大天使之剑H5》优化后，如图所示：
《大天使之剑H5》的代码是关于10M减少到大约5.1M的大小。
⑤ 有些还没去过《大天使之剑H5》理想的优化
- 静态常数被编译成JS之后，在使用的地方写值，这不一定是最佳的
- 方法中使用的属性被分配给局部变量以供重用
- 使用(param)=>{}代替function(param){}
- 当一个类只有一个子类时，可以减少继承链
- 可以减少分组结构
四、使用分包
在上述优化之后，《大天使之剑H5》主要代码也是5.1M，还需要这个5.1M裂开，这5.1M中，游戏引擎的部分占了0.7M，其他小文件占0.2M，剩下的主要程序是4.2M，剩余的4.2M可以转包加工。
怎么能转包在腾讯和layabox官网找详细教程，以下是相关链接：
腾讯关于分包加载的解释：
https://developers.weixin.qq.com/minigame/dev/tutorial/base/subpackages.html
Layabox微信游戏在官网转包的例子：
https://ldc.layabox.com/doc/?nav=zh-js-5-0-6
关于在layabox是怎么分包的，这里简单说一下：
项目的根本，创建一个module.def文件，这是一个文本文件，里面的内容如下，可以编，生成主文件的JS和模块.js两个文件。如果要将其分成多个模块，写出不止一个这样的结构，只需定义模块名称和模块对应的代码所在的文件夹即可。
看起来是不是很简单？但是我们随机指定一个文件夹中的代码编译成一个模块，然后独立出去，运行时，会有一个错误。上图红色部分报告了一个错误。
该错误的原因是主文件将首先运行，主文件引用模块的XXX，当它在这里运行时，该模块尚未加载，所以xxx未定义，所以报错了。
所以，在你能很好地划分模块之前，你需要分离项目。如果你想分离，那你必须知道，我们分配给模块什么功能，如果您需要在此功能中与主程序进行交互，需要设计相应的传递机制来实现解耦。
如果该项目是新项目，我们可以在设计游戏之初就做这一部分，在功能开发中，要知道该功能是一个要分出来的模块，应该用什么样的开发规则进行开发，可以实现解耦，然后实现模块化。
但是我们的游戏上线快一年了，如果我们现在加入这样的机制，就相当于把需要放入模块的功能进行了重构，这是一项繁重的工作，并且必须重新测试该功能，开放式开发周期，很容易出去BUG。后来我想到了一个方法，可以不解耦的划分模块。
在我说我们能做什么之前，我想说明一点，这个方法只是为了解决小游戏中转包小于的问题4M而做的，与子模块的设计思路不同。该模块的目的是什么？就是把不用的函数放到模块里，当你需要的时候，然后加载相应的模块。我的方法，有必要进入游戏之前，所有模块都需要加载，无论模块的功能是否需要它，无论模块中有什么功能。
为了说明这一点，我们先来看看JS的类。JS在撰写本文时，类的定义，有顺序吗？看看这段代码，这里定义了一个父类，然后定义一个子类。我们能不能先在这里写定义一个子类，写定义另一个父类？注意子类的定义，您需要传入父类的定义，如果你先写子类的定义，传入的父类定义是一个undefined，当它被转移到父类定义中的属性时，将报告一个错误。所以父类必须写在子类前面。换组件模块是什么感觉？假设我们现在有两个文件，第一个被加载的被称为模块A，加载后，它被称为模块B。模块A中有一个子类的定义，在模块B中有其他类的定义，本模块也包括在内A中子类的父类的定义。在模块A加载后，当运行子类的定义时，他的父类叫做，因为模块B尚未加载，所以肯定是报错了。这里怎么才能避免报错？很简单，将父类定义，也放在模块里A里，那就不会报错了。如果父类有父类，而且在模块中B里的，然后记得把他的父类也带到模块中A里。
具体我们是怎么操作把父类也放在模块里A里的呢？我们只需要打电话给Laya编译器之前，将父类as文档检查模块A把它放在文件夹里。父类中的包名是什么，不需要修改。知道包名是AS尽管它与存储文件的路径相匹配，但在用laya编译时，它不检查包名是否与路径匹配，最终生成到JS里的，它是写在文件中的包名，路径只是作为放入哪个模块的基础。
我们刚刚谈到的是，在另一个模块的情况下，父类导致了错误。除了这个，还有别的吗？有的，比如我们刚才在模块里A里的类，在解耦的逻辑中，必须有对模块的调用B的类。然而，在初始化时，它不应该碰到商业逻辑，你为什么报告错误？让我们看一下模块A中的代码。
模块A框中的前几行通常是这样的，第二行，是将Laya引擎中的一些公共方法用短名称定义变量，调用方便的逻辑。第三行开始，它是本模块中引用的类，用所有类的名称给变量名赋值，这样使用起来很方便，不需要写包括包名的类名。也就是说，我们直接在AS中的代码，不需要太多的修改，它就可以在JS。注意到，这些代码行，它在这里JS该文件将在初始化时运行。看第四行，我们有课，假设这个类被称为ClassName，这个类是在模块中定义的B里的，那么这个赋值语句将是因为模块B尚未加载而找不到ClassName的定义，然后报告一个错误。这个类出现在这里的原因是，因为它用在这个模块的一个类中。
我们在这里见，写在类的方法中的代码，它将不会在初始化期间运行，所以我写了模块B在中定义的类在初始化时不会报告错误，导入的类将被写到模块的开头，会在初始化时运行到将报告一个错误。所以我们是这样处理的，所有模块A里的类，如果import该类是一个模块B的类，那拿着这个import删除掉。把所有使用这个类的地方，类名，包括包名，写为此函数调用的字符串。
好像是这个变化，会有更多需要改变的地方，并且在生成的代码中，还会有多个董事的名字，我把它改成了这个，向类中添加一个静态变量，让他等于这个函数，那么就不需要在代码中修改了，转到使用该类名的地方，实际上，这个定义的静态变量叫做。并编译成JS后，静态变量的定义变成了get函数来获取这个值，也就是说，只有在使用它的地方才会调用它，而不是初始化。这就解决了模块A该模块在代码中被调用B类导致初始化期间报告错误的问题。
做刚才那两个地方就完事了？我们再回忆两种情况，它们都是模块A里的类，如果模块被引用B里的类，然后想办法去掉他的引用，第一次运行时让他调用它。换句话说，编译为JS的时间，模块A中的类被视为没有引用的模块B在班上，如果该模块B中的类，假设叫SimgleClass，唯一的参考是模块A中的类引用了，现在把模块A中的引用被删除，那SimgleClass没有类引用它，也就是编译的时候，不会将此类编译成JS里去。在运行时，你会报告一个错误，因为你找不到定义。所以在SimageClass加上强制编译的标签，这是由LayaBox提供的标签，当有这个标签时，即使这个类没有引用，也会被编译成JS里去。
最后的结果，如图所示：
这4.2M主程序文件，被分割成一个1.2M和一个3M，小的打包成一个包，里面有引擎代码和一堆其他的小文件，共2.1M，3M那个文件只是一个包。当程序运行时，会进入游戏，先加载2.1M的包，它将在完成后立即加载3M的包。加载完两个包后，会进入游戏。
陈源：游戏性能优化
游戏性能问题，往往是我们游戏程序员最关心的问题，对于这个问题，这里我总结一下我关于游戏性能优化的八点想法：
理念一：善于从问题的表象进行优化
当游戏中出现问题时，最直接的表现就是卡，有许多不同的情况导致卡顿的问题。在解决卡顿问题之前，我们应该首先排除外部问题是否导致了堵塞，外部问题：网络差，硬件差，系统问题等。排除外部问题引起的卡后，我们可以根据卡顿现象来定位问题。
1.稍微更频繁的干扰
1）帧率
根据游戏本身设置帧率范围，一般游戏建议30框架就够了
2）Drawcall
在理解什么是drawcall后，我们知道，过高的drawcall会导致卡顿，这里有一些折扣drawcall的方法：
A.查看drawcall
在layabox中，添加代码DebugTool.showStatu = true;
B.连续渲染同一图集中的图片，它只会被执行一次drawcall
C.UI上drawcall优化
优化的思路是尽可能使同一图集中的图片一次性连续渲染，例如：在layabox打开其中一个UI，查看表单层次结构界面中的子对象，如下图：
我们可以看到每个子对象的正面，有一个小点，这个点的颜色代表他来自哪个图集，相同颜色的点代表同一个图集。渲染UI时，UI上的每个子对象都是从上到下渲染的。而不影响界面，调整界面中组件的级别，可以减少drawcall的目的。调整后，如图所示：
优化前：会有6次drawcall
优化后：只有3次drawcall
D.出现drawcall优化
以场景中的人物为例：
假设一个角色的一组资源在一个地图集中。
所以这套服装中的人物在场景中被连续渲染，只用1次drawcall。实际上，在游戏中，穿同一套衣服的人不会按照理想的顺序出现。在一个场景中会有许多穿着不同服装的角色，每套衣服都在一本地图册里。换句话说，场景里，渲染N这样的角色需要无限接近N次drawcall。
当每个角色都有阴影的时候，影子资源，它必须在一个不同于每个包资源的atlas中。
情况1：和人物阴影在同一个容器中处理，每个容器都是一个角色，这将会发生，渲染单元A，将使用两套图集+有两张影子图册drawcall。当渲染N个人物，就有N*2次drawcall。
情况2：移除渲染的阴影，当所有的字符都被渲染时，根据所有字符的位置，画一个阴影。这种情况，渲染N个人物，只会有N+1次drawcall显然现在的情况2处理方法比较好。
当每个角色都有名字时、称号、血条和其他元素，如果这些要素符合上述情况1的处理，那drawcall就有N*M次。根据上面的情况放这些元素2的处理，显然可以减少很多drawcall。
E.其他削减drawcall的方法
如：减少遮挡单元渲染
Atlas控件
3）高消耗运行，特别是enterframe和for在循环内部
注意代码逻辑优化，降低算法复杂度
4）资源加载缓存有问题/资源过于分散，造成I/O过高
优化资源加载策略
5）打印日志
减少打印日志
6）限制基础渲染分辨率
2.突然，大卡顿
- 一些不规范的操作，高循环复杂度
它可以被执行到一些具有高复杂性的循环中，导致突然，大卡顿
- 包裹太大
关注协议包优化，优化方法，例如：
如果以上a,b,c当的值仅低于十位数时，可以整合到一个领域:
这样做的好处，最初需要12数据字节，仅现在4字节也行。
- 垃圾恢复负载过重
装置是否经常初始化，用后销毁？
需要使用对象池吗
如果卡顿发生了UI上：
- 面板内容初始化成帧处理
- 和图片大小，图集依赖规划是否合理
- UI面板分页标签
- UI内特效，3D模型等辅助元素的初始化延迟
- List优化，动态初始化，使再循环
3.越来越糟了，卡顿
- 有对象吗/用完了就藏东西，而不被删除，越积越多
如：飘血、事件监控等
- 内存泄漏，GC越来越频繁
4.坚持闪回
- 内存太高，内存泄漏
- 检查是否有错误或无限循环
理念二：基于记忆的
许多感觉到的大堵塞是由垃圾收集引起的；
记忆问题通常比CPU这个问题更难解决，甚至需要大规模的重建；
减少内存会让游戏更轻，其他小问题可以缓解。
理念三：内存使用策略比内存释放策略更重要
内存使用策略，通常应该在项目的早期阶段就制定出来，这里有一些建议：
- new对象必须由创建Factory或者Manager实行统一管理，这就完了，这对以后排除内存问题尤其重要；
- View和Model完全分离；
- View的创作精细到每一帧，按业绩创造；
- FpsManager根据帧速率动态调整阈值；
- 对象池的合理使用：“频繁的创造和毁灭”的“小型”对象采用对象池。
理念四：重视资源压缩
在游戏程序中，很多内存来自资源，合理压缩资源是减少内存的有效方法。关于资源压缩，这里有一些建议：
- 注意制作工艺，技术标准
资源的生产不能是任意的，必须有一定的标准，例如：
- 原始图片资源的使用jpg还是png
- 是可以镜像处理的图片资源吗
- 相似的资源可以统一吗
- 避免在程序中使用过滤器和灰化
- 图片资源上一些不起眼的灯光效果或者羽毛效果可以用吗
- 字体图片，拆分和组合相同的单词
- 九格拉伸图的概念
- 理性行动、特效序列帧
许多角色会移动、特效资源，美术给的效果很精细。在处理记忆问题时，考虑对这些资源的以下处理：
1.抽帧
一些影响不大的关键帧可以删掉吗。
2.再次放大
一些不起眼的部分，序列帧可以按比例缩小，当使用该程序时，再放大。
3.砍方向
人物的左右资源可以通过旋转其中一个动作来实现吗？
需要各个方向的资源吗？
- 对称资源减半/使用四分之一反射镜
- 序列特效IDE进行替换
- UI全屏分辨率选择 1024像素
- icon尝试使用 64*64 的格式
- 使用pvrtc etc ，png8格式
- UI使用背景最接近的那个2权力的大小
- 不要打相册里的背景，并尝试使用它jpg
- 少用口罩
- 使用单声道声音
理念五：屏蔽策略
当游戏出现性能瓶颈时，我们不得不考虑屏蔽一些游戏内容的显示，例如，一些次要的场景单元、特效等。拦网必然会削弱玩家的游戏体验，但是，和卡顿比起来，甚至闪回了，适当的屏蔽规则是必要的。
- 添加屏蔽设置，性能差时自动开启
- 该策略应涵盖所有类型的显示对象
- 一些场景使用统一的模型
理念六：不要忽视看起来很小的东西
积少成多，一些看起来很小的地方，但是处理方式不合理，也往往会影响游戏的表现，在《大天使之剑H5》中，我们在以下几个地方做了一些优化：
- 配置表数据优化
- String阵列方案
- 相似String的处理
- 版本文件，使用树存储来减少URL场的重复
- 类型被广泛使用并且变得更长
- 战报分析，细分分析
理念七：了解有关开发人员工具使用的更多信息
调试游戏时，我们经常依靠开发者工具来了解游戏的内存变化、CPU的使用、游戏中物体的整体情况、资源的应用、甚至是我们关注的变量值等等。善于使用各种开发者工具可以让我们事半功倍。
- 使用谷歌浏览器的开发者工具
layabox开发的H5游戏默认由谷歌Chrome调试，在这里，我们来谈谈Google Chrome的开发者工具的应用。当游戏在谷歌浏览器中运行时，按F12你可以打开开发者工具，他的一些常见功能是：
1.console的使用
Console的界面如上图所示，主要显示我们游戏运行的日志等信息。在每根木头的后面，有一个链接可以快速跳转到输出日志的代码，在console的下方，具有输入框功能，我们可以通过在这里输入代码来改变当前游戏中的值、以不同的方式打印日志等。
2.调试
我们可以在工具的Sources选项卡找到我们想要调试的内容JS，调试断点或条件断点。
3.NetWork
NetWork该面板提供了关于已经下载和加载的资源的详细信息。
在这里我们可以直观的找到一些需要很长时间加载才能进行优化的资源。
4.TimeLine
TimeLine界面中，我们可以看到时间支出的完整概览。
如图所示，通常，当游戏性能很差时，在TimeLine点击界面左上角的录制按钮，在记录一段时间后，单击完成，这将有助于我们在录制期间收集信息，游戏每一帧的运行状态。
- 绿色帧在帧时间内完成所需的处理。
- 红色帧的处理时间比帧应该处理的时间长，也就是卡帧。
我们可以关注红色框架，你可以在下面看到哪种方法占用了多少时间，以及这个文件中调用了哪些方法，它们分别调整多少时间。
在图的左下部分，还可以看到代码逻辑和渲染的比例，可以用来判断可以做哪些优化，如何优化。该功能，我不是唯一一个提到这个程序的人，这里有很多信息可以帮助我们分析和发现问题，可以为我们的优化提供很多帮助。
5.Profiles
Profiles界面中，我们可以使用快照功能。最常用的是Take Heap Snapshot功能。它可以记录当前内存分配的详细信息，还可以比较多个内存快照，不同时间点的分析，内存有哪些具体的变化。
理念八：遭遇，先抵制再优化
没有一个性能问题是由单一问题引起的；
单一单点修改，注意，前后对比很容易发现关键问题；
调试时注意日志，一行一行看，总会找到的Keyword。
关于极光客厅
“极光客厅”是三七互娱极光网主导的线下分享沙龙系列活动，以分享干货为核心追求，覆盖技术、美术、策划、市场等不同维度，为游戏开发者提供一个互相学习交流的平台。
