大規模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程序員的要求也愈來愈高。