0. 背景介绍
前段时间用WebGL做整车的web端展示，发现当三角片数量大于一定量级后，在微信内置浏览器内打开模型时，浏览器直接崩溃。于是就想到了数据压缩，花了大概一周多时间做数据压缩，然后就是修改代码，debug，修改代码，debug...
好容易调通了，上整车试试呗，在微信内置浏览器里边打开模型，见证奇迹的时刻到了，妈卖批，这次没有崩溃，但是发现数据加载的时候奇卡无比。像下边这样，持续大概要100秒左右：
优化前（一）
1. Chrome Performance工具
Chrome Performance工具界面
如上图所示，当我们刷新页面时，按下左上角实心黑色原点按钮，就可以把页面加载过程中的一些性能指标给记录下来，依据其记录结果，我们可以有针对性地对应用程序进行优化。
针对前边提到的加载卡顿的问题，我们使用Performance工具进行分析，其结果如下：
性能分析结果
由分析结果可知，性能瓶颈在XHR Load这个执行过程中，那么具体是哪个调用影响了性能呢？我们可以展开调用堆栈一探究竟：
展开调用堆栈
从展开的调用堆栈，我们很容易发现，是下边这条调用造成了严重的耗时：
gl.getShaderParameter，即图中红框框起来的位置。并且从调用堆栈中我们能知道这个函数的调用是在文件：shader.ts文件中，于是我们在本地IDE中打开该文件，发现的确有这样一条调用：
源码
第一次优化后的性能分析结果
第一次优化后的调用堆栈
let length = gl.getProgramParameter(id, gl.ACTIVE_ATTRIBUTES);
这个调用的目的是为了来获取顶点着色器中attribute变量的数量。
第二次优化后的性能分析结果
这一次，XHR Load的执行耗时已经从第一次优化后的63000+毫秒降低到了26000+毫秒，大概减少到了最开始没有优化时候的1/3左右。但是这个地方依然是性能瓶颈，应该还可以优化...
