原创声明
本文系作者辛苦码字所得，欢迎分享和转载，但请在明显位置注明作者的如下信息：
笔名：来碗鸡蛋面
简书主页：//www.greatytc.com/u/4876275b5a73
邮箱：job_tom@foxmail.com
CSDN ID：tom_wong666
背景：Vue+Echarts+mintUI开发移动端app
问题：Echarts图表在IOS端懒加载多个时出现闪退
问题分析：
频繁操作App直到闪退出现，监控内存使用情况后发现，在操作过程中内存一直升高，到600M时软件闪退；
考虑从两方面解决：
一，减轻echarts图表渲染的压力(只渲染视口内的图表)；
二，抑制频繁请求，减轻内存压力(抑制无效请求)；
一，减轻echarts图表渲染的压力：
处理步骤1：
因为同一个组件做了复用，通过点击事件改变params来区分A组图表和B组图表。一开始推测是切换AB组时数据未清空导致的，所以点击事件时给数据做了重置清空动作(this.list=[];)。这样处理之后，进行测试，结果发现内存在起伏中上涨，最终还是会达到600M而崩溃；
处理步骤2：
到这里考虑是否在某个时机(改变AB组图表时或者什么时候)销毁组件，但是vue的.$destory只能销毁一个实例：清理它与其他实例的链接，解绑它的全部指定以及事件监听，并不会销毁/影响DOM展现。DOM展现还在，就表示前面展现过的图表都还在内存中占用空间。
所以办法就是用v-if强制移除DOM。想到就去尝试，思路是：
给eCharts组件加v-if=“isShow”,isShow通过touch事件触发scrollTop的值变更来决定是否显示；步骤三展开讲具体实现。
处理步骤3：
先说明一下变量/常量
(1)mainPage元素，echarts画布元素的顶级父元素；
(2)6rem,chart元素/画布的固定高度；
算法是：
touchend(){
//touchend时获取画面滚动距离的rem值
let scrollRem=mainPage.scrollTop/document.documentElement.fontSize;
//获取页面滚动和echarts元素高度的比例值
this.scrollStep=scrollRem/6;
}
//对于每一个echarts元素是否视口内的判断
<chart v-for="(item,index of data)" :key="index"
v-if="index > scrollStep-1 && index<scrollStep+1">
</chart>
处理步骤4：
考虑到业务需求，懒加载的目的是可以顺畅浏览，所以一般都会在视口之外预先渲染几个图表。实现这个，只要改变判断条件就好了，这里以预加载三个图表为例：
//一次渲染三个图标为例
<chart v-for="(item,index of data)" :key="index"
v-if="index > scrollStep-1 && index<scrollStep+3">
</chart>
处理步骤5：
步骤4处理后，实际验证时发现，正常滑动浏览器/手机端app页面没问题，但是快速滑动时，页面惯性导致在手指离开屏幕后继续移动了两屏，此时出现bug：有图表进入视口，但是没有渲染；
分析后发现，问题在于触发scrollStep的时机不对，目前是在touchend时触发一次，导致在上面的情况下无法控制进入视口的图表渲染。
解决方法：把scrollStep放入onscroll事件中计算，在页面滚动时实时触发。
依据我们的渲染条件，只有scrollStep变更达到6rem才触发一次图表渲染变更，其他时候只在onscroll事件中只触发了两行获取和计算的代码，资源消耗压力不大。
onscroll(){
//获取画面滚动距离的rem值
let scrollRem=mainPage.scrollTop/document.documentElement.fontSize;
//获取页面滚动和echarts元素高度的比例值
this.scrollStep=scrollRem/6;
}
二，抑制频繁请求，减轻内存压力：
处理步骤6：
经过以上五步之后，内存得到了一定程度的释放，但在如下极限条件下仍然会出现内存飙升闪退情况：
如上图，AD是App的导航，所有的导航指向同一个组件E，持续快速切换ABCD，约两分钟后内存飙升超过600M，软件再次闪退。AD组件每次点击需要给E组件发起6个请求，重复多次点击时累计了大量的频繁请求挂起和持续返回，造成了内存的大量累计。
对策：给页面加上“数据加载中”模态框，在数据请求回来之前禁止页面操作，避免频繁的无效操作增加内存压力。
说明：匆忙之中来不及做具体的演示demo，只理了一下思路，若遇到类似问题，参考思路就好。
