android+webgl+性能优化,WebGL应用性能优化

0. 背景介绍

前段时间用WebGL做整车的web端展示，发现当三角片数量大于一定量级后，在微信内置浏览器内打开模型时，浏览器直接崩溃。于是就想到了数据压缩，花了大概一周多时间做数据压缩，然后就是修改代码，debug，修改代码，debug...

好容易调通了，上整车试试呗，在微信内置浏览器里边打开模型，见证奇迹的时刻到了，妈卖批，这次没有崩溃，但是发现数据加载的时候奇卡无比。像下边这样，持续大概要100秒左右：

优化前(一)

1. Chrome Performance工具

Chrome Performance工具界面

如上图所示，当我们刷新页面时，按下左上角实心黑色原点按钮，就可以把页面加载过程中的一些性能指标给记录下来，依据其记录结果，我们可以有针对性地对应用程序进行优化。

针对前边提到的加载卡顿的问题，我们使用Performance工具进行分析，其结果如下：

性能分析结果

由分析结果可知，性能瓶颈在XHR Load这个执行过程中，那么具体是哪个调用影响了性能呢？我们可以展开调用堆栈一探究竟：

展开调用堆栈

从展开的调用堆栈，我们很容易发现，是下边这条调用造成了严重的耗时：

gl.getShaderParameter，即图中红框框起来的位置。并且从调用堆栈中我们能知道这个函数的调用是在文件：shader.ts文件中，于是我们在本地IDE中打开该文件，发现的确有这样一条调用：

源码做过WebGL开发的同学应该很容易看出来，这段代码其实是为了捕捉着色器的编译错误信息，方便调试用的，正式它导致了异常的时间消耗。我们把它注释掉，重新编译，运行，看看结果：

第一次优化后的性能分析结果

发现XHR Load这个执行耗时减少了20000+毫秒，但是性能瓶颈依然在这个地方。因此我们再次打开调用堆栈看看什么情况：

第一次优化后的调用堆栈这次依然是gl.getShaderParameter造成了异常耗时，但是调用位置发生了变化，这次是在文件：shaderprogram.ts中，还是一样的，打开源码看看：

let length = gl.getProgramParameter(id, gl.ACTIVE_ATTRIBUTES);

这个调用的目的是为了来获取顶点着色器中attribute变量的数量。

由于最近为了做数据压缩修改了很多代码，猜测可能和我近期的代码修改有关(创建了太多的着色器程序)，因此尝试修改代码逻辑，尽量减少不必要的着色器创建操作，对代码进行第二次优化，然后又是重新编译、运行，性能分析：

第二次优化后的性能分析结果

这一次，XHR Load的执行耗时已经从第一次优化后的63000+毫秒降低到了26000+毫秒，大概减少到了最开始没有优化时候的1/3左右。但是这个地方依然是性能瓶颈，应该还可以优化...