大规模WebGL应用引起浏览器崩溃的几种状况及解决办法

通常的Web应用基本上不会致使浏览器崩溃，写Javascript代码也不须要管理内存资源，基本也不须要考虑内存“泄露”的问题。随着H5的崛起，愈来愈多的本来在桌面端的软件也改头换面迁移到Web上来，好比三维图形类的应用。在Web端显示大规模三维模型不单单是三维显示引擎的问题，也涉及到数据组织、任务调度、资源管理、浏览器兼容等方方面面。这里针对在项目中遇到到几种把浏览器高挂的状况简要列举了一下。

异步请求过多

  浏览器对并发异步请求是有限制的。若是程序不作处理，“同时”发送几百个请求就可能致使浏览器崩溃。

  解决这样的问题涉及到数据管理的问题。有的须要屡次请求获得的数据能够从新组织在一次或几回请求完成。若是就是须要若干次请求，就须要把请求排队，用多个异步请求队列加载数据。

并发异步请求资源死锁

   若一个资源被多个异步请求同时请求的时候就可能致使浏览器死锁，死锁的结果就是浏览器崩溃。默认浏览器都是启用cache的，而浏览器在从cache中读取数据的时候会加锁。

  就须要在组织异步请求队列的时候，相同的资源不能在不一样的队列中出现

GPU进程崩溃

Chrome是多进程架构，每一个Tab都会启用单独的进程来处理页面。但，全部的进程都会公用一个GPU进程。

那么问题来了，若是开启多个WebGL应用页面，每一个页面占用必定的GPU资源，GPU进程的内存加起来总的就会轻轻松松超过1.5G，结果就是GPU进程崩溃，即便是64位Chrome。

在实际中用WebGL显示大模型会轻轻松松的撑爆GPU进程。这就须要显示引擎要处理好顶点数据的内存占用。方法有不少种，这里就很少赘述了。

JS使用内存过多致使崩溃

在上图中能够看到多个内存：内存、GPU内存、Javascript内存。其中Javascript内存是JS对象占用的内存，垃圾回收会影响这部份内存。Javascript代码和垃圾回收运行在同一个线程的环境，当垃圾回收的时候，js代码不会执行。若是js对象过多，（占用内存过多），垃圾回收的过程也会变得漫长。因此Chrome简单粗暴的限制了Javascript内存的占用，在x64下最大~1.4G。解决这样的问题须要优化数据结构或者增长数据动态管理的机制。

JS代码运行Timeout

若是JS运行时间过长，超出必定的时间，浏览器就弹个对话框，让用户选择是否结束。相同的代码在chrome中没有问题，而在firefox中就可能无响应。

解决方法就是把耗时的算法设计成分部执行，结合setTimeout或者requestAnimationFrame使用。

总结

相对桌面应用，浏览器仍然是一个资源受限的环境：JS执行效率，内存管理，线程……。对于大规模的Web应用，须要不断的在效率性能和资源占用上作平衡。

一年半下来，大部分精力花在了debugging中。深深感到，前端能作的事情愈来愈多，程序的规模也愈来愈大，对JS程序员的要求也愈来愈高。