Platform: All(Android/ios/Windows etc..)
Problem 1:
The current implementation does not cleanup on the deletion of the scope. This leads to a memory leak. The spinning animation keeps on running even if the spinner is not in the dom anymore. The animation should be stopped when the scope gets destroyed. This degrades scrolling performance too.
Once they have been displayed and then hidden again they still remain in the DOM animating and eat up CPU. After a while on Android devices it heats the phone up and runs the battery down very quickly, especially if you have loaded the animated SVG in multiple views / places while using the app.
Problem 2:
The spinner in combination with the infinite-scroll directive.
It is not sufficient to have the spinner translated out of view. (Why this solution was chosen instead of opacity?). The spinner is still getting animated and degrades scrolling performance on iOS devices a lot. Even if out of view.
I simply replaced the SVG spinner with a .gif loader:
$ionicLoading.show({
template: "<span class='loader'></span>"
});
Not the best solution but at least it works.
Related
I tried to implement the lazy loading solution for UIScrollView with paging enabled, as in the PageControl example from Apple. It seems to work fine, the only problem is that as the user scrolls past the 50% of the page, there is this short hitch as the content of the next page is loaded (obviously because loading the next ViewController takes some time and it seems to happen on the main thread).
Is there some way to make the scrolling seem more smooth that would work no matter how fast the user scrolls ?
You need to make sure that anything which takes time happens asynchronously. The techniques for this will vary based on what kind of content you're loading or what sort of drawing you're doing that causes the delays. Try to load images in the background, do custom drawing in the background, use operations or gcd to break up large tasks into smaller chunks that can happen concurrently, etc.
You should be lazy loading the surrounding pages so that they're already loaded when the user scrolls.
So if the user scrolls to page 2, load pages 1 and 3 (if they aren't already)
I have an AJAX heavy website. There's hundreds of buttons that momentarily put up an animated loading GIF when the server is processing a request.
I noticed that my site is sluggish after using it for several minutes. The animated GIFs play at lower framerate. They sometimes even stop animating. Hover effects on buttons have a noticeable lag. Is it possible that these hundred animated GIFs are still locking up the CPU even while they're hidden (style="display: none")? At most, only a few GIFs are visible at any point in time.
Things that are hidden using style-sheets still exist in, and are resolved by the browser (and can therefore be manipulated by script), they are just not displayed to the user.
This is in contrast to when controls are marked as .visible=false in which case they are not marked up in the browser (and therefore cannot by manipulated by script)
I am working on an OpenGL application for the iPhone...
My app has only 2 views:
An OpenGL view and, as a subview for the OpenGL view, a view with the sole purpose of catching touch events...
The problem is that after about 10-15 minutes of keeping the app running on the device, I get a big (0.5s-1s) delay between every touchesMoved:withEvent: call
The animation runs smooth, and CPU usage is also not the problem (10% at most)
I have no idea what might be causing this
That is weird, eh.
This happens ON THE DEVICE right? When you are not running tethered from XCode?
I would guess you are using up a lot of memory, either a leak or just in some way using up more and more memory as time goes on.
Are you familiar with the various memory tools to watch what is going on?
Also, what about this: launch a few other large apps that remain in the background. Run your app until the problem exhibits. Then, kill the other apps. Does the problem suddenly go away? If so that would suggest you're low on memory.
Would be interested to hear.
I've got an app I'm working on where we handle a LOT of images at once in a scrollview. (Here's how it looks, each blue block being in image on a scrollview expanding to the right: http://i.stack.imgur.com/o7lFx.png) So to be able to handle the large strain doing this puts on memory. So I've implemented a bunch of techniques such as reusing imageviews etc which have all worked quite successfully in keeping my memory usage down. Another thing I do is instead of keeping the actual image in memory (which I of course couldn't do for all of them because that would run out of memory very quickly) I only keep the image's filepath in memory and then read the image when the user scrolls to an area of the scroll view near that image. However, although this is memory efficient, it's causing a LOT of lag in the scrollview because of the fact that it has to constantly read images from the disk. I can't think of a good solution on how to fix this. Basically right now the app draws to the screen only the visible uiimageviews and while the user scrolls the app will look to see if it can dequeue another imageview so it doesn't have to allocate another one and at that point it reads the image into memory, but as I said it's causing the scrolling action to be very slow. Any ideas on a strategy to use to fix this? Does anyone know what the native photos app does to handle this kind of thing? Thanks so much!
I can suggest you a simple solution to balance both the memory and the computer processing. You only keep small images like thumbnails in memory and only keep about 20 of them. One project that I am doing, I keep 20 thumbnail images (100 x 100) recently accessed, which doesn't cost a lot of memory. I believe that it costs about 200 kb all the time but comparing to a general available memory. I think it is good enough.
It also depends on your use case : if user scroll really fast and you don't know when will they go. You can have even smaller images than the thumnail and when you show it on the UIImageView, you resize it to fit. When user stops scrolling for a while. You can start loading bigger images and then you have a nicer images. User may not even notice about the process
I don't think there is a solution that can be fast and using as less memory as possible. Because we have memory, maybe not big but have enough if we use it smartly.
Slow scrolling performance might mean that you're blocking the main thread while loading images. In that case, the scrolling animation won't continue until the images are loaded, which would indeed cause pretty choppy scrolling performance.
It would be better to lazily load requested images in the background, while the main thread continues to handle the scrolling animation. A library that provides this functionality (among other things) is the 'three20' library. See the Tidbits document, and scroll down to the bottom where the 'TTImageView' class is described.
I had a similar issue with a PDF viewer, The recommended way to do this is to have as low a res image as you can get away with and if you are allowing the user to blow the image up/zoom, then have two versions or three versions of that image increasing the res as you go.
Put as much code as you can get away with in the didDecelerate method (like loading in higher res images like vodkhang talks about), rather than processing loads in didScroll. Recycle Views out of scope as you have said. and beware of autoreleased Context based Image Creation functions.
Load images in on background threads intelligently (based on the scrollView Offset position and zoom level), and think about using CALayer/Tiled Layer drawing for larger images.
Three20 (an open source iOs lib) has a great Photo Viewer that can be subclassed, it has thumbnail navigation, large image paging, caching and gestures right out of the box.
I've heard that OpenGL ES and standard iPhone UI controls don't play well together, but I'm wondering if anyone knows why, and what the effects are? I'm writing an OpenGL based game, and the view is loaded from a nib file with ui controls, and it seems to work ok, but the game is really simple at this point... does using ui controls cause some kind of performance hit?
UI events momentarily pause timers, like when scrolling a tableview. You can get around this by using the common runtime mode when creating a timer. It may slow down your rendering if you have a lot of layers because they all need to get redrawn every-time you refresh. So if your game runs at 60fps it will also redraw everything on top of the GLView, like UIImageViews, buttons etc. 60 times a second, which is a huge waste. It might not make a huge impact on your frame rate but it may make the device run hotter and drain the battery faster. Its best to draw your HUD using OpenGL, but it depends on the situation. For something that will be displayed only for a short time, like a menu I think you can get away with it.
Theres nothing wrong with it, its just wasteful.