petvas
macrumors 603
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.
Grolubao
macrumors 68000
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...
adnbek
macrumors 68000
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.
Michael Goff
Suspended
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.
Michael Goff
Suspended
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.
tigres
macrumors 601
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.
dannyyankou
macrumors P6
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
Jnesbitt82
macrumors 6502
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.
petvas
macrumors 603
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.
pacmania1982
macrumors 65816
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).
dcp10
macrumors 6502a
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.