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
Related
it's all start from a lot of warnings about the width of collectionView cells,
That was written to console every time I press home button.
I thought it's something with size of the cells and tried to fix it.
Only after some testing, I notice that viewDidLayoutView is called with wrong view.bounds, and that make the collectionView cell bigger(in width) than collection view.
For now, my fix is to check if app is on background state and ignore viewDidLayoutView.
why it's happen only in iPad and not on iPhone ?
it's whirred that only now I saw this happening. it's something new in iOS ?
what is the right way to handle this ? I don't use auto-layout
its calling with wrong bounds and I don't want to calculate all cells frames just for the user to return to the same orientation.
I feel like I'm missing something very basic here OR there is some change on iOS that I'm not aware.
why it's happen only in iPad and not on iPhone ?
Because when you click Home on an iPad and the app goes into the background, the runtime takes two snapshots, one in each orientation, to use in the App Switcher interface (and in preparation for when the app comes back to the front). That means it has to rotate the app, which triggers layout, and so your viewDidLayoutSubviews is called.
it's whirred that only now I saw this happening. it's something new in iOS ?
what is the right way to handle this ? I don't use auto-layout
its calling with wrong bounds and I don't want to calculate all cells frames just for the user to return to the same orientation.
I feed like I'm missing something very basic here OR there is some change on iOS that I'm not aware.
Well, iPads have been behaving like this for quite a long time. It isn't my job to explain why you haven't noticed. Basically you should not be doing anything time-consuming in viewDidLayoutSubviews.
for now, my fix is to check if app is on background state and ignore viewDidLayoutView
That's perfectly reasonable. I do the same sort of thing. For example (this is a different method, but it's the same idea):
override func viewWillTransition(to size: CGSize, with tc: UIViewControllerTransitionCoordinator) {
if UIApplication.shared.applicationState == .background {
return
}
// ...
}
Be warned, however, that if you are doing manual layout and you don't do it when the app when goes into the background, your App Switcher snapshots may look wrong. Also, the fact that you are not using autolayout is a red flag. You should probably use it.
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'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
I'm making a dictionary app, which allows user find a word definition by touch the word in screen, and there will be a magnifier on screen and follow user's finger. I have implement it by take a screenshot of view and assign the image to maginifer image view, which is a UIImageView, however, in order to take a screenshot, the method [self.layer renderInContext:c]; cost too much time, is there any other way to do it ?maybe openGL will help?
after profiling my app with instruments->core animation, it is only 9 fps showing magnifier, but it will 30 fps if showing the system default magnifier in a UITextView, I don't know why the system is so fast
You can use exact same view in magnifier view, and change position to visible words.
There are new methods in iOS 7 that are highly optimized :
– snapshotViewAfterScreenUpdates:
– resizableSnapshotViewFromRect:afterScreenUpdates:withCapInsets:
– drawViewHierarchyInRect:afterScreenUpdates:
However they are not available in previous versions.
I am creating an app with an UIViewController which displays other UIViewControllers with the MPFlipTransition inside it. It's like a little book on iPad.
The UIViewControllers inside are created each with xibs with 4-5 UIImageViews inside and some of those images are animated with CoreAnimations ([UIView animateWithDuration] blocks)
I remove all the animations in the viewDidDiseappear function with the QuartzCore function removeAllAnimation on each animated layer.
But when I'm testing the app on an iPad 3, it works properly, but on iPad 2 it crashes at about the 8th page change.
I've made a profiling with Instruments and found that the real memory usage was increasing everytime I turned the page (when the MPFlipTransition appears). But even if I remove from the superview the previous views, the real memory usage is not decreasing. I thinks that it created the crash on the iPad 2 because the crash come when the real memory usage is passing the 400 Mbytes value (and the iPad 2 has only 512MB...).
What do you think about this problem ? Any help ? I'm using ARC for memory management...
Thanks for you help ! Feel free to ask if any need of precisions...