It crashes my iPad Air running iOS 7.1 beta 2 all the time, even after starting the system fresh.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Seeds iOS 7.1 Beta 2 to Developers [Updated]
- Thread starter MacRumors
- Start date
- Sort by reaction score
It crashes my iPad Air running iOS 7.1 beta 2 all the time, even after starting the system fresh.
Yup, as I've pointed out above, it's impossible to even load the page on an 1GB Retina iPad - not even 690Mbytes of free RAM is sufficient to load the page.
This is why I've stated right from the beginnign that UIWebView (and Safari) is a real memory hog and casual(!!) Web pages can easily result in allocating hundreds of Megabytes of RAM. Just like with nin.com.
This, again, has nothing to do with "incompatible" HTML / CSS markup, unlike what some have stated here in the thread. It's just that nin.com has too many embedded videos / images, which heavily taxes UIWebView. It has, on some non-Retina iPads / larger-memory iPhones, perfectly render-able markup.
Turns out I was right.
My benchmark app is ready. As usual, I've made the entire project available. It's available at https://dl.dropboxusercontent.com/u/81986513/122013/WebPageMemoryTester.zip and can be used for your benchmarks too.
I've made it VERY simple it doesn't even have XIB's. The view controller, WebPageMemoryTesterViewController, (programmatically) creates an instance of UIWebView with the size of the full screen (minus the upper status bar, of course) and adds it as a subview to the current view. Then, it starts loading nin.com and starts a timer ([NSTimer scheduledTimerWithTimeInterval:0.5 target:self selectorselector(print_free_memory) userInfo:nil repeats:YES]
I also directly call print_free_memory from not only the timer, but also immediately before and after creating UIWebView and immediately starting to load the web page into it. Also, I directly call it from the didReceiveMemoryWarning method so that we can see how much free memory the system had upon the warning.
I've run the tests on several of my devices, with various iOS versions and screen resolutions. I've reset every device before the tests so that they can have as much free RAM as possible. Three of the devices are JB'n but this fact didn't really have any effect on the results. After all, the free RAM of my non-JB'n 7.0.4 iPad 3 was 659349504, while that of my 6.1.2-based, JB'n iPad 3 was 625999872 that is, some 35 Mbytes only.
The results certainly show what I talked about:
- UIWebView consumes a LOT of memory. Retina iPad 3's with 1 GB memory simply can't even load it because the page just won't fit into the memory, regardless of the OS version.
- the higher the screen resolution, the significantly(!) more memory used. This is certainly visible if you compare the iPad2 figures to those of the two iPad 3's. The non-retina iPad 2 allocates significantly less memory when loading / scrolling around the page and, if you don't scroll too quickly, you can actually have a chance to be able to read it entirely.
- the number of pixels of the 640*1136 iPhone 5 is around the same (727k) as that of the 1024*768 iPad 2 (786k). Still, the former consumes almost two times more memory to load / render the same webpage (I would have expected the iPad 2 to consume somewhat more memory because of the higher-res screen). Dunno if this is caused by the iPhone 5 running 7.0.4 and the iPad 2 only 6.1.2.
Links to logs + more thorough explanation:
The 5.1.1-based, JB'n iPhone 3GS couldn't even load the page. As you can check out in the full log at , in second 42, immediately before didReceiveMemoryWarning being invoked, we only had 3.5Mbytes (3555328) of free RAM, while the Web page has already been allocated 104Mbytes (104001536):
84; DIFF ORIG: 104001536; DIFF PREV: 471040
used: 73666560 free: 3555328 total: 77221888
The 4.3.3-based, non-JB'n iPod touch 4 crashed at loading too (after allocating 85M (85803008) bytes; full log: https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/ipt4g.txt ):
didReceiveMemoryWarning; 100; DIFF ORIG: 85803008; DIFF PREV: -647168
used: 60604416 free: 2506752 total: 63111168
The 7.0.4-based, non-JB'n iPhone 5 started with 626Mbytes of free RAM (626913280; full log: https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/ip5.txt ). It has finished loading the entire page at around the 55th second (around tick 110), allocating 335 Mbytes (335597568) in the process:
111; DIFF ORIG: 335597568; DIFF PREV: 0
used: 378970112 free: 291315712 total: 670285824
Then, I started to (quite slowly fast scrolling would have crashed the widget) scroll down. During this, I've encountered several didReceiveMemoryWarning invocations. Then, the free RAM was around 70 Mbytes (70344704; a considerable drop from the 291M free after loading the page) and the widget allocated itself around 556 Mbytes (556568576):
129; DIFF ORIG: 556568576; DIFF PREV: 131567616
used: 577814528 free: 70344704 total: 648159232
After getting to the bottom and waiting a bit for everything possible to be released, I regained most of my, during the scrolling, missing free memory, which was around 274M (274776064); that is, not much less than the starting 291M:
145; DIFF ORIG: 352137216; DIFF PREV: -8192
used: 432508928 free: 274776064 total: 707284992
Then, a quick scroll to the top (by tapping the status bar) could have easily crashed the app as it, at the worst half-second, resulted in only 38Mbytes (38494208) remaining free:
153; DIFF ORIG: 588419072; DIFF PREV: 13512704
used: 527482880 free: 38494208 total: 565977088
The 7.0.4-based, non-JB'n iPad 3 couldn't load the page either (full log: https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/ipad3.txt ). Very soon after UIWebView had allocated around 650 Mbytes (648257536) and there remained only 11Mbytes of RAM (11091968), it crashed:
didReceiveMemoryWarning; 31; DIFF ORIG: 648257536; DIFF PREV: 79646720
used: 468738048 free: 11091968 total: 479830016
The 6.1.2-based, JB'n iPad 3, starting with a free memory of around 625 Mbytes (625999872), received its first didReceiveMemoryWarning callback at around 80 Mbytes of free (80945152) and, then, after half a second later, crashed at 8MB free (8798208), with the Web widget having allocated 617Mbyte (617201664) (full log: https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/ipad3-612.txt ):
didReceiveMemoryWarning; 25; DIFF ORIG: 545054720; DIFF PREV: 22192128
used: 465739776 free: 80945152 total: 546684928
26; DIFF ORIG: 617201664; DIFF PREV: 72146944
used: 517550080 free: 8798208 total: 526348288
The 6.1.2-based, JB'n iPad 2 only allocated around 200 Mbytes (201277440) of RAM to load the entire page with just a little bit (10Mbytes) of free RAM (10838016); see for example (full log: https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/ipad2.txt )
177; DIFF ORIG: 201277440; DIFF PREV: 0
used: 165519360 free: 10838016 total: 176357376
I started (slowly) scrolling down at tick 177; apart from occasional didReceiveMemoryWarning invocations, this could be done without crashing. So could I tap the upper status bar to quickly return to the top.
----------
(Just a quick note: see my benchmarks above.)
Great job! Maybe would make sense to send such benfhmarks to Apple no?
They've certaintly been aware of the problem for years. I don't think they want to fix it -it might be "good enough" for them. It could be fixed by them, even w/o adding additional RAM, purely in software.
good for you for doing all that testing... but mine works fine! Go figure. In fact, I can't remember the last time anything crashed on this phone, let alone safari...
So just pretend the update is actually called 7.0.5 (you realize it's just a number, right?) and be happy. I'd rather Apple work out all the bugs in the initial release prior to throwing in more features.
That, tbh, makes the results of your benchmark rather useless. A more scientific approach would rule out (i.e. keep the same) as much variables as possible, and the only thing you're actually prooving here is that the culprit is probably more iOS7 than a structural starvation of RAM.
Nonetheless, this appears to be a software issue and not, as some keep claiming, an unfixable hardware issue. Which more or less confirms my suspicions that I had based on the fact that my old iPad mini could, running iOS7 and with a meager 512MB of RAM, keep more Safari tabs in memory than my new rMini.
As I've explained above, all iPhones, even the iPhone 5, have significantly lower-res screens than Retina iPads. This is why they use a lot less RAM to load / scroll around the same page. With nin.com, this figure doesn't really exceed 350-370 Mbytes for example upon loading - as was also proved today, see below.
I've done some additional tests to find out how Safari behaves - attached Activity Monitor to the process on my iPhone 5 running 7.0.4 after a reset. Only Skype was (auto)started before the experiment; it was allocated 34.2 MBytes of RAM. No other user processes (e.g., mail).
These are the results of loading the entire page (and waiting a bit after it, w/o any scrolling and the like):
(high-res original: http://www.flickr.com/photos/33448355@N07/11388049763/sizes/o/in/photostream/ )
The maximum memory allocation Instuments encountered was around 370 Mbytes; the screenshot above shows 309 Mbytes being allocated for the page.
This is almost the same value as in my own app (see "It has finished loading the entire page at around the 55th second (around tick 110), allocating 335 Mbytes (335597568) in the process" at https://forums.macrumors.com/posts/18502038/, in my yesterday's benchmark result article.)
Interestingly, not even excessive scrolling could crash Safari this time - the RAM usage didn't really exceed 370 Mbytes during my further tests scrolling even wildly (including the quick scroll to the top, which is always very taxing, memory-wise). That is, I haven't encountered crashes. As opposed to loading / reading the same page on any Retina iPad, where it does crash almost all the time. I'll very soon re-do the new, Instruments-based test with my 7.0.4 iPad 3.
1. I don't think it's iOS7 that's the culprit here - the memory starvation problem has always been a huge issue with UIWebView (and, consequently, the stock Safari app.)
2. back in the Windows Mobile times, I used my own 600kbyte test page, with tons of inline, small images (but no videos) to test memory consumption (and other benchmarks like page loading speed). (It's at http://winmobiletech.com/a/1.html ) I'll re-test these browsers with this page and report back.
Yup, as I've also explained in the other, dedicated thread / post at https://forums.macrumors.com/posts/18503087/ , this could be fixed by Apple, purely in software.
Nevertheless, as I don't know why UIWebView is behaving this bad (after all, it's just a "black box" for us non-Apple engineers not having access to the sources), I don't know whether it'd be possible to drastically (with, say, an order of magnitude) reduce its memory usage.
Yes, as it's a non-Retina iDevice and, consequently, uses way less RAM.
So you're arguing that they shouldn't because they haven't? I know we have more and more resources with each new device, but that doesn't mean you need to hog it all when it could be made to be more efficient.
Then they should do that.
Nope... they're highly unlikely to, not shouldn't. I'd be too very happy to see it fixed but, given that they haven't bothered fixing it for 4+ years, I don't have high hopes.
Okay, I thought you were saying "they shouldn't" in the "it's not a problem" sort of vein that you'll get from certain fans around here. They probably won't, though, you're right. And that makes me sad. People make fun of Android when people say that the solution is more RAM or a better processor, but keep silent when it's iOS that has to have that solution for something.
I've finished making another set of tests with the above-linked page. As usual, I reset all devices before the test. Skype was running on some of them (the two iPad 3's, the iPad 2 and the iPhone 5), decreasing the free memory by around 35Mbytes but not having any other effect otherwise.
The results clearly show that Retina iPads, generally, use twice the RAM for both initially loading and, then, scrolling around the same page than non-Retina ones. The difference between non-retina and retina iPhones / iPod touch models, incl. both 3:2 and 16:9 ones, isn't this pronounced the non-retina iPhone 3GS only needed a little bit less memory to initially load the test page than the iPhone 5 or the iPod touch 4G, both sporting retina screens.
It's worth noticing that even this, quite simple page (again, it's 600 kbytes only in size and has almost no Javascript) taxed both Retina iPad 3's very heavily: 80-95Mbyte initial RAM usage and 125...194Mbyte peaks during scrolling. No wonder Safari crashes this easily on anything Retina iPad... As has been pointed out in the previous paragraph, the non-retina iPads, of which I've tested two (adding an 5.1.1 non-JB'n iPad 1 to the bunch), have shown about half the memory usage all the time.
Incidentally, in this test, the iPhone 5 produces pretty much the same figures as the iPad 1 and 2. This means I was right when commenting on the previous, nin.com test, where I wondered why I got significantly larger memory usage figures for the iPhone 5 than for the iPad 2, both having approximately the same number of pixels.
The tests have also shown there is no really noticeable memory consumption difference between the tested iOS versions (4.3.3, 5.1.1, 6.1, 6.1.2, 7.0.4). That is, 7.0.4 doesn't seem to either worse or better WRT memory usage than the currently target-able iOS 4.3.x version. But, again, the test page is pretty much devoid of dynamic content I don't know how these iOS versions would compare with a page with a lot more dynamic scripting or AJAX.
New version of the tester app
I've modified the tester app. The new sources are at https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/WebPageMemoryTester2.zip
Basically, I've added tabulated formatting of the memory reports as follows so that it can be easier to paste into a spreadsheet:
Counter <TAB> Difference between original state (=memory used by UIWebView)<TAB> Total free memory<TAB> (Signed) difference (=delta) between amount of currently free memory and the amount in the previous tick (which is 0.5s in this test too). If it's around 0 (or some thousands at most), the component has finished (de)allocating memory, that is, doing the scrolling / loading / etc.
I've also added other stuff like immediately canceling download from the low memory callback (didReceiveMemoryWarning). Of course, the latter haven't been utilized in these tests as the memory usage hasn't approached the maximal on not even the Retina iPads, particularly not during the initial loading phase. (Again, it's during the scrolling that you'll encounter sometimes vastly higher memory allocations, with larger pages immediately resulting in crashes.)
The detailed results
As with the previous list, I've linked to the full report:
iPhone 5 (iOS 7.0.4, non-JBn, with Skype): 33M for loading; 79M at worst during scrolling - https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/iphone5-ppcmag.txt
iPad 3 (iOS 7.0.4, non-JBn, with Skype): 72M for loading; 167M at worst during manual scrolling; 194M at worst during quick scrolling to the top - https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/ipad37-ppcmag.txt
iPad 3 (6.1.2, JB'n, with Skype): 96M for loading; 125M at worst during manual scrolling; 140M at worst during quick scrolling to the top - https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/ipad3-612-ppcmag.txt
iPad 2, (6.1, JB'n, with Skype): 46M for loading; 72M at worst during manual scrolling - https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/ipad2-ppcmag.txt
iPt4g (4.3.3, non-JBn): 35M for loading; 65M at worst during scrolling - https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/iPt4g-ppcmag.txt
3GS (5.1.1, non-JBn): 26M for loading; 39M at worst during scrolling - https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/3gs-ppcmag.txt
iPad 1 (5.1.1, non-JBn): 46M for loading; 57M at worst during manual scrolling - https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/ipad1-ppcmag.txt
iOS 7 needs more refinement first, then you can have new features afterwards. Besides, it's only beta 2.
Apple is listening to complaints, it's a good thing.
If you turn on list view in the calendar app, your events appear in list mode in Notification Center.
here are my thoughts abt beta 2,
settings crashes a lot, even notification submenu on settings app crashes so much BUT
ios 7.1 beta 2 is so much faster, animations are fast even with reduce motion off.
if u turn on reduce motion, it works awesome specially on iphone 4s.
the phone app still has a slight animation delay before its usable. kinda annoying.
all apps works just fine, atleast for me.
the dark keyboard when u use spotlight is very glitchy, i get lines that appears on my screen when i press the lower bottom keys.
the keyboard rotation lag still persists but not as they were in previous versions.
i am not sure if auto updates still works because everytime i go to app store app , i find new apps updates which then start to download automatically.
siri still sucks
overall i am very happy with it. its so much better than 7.0.4
fardeenah is online now Report Post
settings crashes a lot, even notification submenu on settings app crashes so much BUT
ios 7.1 beta 2 is so much faster, animations are fast even with reduce motion off.
if u turn on reduce motion, it works awesome specially on iphone 4s.
the phone app still has a slight animation delay before its usable. kinda annoying.
all apps works just fine, atleast for me.
the dark keyboard when u use spotlight is very glitchy, i get lines that appears on my screen when i press the lower bottom keys.
the keyboard rotation lag still persists but not as they were in previous versions.
i am not sure if auto updates still works because everytime i go to app store app , i find new apps updates which then start to download automatically.
siri still sucks
overall i am very happy with it. its so much better than 7.0.4
fardeenah is online now Report Post
I hope this fixes the "inadvertent Safari poof" bug (Safari closes suddenly).
Didn't have that on my 4S until iOS 7.
I downloaded it last night. So far, Safari has been stable. Before this update, it would freeze up or "poof" away about 10 times daily.
Siri sucks because it's still limited in functionality and doesn't always work. The latter is the biggest problem. I want to know before using sth that it will work 100% of the time. This is unfortunately not the case with Siri.
I don't think its hysteria - when you have vision problems or are of the older generation, stuff like this that make it more obvious really help.
Bingo. A lot of people just don't think about things of that nature and have a hard time imagining different kinds of people using the phone differently (if they even care to do so to begin with).
I don't think people are being given enough credit, especially older users. A vast majority of what used to be "buttons" are text labels such as edit. How much clearer does it need to be? The only one I can think of which might be a problem at first is the 3 line menu, but everyone who has used an iDevice for the first time and was able to figure out iOS symbols the first time, not sure why it would be any different this time.