介绍
最近开发任务中用上了我们自己开发的可视化图层gl-layers，同事发现把图层加入后CPU占用率非常高，这将直接导致页面帧率下降，从而引起画面不流畅，于是找到我排查其中原因。这刚好是一次不错的性能优化实践，于是把它记录下来以备今后朋友们不时之需。
操作步骤
-
看看整体的性能监控是否有异常（右上角折叠菜单icon - More tools - Performance monitor），在本示例中发现CPU占用率长期维持在90%以上，我们需要分析具体原因。
-
打开性能选项卡，录制几秒的过程，就可以非常清晰看到每帧的执行状态和任务的健康状态
-
点击Task-Summary 查看当前任务时间花费在哪里了，如图中示例大部分时间花在脚本执行上
-
打开 Task-Event Log 查看任务中具体质心的时序图，可以看到耗费高时刻以及对应的js脚本名称
-
双击脚本锚点进入对应的代码行，这是高德地图API内部脚本，我们隐约可以看得出来它在帧内执行了某个计算量大的函数，由此知道在执行逐帧方法里肯定调用了高德地图的方法。
-
排查我们自己代码里的逐帧方法，果然存在一个map.render()方法，它的作用是强制让地图重新渲染，以激活自定义图层的内容重新渲染，并与地图的渲染结果进行合并绘制。
-
知道了原因后有两个选择，一是调整造成问题的方法，一是规避该方法。由于map.render()是个非开源API的方法，我们选择后者，通过独立渲染图层的方式规避"图层内容与地图渲染结果合并绘制"这一步。 优化前后性能监测见下图，CPU占比没有维持在90%以上了，js内存占用率也有所下降。
总结
在这次实践中，我们发现问题原因，是高德提供的自定义可视化GLCustomLayer图层必须依赖map.render()，因为它的原理是将map渲染的结果与自定义图层的结果合并后绘制到canvas，如果去除map.render()，那么底图会消失。解决方案是使用独立图层customLayer，不需要依赖map.render()，需要做的就是在viewChange时同步空间坐标就可以了。
唯一的缺陷就是无法展示map上建筑白模与自定义图层网格体的远近关系，网格体永远在map场景的前面，不过这个问题也不大，因为只要有足够的数据，我们可以自己渲染建筑白模，甚至自行定制建筑白模的外观和交互行为。在某些场景中地图的作用被弱化，同时它的资源占用率也可以被弱化，这是我们乐于看到的。
综上所述，做性能方面的优化工作，处理了掌握具体的排查步骤，还需要对代码的业务逻辑有足够的认识，才能够快速定位找到原因和解决方法。