I am developing one application in Silverlight for windows phone 7. I am stuck in very common issues which comes in windows phone app however not able to get out of it in any ways. It is memory leak issue which comes during navigation from first page to second, second to first and so on for multiple times.
To solve it, i create one new project having 2 blank pages. Each page has 2 text blocks to print current memory and peak memory and one button to move to next or previous page. When navigate from page 1 to page 2, i make null referance of all 3 things and call gc.collect to destroy the page referance. Same way, while moving from page 2 to page 1, i do the same thing.
I also tried to call gc.collect() in timer for every 500 mili seconds, but still no result. If i remove gc.collect() totally, memory increases in MB so i think it is a must thing.
You're doing it wrong. If you're continuously navigating from page 1 to page 2 then to page 1 again, you're keeping all the previous page instances in the navigation stack. It's bad for the memory management problems you've pointed out, but it's also awful UX as the user will have to press the back button a great deal of times before exiting the app (actually, I'm not even sure it would get past through marketplace certification).
After navigating to page 2, if you want to go to page 1 you need to call NavigationService.GoBack rather than NavigationService.Navigate. It will restore the previously cached instance of page 1 (so obviously you mustn't nullify the references on that page).
On some rare conditions, you might really want to navigate to a new instance of Page 1 instead of the previous one. In that case, call NavigationService.RemoveBackEntry to remove the latest cached page from the navigation stack (you can call that multiple times to clear the entire stack).
Related
I am currently updating my app, and I have been facing a very strange and complex problem for the last few days. The part of the application that is problematic is made of one UITableViewController that is a list of news, and (after you click on a news) a detail view which is in fact a UICollectionView with as many details CollectionViewCells as there are news.
Each of these can have an infinite amount of elements, and are loaded 20 by 20 when the user scrolls to the bottom of the TableView (or to cell that is at the furthest position right on the CollectionView). Also, inside a DetailsCollectionViewCell, there can be another UICollectionView, containing images.
My problem is that after scrolling a few details views, after behaving normally (ie memory is allocated when I change the page, then stabilize until I change the page again, and so on), the memory allocation start to ramp up slowly but steadily, even if I stop doing anything at all. Also, the CPU usage will go to 100-120% and stay there, whatever I do, even, again, if I don't touch anything. After a while, the UICollectionView and the UITableView will not render any animation anymore, thus loosing the paging, and the inertia when scrolling, and overall resulting in a very poor user experience.
The strange thing is, I can observe these behaviours via XCode 5's Debug Navigator, but when I try to use instrument to find the source of the leaks/allocations, the allocation graph is normal, and I get 40-60 MB mem usage, no more, despite still observing the animations/paging problems.
Has anyone already met such a strange behaviour, and can someone help me in finding the cause of all this fuss ? (maybe by fixing Instruments ?)
Thank you all in advance, don't hesitate to ask me for more infos if needed !
I found the solution to my problems in the meantime.
About the difference in Memory usage between Xcode 5's Debug Navigator and Instruments, it was caused by my use of NSZombies. I have the habit of always setting them on, and that just flew off my mind... To remove them : Product > Scheme > Edit Scheme > Diagnostics > Enable Zombie Objects (just unmark it).
The cause of my CPU usage was an animation that was going on indefinitely in the background on multiple pages. The solution was to first of all stop it as soon as it is not seen/useful anymore, the optimise it by changing my approach (I was using CAAnimation and moved on to using UIView's animate function).
I think I might have pulled the trigger a bit too fast here, but hey... if this can help someone later, then it will not be a waste !
I have an Cordova 3, jQM 1.3 application on iOS.
On the first page there is a lot of content. If I navigate away (through the tab/nav-bar) to the second page it displays the page really fast (under one second) because it has very few content.
Every time I navigate back to the first page it takes a long time to load it.
How can I improve that? Other applications don't seem to have such a long loading-time, even on content-heavy pages.
e: I am using changePage function, no transitions, no tap delay.
It depends on your content and your application architecture.
One solution would be to not show all the content, but just a part of it and provide some mechanism for the loading the rest (scrolling down, press a button etc). This would work on single page applications (every page corresponds to its own html file) and on multipage applications (one html file for the whole app).
Another solution is to load the page when your app is launched. This would only work on multipage applications. That would mean that the page is ready, in the DOM tree and available for use whenever you call for it. This has the downside of having a bigger DOM when it isn't actually needed, and it might slow down other aspects of your app.
Finally, try upgrading in jqm 1.4 as it is stated to be faster. Try to produce your content in an efficient way (you might already do that,so just ignore me on this one if you do). Don't output your context in parts (e.g multiple html() in a for loop). Concat big parts of your content as much as you can and output it as a whole (whenever that's possible of course).
what does Recalculate Layout Paint mean in chrome developer tool TimeLine records? and how to improve the page performance by reduce the page Recalculate,Layout and Paint's count? can give some suggestion?thanks
Basically, they're your browser figuring out how to draw the changes that you made to the page.
Don't worry about getting rid of them -- if you did that, your site would be static.
However... ...if you want to do something that IS useful for performance, which does have to do with reflows and repaints, then batch your changes together.
Lets say that you got a job at Twitter.
And your job is to write the next version of the window that adds each twitter post to the screen.
If a user gets 250 new tweets in their timeline, and you add each one in a loop, one after the other, the browser is going to slow way down, because every time you add one, it will have to reflow (move things around to make space for the thing you added) and repaint (style everything that was affected by the addition).
A better way of doing it would be to build the list of new tweets together off-DOM (ie: with elements that aren't actually on the page right now), and then add them all at once.
This cuts down on the number of times that a browser has to figure out where everything needs to go.
#Fabricio -- Micro-optimizing might not be great, but appending hundreds of browser elements in a loop, versus putting all of them in at the same time can make a big difference.
Just ask the Twitter guys, who weren't bothering to cache their jQuery objects.
Here's a very handy list of properties and methods that trigger the layout (reflow) of a page:
http://gent.ilcore.com/2011/03/how-not-to-trigger-layout-in-webkit.html
You want to minimize these calls as much as possible -- especially in situations where performance is critical, such as during the scroll event, or when animating large blocks of content.
You can use the "Profiles" tab and "Audits" tab to detect the performance of your code. The will give you a report about your codes.
You can reduce the page Recalculate,Layout and Paint's count by many ways.
Append many child at one time.
Hide elements before change them.
Give images and other elements height and width.
I have a main page in an app that has significant issues when the page is navigated to. I finally narrowed the issue when I added a static class that can be used to write trace information, and time elapsed to the debug out put. I have discovered that when this main page of the app is navigated to (always via hardware back, or nav.goback()) has a greater than 4.5 second delay between the OnNavigatedTo and the Loaded event. At that point, I cannot see any other places in managed code where I can add trace statements to drill down further.
Any suggestions on troubleshooting?
I would try eliminating (commenting out) various items from your XAML until the problem is greatly reduced or eliminated. Likely candidates are databound fields, listboxes, pivot controls with too many items, pivots within panoramas, Converters, etc.
Once you find the source of the slowdown you can begin to work on the cause.
Usually, when a View requires a lot of bindings, or some UI Elements like a Bing Map, it takes a "while" to load (like between half a second and a second).
I don't want a delay between a "tap" action (like tapping an element on a ListBox) and the navigation action (displaying a new page).
I don't mind displaying the page progressively. For example, for a Bing Map, I don't mind displaying a black page with only a title, and a second later, having the Map appear.
What are the best practices ? It could post a sample if i'm not clear enough
edit: I'll keep the question open for a while, so other can answer. Thanks Matt and Mick for awesome answers. I'm already working on some improvements. The major one being binding my controls after the page loaded.
It's expected on resource constrained devices that non trivial actions will take at least a little time to execute.
The most commonly recommended best practice for dealing with this is to use animations to give the user the impression of perceived performance. This has been a recurring recommendation throughout the CTP and Beta phases by the product team and in presentations at Mix 10 and Tech Ed 2010.
Page transitions are a common approach to this.
Discussed here by Kevin Marshall, prior to inclusion in the November toolkit.
WP7 – Page Transitions Sample
And here, referencing the control in the toolkit.
Transitions for Windows Phone 7
There are also a number of very basic optimisations you can do that will give you some bang for a little effort.
don't name controls that you don't reference in code
use background worker to load any data to avoid impact the UI thread (already busy loading your page) and fire this off after the page is loaded (disable any controls not usable in leui of this) (Phạm Tiểu Giao - Threads in WP7)
use httpwebrequest over webclient for the same reason (WebClient, HttpWebRequest and the UI Thread on Windows Phone 7)
I would also reiterate Matt's suggestion for not loading controls that aren't used initially.
If you decide to go the extra mile, there is more you can do to optimise page loading. These two posts are worth absorbing in that regard.
Creating High Performing Silverlight Applications for Windows Phone
WP7 Development Tips Part 1 - Kevin Marshall's Epic Work Blog for Awesome People
If using Listboxes, also familiarise with Oren Nachman and David Anson's
WP7 Silverlight Perf Demo 1: VirtualizingStackPanel vs. StackPanel as a ListBox ItemsPanel
Keep a low profile LowProfileImageLoader helps the Windows Phone 7 UI thread stay responsive by loading images in the background
Never do today what you can put off till tomorrow DeferredLoadListBox (and StackPanel) help Windows Phone 7 lists scroll smoothly and consistently
and be sure image sizes are optimised for their display size.
My suggestions/recommendations:
Create and navigate to the new page as quickly as possible.
Display the page with placeholder content while it loads (if appropriate).
Give an indication that something is happening while the page loads. An indeterminate progress bar (use this one) is the convention on the platform.
If it's not possible to use the page until all controls are loaded, then prevent access to the page. A semi-transparent object displayed over the entire page is a common technique to not only prevent touching of controls but also to indicate that they can't yet be touched.
If possible/practical set the size of the items in xaml/code to prevent relayout due to resizing once an item is loaded.
Try delay loading of items which aren't on the screen initially to get the perceived total load time down.
and finally:
Optimize everything to get the load time down and the application as responsive as possible.