iOS：由於內存不足導致瀏覽器崩潰

Question

由於iOS上的內存不足，我的網站在瀏覽器中崩潰。 我正在重復一些消耗記憶的動作。 經過多次嘗試，瀏覽器崩潰了。 但是，當我使用開發工具中的timelime使用Chrome在我的桌面上測試同一個網站時：

1. 執行相同的操作
2. 收集垃圾
3. 收集所有額外分配的內存。

如果沒有內存泄漏，為什么瀏覽器會崩潰？ 有沒有辦法強制垃圾收集？

Answer 1

了解iOS資源限制

您的網頁在桌面上運行良好並不能保證它在iOS上運行良好。

1.請記住iOS使用

• EDGE（帶寬更低，延遲更高）
• 3G（更高的帶寬，更高的延遲）
• Wi-Fi（更高帶寬，更低延遲）

連接到Internet。

2.您需要最小化網頁的大小。 包含

• 未使用或不必要的圖像
• CSS
• JavaScript的

這會對您網站在iOS上的表現產生負面影響。

3.由於iOS上可用的內存，它可以處理的資源數量有限：

已解碼的GIF，PNG和TIFF圖像的最大大小

• 3百萬像素，適用於RAM低於256 MB的設備
• 500萬像素，適用於RAM大於或等於256 MB的設備

對於RAM小於256 MB的設備，這確保寬度*高度≤3* 1024 * 1024

注意：解碼后的大小遠遠大於圖像的編碼大小。

使用子采樣，JPEG的最大解碼圖像尺寸為3200萬像素 。 由於子采樣，JPEG圖像可以達到3200萬像素 ，這使得JPEG圖像可以解碼為像素數量的十六分之一 。 大於2百萬像素的 JPEG圖像被二次采樣 - 即，解碼為縮小的尺寸。 JPEG子采樣允許用戶查看來自最新數碼相機的圖像。

4. canvas元素的最大大小是

• 3百萬像素，適用於RAM低於256 MB的設備
• 500萬像素，適用於RAM大於或等於256 MB的設備。 如果未指定，畫布對象的高度和寬度為150 x 300像素。

5. JavaScript執行時間

每個頂級入口點限制為10秒 。 如果您的腳本執行時間超過10秒，則iOS上的Safari會停止在代碼中的隨機位置執行腳本 ，因此可能會導致意外后果 。

6.一次可以打開的文件的最大數量是

• 在iPhone上有八個

• 在iPad上有九個 。

有關詳細信息，請參閱開發Web內容以獲取Safari-Apple文檔 。

垃圾收集

移動safari javascript實現沒有像Internet Explorer中的CollectGarbage（）那樣的命令用於垃圾收集。

有三個事件將觸發移動safari中的垃圾收集 （ 參考 ）。

• 專用垃圾收集計時器到期
• 當所有堆的CollectorBlocks都已滿時，就會發生分配。
• 分配具有足夠大的關聯存儲的對象。

觸發垃圾收集真的是一種不好的做法。我們應該做的是編寫不泄漏內存的代碼。

請參閱Javascript中的內存管理

Answer 2

下面是我遇到過的最好的資源（有基准），它解釋了它： http ： //sealedabstract.com/rants/why-mobile-web-apps-are-slow/

幾個星期前我遇到了那些性能障礙，請注意iOS沒有任何默認的垃圾收集（文章解釋了原因）。 它是應用程序的責任（在這種情況下，是瀏覽器應用程序）。 您無法通過您的網絡應用收集垃圾。 為iOS優化您的網站（防止崩潰）的一個小技巧：避免CSS轉換。

雖然我建議你拿一杯咖啡閱讀完整的文章，但我會在下面粘貼摘要：

• Javascript對於2013年的移動應用程序使用來說太慢了（例如，用於照片編輯等）。
  
  • 它比本機代碼慢約5
  • 它與IE8相當
  • 它比x86 C / C ++慢約50
  • 如果你的程序適合35MB，那么它比服務器端Java / Ruby / Python / C＃要慢大約10倍，並且從那里開始呈指數級下降
• 它變得更快的最可行途徑是將硬件推向桌面級性能。 這可能是長期可行的，但它看起來像是一個漫長的等待。
• 這些天語言本身似乎沒有變得更快，正在研究它的人說，使用當前的語言和API，它永遠不會像本機代碼那么快
• 在內存受限的環境中，垃圾收集呈指數級惡化。 它比桌面級或服務器級環境更糟糕。
• 每個有能力的移動開發人員，無論他們是否使用GCed環境，都會花費大量時間考慮目標設備的內存性能
• 目前存在的JavaScript基本上反對甚至允許開發人員考慮目標設備的內存性能
• 如果他們確實改變了主意並允許開發人員考慮內存，那么經驗表明這是一個技術難題。