I've a native iOS screen with UITableView inside that displays some article. Some cells in this table display article image, title, author, comments, etc. But there is a single cell with UIWebView inside that displays article content. This cell has dynamic height depending on the content size. Article content goes from the server as html string in JSON response and may contain images, videos and other things that supports HTML format. I can edit this string using regular expressions depending on some requirements (for example increase font size depending on app settings). Here is an image representing my UI structure:
The problem is that once the article content is very large, UITableView cell with UIWebView inside becomes also very large in height and this leads to memory crash. In my case this crash happens only on iPhone 6 Plus. On all of the other devices including iPhone (5, 5S, 6), iPad (2, 3, 4) (and probably other devices that supports iOS 7) app works correctly. As I suspect the reason is that iPhone 6 Plus has a high resolution screen and only 1 Gb of memory. So rendering the same content with the same amount of memory as in other devices, but in larger resolution, leads to memory crash.
I've created two test applications with UI as in the image below:
Both apps load the same HTML content in a single UIWebView. There is no other ui or logic in both apps.
In case a) all works correctly, scroll indicator appears and only visible content are rendered. When I'm scrolling fast, I can see white space that after a moment replaces with rendered content.
In case b) UIWebView stretches to fit content size. Test app is crashes (as my real app). As I suspect in this case even invisible content rendered and that leads to memory crash.
So my question is:
How can I fix this bug without scrolling inside UIWebView? Only UITableView should be scrollable
Make your UITableViewCell reusable. i-e(UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:#"Cell"];).
one thing very important don't use [UIimage imagenamed:#"Imagename.jpg"] which leads you to a memory crash, you can use [UIImage imageWithContentsOfFile:[[NSBundle mainBundle] pathForResource:#"Imagename" ofType:#"png"]];.
I hope it might help.
You can give webview constant height. it has scrollviewer inside. otherwise it is really hard to render large content at once. if you give webview constant size(max value) white spaces will be removed too.
edit: webviews own scrollview should work fine with tableviews scrollview bu i am not sure
Related
I have a UICollectionView whose cells each have an AVPlayerLayer, all playing a video at the same time. About 9 cells fit on the screen at a time and it's pretty laggy so I need ways to boost the performance to achieve smooth scroll. There's a few things I've tried already:
1) Each cell has only one instance of AVPlayer. It doesn't get created, instead, player.replaceCurrentItemWithPlayer is called when the video url changes.
2) Because I'm using ReactiveCocoa, it's trivial to skip repeat urls to avoid playing the same video twice.
What else can I do to speed up the scroll and performance?
First I want to say it's a bit crazy to see several players in action at the same time: it's a heavy task of rendering anyway.
As far as I know, simply scaling/re-framing the video to smaller size doesn't make it less content to render: if you have a 100x100 picture to render and you render it in a frame of 10x10, it still consumes the same amount of memory as the original picture would consume; same thing goes for videos. So, try to make your video assets having similar resolution as the frame where you would present them.
Store each cell in an NSCache or NSMapTable using the NSIndexPath as the key for each; then, whenever you need a cell, call one directly from the cache or map table.
Obviously, you'll have to create all the cells at once, but you'll get the same scrolling performance as you do with nothing in the cells at all.
Need sample code?
Here's my latest iteration of a perfectly smooth-scrolling collection view with real-time video previews (up to 16 at a time):
https://youtu.be/7QlaO7WxjGg
It even uses a cover flow custom layout and "reflection" view that mirrors the video preview perfectly. The source code is here:
http://www.mediafire.com/download/ivecygnlhqxwynr/VideoWallCollectionView.zip
Unfortunately, UIKit will hit bottlenecks and drop frames when put under pressure for this use case. If you can muster refactoring code to use Facebook's AsyncDisplayKit / then this would be your best bet.
For objective-c / this project here is a good reference.
https://github.com/TextureGroup/Texture/tree/master/examples/ASDKTube
- (ASCellNode *)tableNode:(ASTableNode *)tableNode nodeForRowAtIndexPath:(NSIndexPath *)indexPath
{
VideoModel *videoObject = [_videoFeedData objectAtIndex:indexPath.row];
VideoContentCell *cellNode = [[VideoContentCell alloc] initWithVideoObject:videoObject];
return cellNode;
}
there is swift code available if you dig deep enough in github.
I have been developing my app for iOS8, and haven't really had any issues regarding the scrolling speed. The moment I have upgraded to iOS9 the collectionView became very jumpy and staggering. I cant point out to any specific reason why. In my collection view, I have items with images that uses 3rd party library (SDWebImage) and I also use a custom layout library to achieve double column layout. Is there any obvious reason why this could be happening?
We were experiencing the same issues with collection views with iOS 9. The cells also contained images from SDWebImage including animated GIFs. It turned out not to be an issue with SDWebImage but with auto layout. If you have layout constraints with <= or >= inside your UICollectionViewCells (particularly on UITextViews, but still visible on UILabels, iOS 9 just chugs. Hope this helps someone.
In this case the problem was about handling fallback images on the imageView.
Briefly, each item in the CollectionView has an UIImageView. Each UIImageView has a fallback image in case the actual image doesnt resolve (the url is broken for example). So, the way these fallback images set was wrong in my app! I have set images every time a collectionview item is rendered in the viewport.
UIImageView * fallback = [UIImage imageNamed:#"imageName"];
was called everytime, which makes the scroll staggered. Interestingly it wasnt an issue on iOS8 but only in iOS9.
So when I started reading from a precreated dictionary of images instead of creating a new one every time, the scroll view started become smooth again.
Hope this helps to those having the same issue.
I have an app with:
custom topbar and bottombar,
horizontal scrollview that contains 5 other vertical scrollviews
the scrollviews are filled with a grid of images (no collection view)
a view that comes in from left when you grab it (google play store style)
So i have some views in there and i don't make use of interface builder.
If i launch my app on my iPhone 4s (not in debugging mode) my app takes almost 10 seconds to load, so my splash screen is up for 10 seconds.
Why does my app take so long to load up?
I tested it and it takes only 1.3 seconds to load all the images from the memory.
Is my app taking 8.7 seconds only to load my layout?
I wrote all the layout by code, with no use of constraints, i assign the frame sizes and positions for all the views in viewWillappear() method of the viewController.
How can i make it faster to load at start? where am i doing wrong? can it be layout's loading fault?
Thank you
Instruments revealed that my error was in assigning a font that i removed from the resources to a UILabel with the method
button.titleLabel?.font = UIFont(descriptor: UIFontDescriptor(name: "MyFont", size: 21), size: 21)
this line was the problem, it was spending a lot of time looking for the font that was not there.
so i replaced that line with:
UIFont.systemFontOfSize(21)
Hope this helps someone
I am developing an App with an UICollectionView in one ViewController.
This CollectionView it's a gallery with 3 images in each row.
I get the images from the server in groups of 30 pictures, first url and code, and when the cell is going to be displayed in cellForItemAtIndexPath I use SDWebImage Library to download those pictures asynchronously. Every 30 pictures I call again the web service and I get 30 pictures more sending the request with limit and offset. This could happen 100 times, there are profiles with 3000 pictures.
Well, my problem comes one I launch the app in my iPhone 4, after some fast scrolling I start getting Received Memory Warnings and after some warnings the app crashes. When I make the same test in the Simulator, nothing bad happens.
Each time I download 30 pictures I add the result array to the NSMutableArray *data property which handles the CollectionView data and reload the collectionView. I have tried to use Instruments with allocations, but it is very difficult for me to understand what is happening.
This is the code I use to create the cells
-(UICollectionViewCell *)collectionView:(LZProfileImagesCollectionView *)aCollectionView cellForItemAtIndexPath:(NSIndexPath *)indexPath {
if(aCollectionView == self.imagesCollectionView){
if([self.data count] - 12 == indexPath.row){
self.photoOffset += 30;
[self loadUserData];
}
LZProfileCollectionViewCell * cell = (LZProfileCollectionViewCell *)[imagesCollectionView dequeueReusableCellWithReuseIdentifier:ImageCollectionCellIdentifier forIndexPath:indexPath];
Image *image =(self.data)[indexPath.row];
[cell configureCellWithImage:image];
return cell;
}
return nil;
}
And in the LZProfileCollectionViewCell cell I have this one:
-(void)configureCellWithImage:(Image *)image
{
[self setNeedsDisplay];
// Imagen
NSString *imageUrl = [kBaseURL stringByAppendingString:image.imageStringUrl];
[self.pictureImg setImageWithURL:[NSURL URLWithString:imageUrl] placeholderImage:[UIImage imageNamed:kDefaultLoadingImage]];
[self.pictureImg setContentMode:UIViewContentModeScaleAspectFit];
}
I have taken setImageWithURL from SDWebImage
After 3 minutes I get this snapshot in the Instruments(Statistics)
Thank you in advance
Well, you are caching every image in an array, so once you cache so many images you are eventually going to run out of memory. It doesn't happen on the simulator because the simulator has as much memory as the computer running it, so it is unlikely to ever run out of memory, a real device however will run out very fast. I'd handle the memory error yourself and empty the array, to free up new space for new images. Or better yet create your own caching mechanism to hold and clear images that haven't been in view for a while, either way you have to have some way to dump images after you hit a certain threshold.
In the method – didReceiveMemoryWarning you should free some memory of the array where you are stored the images. Maybe the first images that you are not displaying stored it a second array like an auxiliar array.
This is probably happening because a lot of UIImage objects end up in memory. You could instead cache this on disk. AFNetworking has a nice UIImageView category that does all of this automatically.
If you're not saving the Images in your dataSource array, then they're probably being retained somewhere else, which is a bug.
Also, make sure you're dequeuing cells and not creating new ones.
I've experienced similar situation so I'm replying on this issue though the reason seems a little different from yours.
I have a horizontal UICollectionView inside UITableViewCell. When I scroll UICollectionView right and left rapidly, the entire UI(even a home button) stops and after a while the app crashes with the message "Message from debugger: Terminated due to memory issue" on the console even without didReceiveMemoryWarning call.
I tested it with a UICollectionViewCell without any UI components but no changes. XCode Profile tool says it's actually keep allocating memory during the UI's stopped until it crashes even without any UI components in it.
The only suspicious point was that I was setting the width of a UICollectionViewCell's subview(custom UIView pinned to all superview edges) with AppDelegate.window.size.width * 0.35 to determine UICollectionViewCell's width and it was a float value like 130.25
When I hardcode this value to 130, all the crashes are gone. I think something was happening under the hood with this vague value of 130.25 and it's determining the width as 130 or 130.25 occasionally.
So I'm using CGFloat(Int(AppDelegate.window.size.width * 0.35)) now and everything's fine.
This is a curious one.
I have an IBOutlet UIScrollView playScrollView whose height is exactly 1/3 of it's contentSize's height. The app is in landscape. I call this code...
[playScrollView scrollRectToVisible:CGRectMake(0.0f, page * PLAY_VIEW_PAGE_HEIGHT,
480.0, PLAY_VIEW_PAGE_HEIGHT)
animated:animated];
... (the int page ranges from 0 to 2) to start on page 1 (displaying the middle third) then go up or down as needed when the user presses buttons.
This works fine for iOS4 both device and simulator, and has been live on the app store for months with no problems. Even iOS5 devices are fine with existing builds, it was only when the app was recompiled for iOS5 that it stopped working correctly on iOS5 devices.
Since updating to XCode 4.2, This doesn't work for iOS5. It goes one page too low, showing the bottom page when it should show the middle. I can get the code to work for iOS5 (device and simulator) by changing page to (page-1)...
[playScrollView scrollRectToVisible:CGRectMake(0.0f, (page-1) * PLAY_VIEW_PAGE_HEIGHT,
480.0, PLAY_VIEW_PAGE_HEIGHT)
animated:animated];
...but of course this breaks iOS4, which works fine with the old code, but gets stuck one page too high with this new code. iOS4 and iOS5 are exactly PLAY_VIEW_PAGE_HEIGHT out-of-step (288 pixels, a third of the height of playScrollView). The same thing happens if I use setContentOffset: instead.
One other curious thing, probably the key to this. If I don't do the scrollRectToVisible at all, then iOS4 sits at the top of playScrollView, wheras iOS5 shows the middle third, (ie PLAY_VIEW_PAGE_HEIGHT pixels down).
I could detect the iOS and use different code for each, but that's a horrible kludge. If it's an iOS5 bug and they fix it in a future release, that would break the live app.
Has anyone any ideas, or noticed anything similar? Thanks.