My site crashes in the browser due to low memory on iOS. I'm repeating some action which consumes memory. After several attempts, the browser crashes. However, when I tested the same site on my desktop using Chrome by using timelime from dev tools:
Why does the browser crash if there are no memory leaks? Is there a way to force garbage collection?
Your webpage performing well on the desktop is no guarantee that it will perform well on iOS.
1.Keep in mind that iOS uses
- EDGE (lower bandwidth, higher latency)
- 3G (higher bandwidth, higher latency)
- Wi-Fi (higher bandwidth, lower latency)
to connect to the Internet.
2.You need to minimize the size of your webpage. Including
- unused or unnecessary images
- CSS
- JavaScript
which adversely affects your site’s performance on iOS.
3.Because of the memory available on iOS, there are limits on the number of resources it can process:
The maximum size for decoded GIF, PNG, and TIFF images
- 3 megapixels for devices with less than 256 MB RAM
- 5 megapixels for devices with greater or equal than 256 MB RAM
That is ensure width * height ≤ 3 * 1024 * 1024 for devices with less than 256 MB RAM
Note: that the decoded size is far larger than the encoded size of an image.
The maximum decoded image size for JPEG is 32 megapixels using subsampling. JPEG images can be up to 32 megapixels due to subsampling, which allows JPEG images to decode to a size that has one sixteenth the number of pixels. JPEG images larger than 2 megapixels are subsampled—that is, decoded to a reduced size. JPEG subsampling allows the user to view images from the latest digital cameras.
4.The maximum size for a canvas element is
- 3 megapixels for devices with less than 256 MB RAM
- 5 megapixels for devices with greater or equal than 256 MB RAM. The height and width of a canvas object is 150 x 300 pixels if not specified.
5.JavaScript execution time
limited to 10 seconds for each top-level entry point. If your script executes for more than 10 seconds, Safari on iOS stops executing the script at a random place in your code, so unintended consequences may result.
6.The maximum number of documents that can be open at once is
eight on iPhone
nine on iPad.
Please refer Developing Web Content for Safari-Apple Documentation for more info.
Mobile safari javascript implementation doesn't have any command like CollectGarbage() in internet explorer for garbage collection.
There are three events that will trigger garbage collection in mobile safari(Reference).
- A dedicated garbage collection timer expires
- An allocation occurs when all of a heap's CollectorBlocks are full.
- An object with sufficiently large associated storage is allocated.
Its really a bad practice to trigger garbage collection.What we should be doing is to write codes that doesn't leak memory.
Plese refer Memory management in Javascript
Below is the best resource (with benchmarks) which I have ever come across, that explains it: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
I hit those performance hurdles a few weeks back, and please note that iOS does not have any default garbage collection (the article explains why). It is the responsibility of the app (in this case, the browser app). You cannot collect garbage via your web app. A small tip while optimizing your website for iOS (to prevent crashes): avoid CSS transations.
Though I would recommend that you grab a cup of coffee and read the complete article, but I'll paste the summary below:
- Javascript is too slow for mobile app use in 2013 (e.g., for photo editing etc.).
- It’s slower than native code by about 5
- It’s comparable to IE8
- It’s slower than x86 C/C++ by about 50
- It’s slower than server-side Java/Ruby/Python/C# by a factor of about 10 if your program fits in 35MB, and it degrades exponentially from there
- The most viable path for it to get faster is by pushing the hardware to desktop-level performance. This might be viable long-term, but it’s looking like a pretty long wait.
- The language itself doesn’t seem to be getting faster these days, and people who are working on it are saying that with the current language and APIs, it will never be as fast as native code
- Garbage collection is exponentially bad in a memory-constrained environment. It is way, way worse than it is in desktop-class or server-class environments.
- Every competent mobile developer, whether they use a GCed environment or not, spends a great deal of time thinking about the memory performance of the target device
- JavaScript, as it currently exists, is fundamentally opposed to even allowing developers to think about the memory performance of the target device
- If they did change their minds and allowed developers to think about memory, experience suggests this is a technically hard problem.
