Best practice tips for delivering apps to Windows Phone with 256 MB - Revision history

Hamishwillee: Hamishwillee - Add link to * [http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh855081(v=vs.105).aspx Developing apps for lower-memory phones] (Dev Center)

2012-12-12T04:03:55Z

Hamishwillee - Add link to * [http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh855081(v=vs.105).aspx Developing apps for lower-memory phones] (Dev Center)

Hamishwillee: Hamishwillee - Addition to article of: Category:Windows Phone 7.5

2012-11-30T05:15:21Z

Hamishwillee - Addition to article of: Category:Windows Phone 7.5

Hamishwillee: Hamishwillee - Add link to WP developer blog

2012-05-07T23:50:56Z

Hamishwillee - Add link to WP developer blog

Hamishwillee: Hamishwillee - Bot update - Fix metadata etc

2012-04-24T00:47:33Z

Hamishwillee - Bot update - Fix metadata etc

Hamishwillee: Hamishwillee - Add link to video topic

2012-03-26T21:42:25Z

Hamishwillee - Add link to video topic

Kiran10182: Kiran10182 - FA template added

2012-03-04T08:34:16Z

Kiran10182 - FA template added

Justin.Angel: Justin.Angel - fixing minor issue where the rendered text was "{{1}}}" due to equals sign in icode.

2012-02-29T03:54:14Z

Justin.Angel - fixing minor issue where the rendered text was "{{1}}}" due to equals sign in icode.

Rebloor: Rebloor -

2012-02-29T02:22:20Z

Rebloor -

Hamishwillee: Hamishwillee - /* Tip #9 - Consider disabling Disable page transitions */ - fix typo

2012-02-28T04:08:45Z

Hamishwillee - - Tip #9 - Consider disabling Disable page transitions: - fix typo

Hamishwillee: Protected "Best practice tips for delivering apps to Windows Phone with 256 MB": Nokia-official ([edit=sysop] (indefinite) [move=sysop] (indefinite))

2012-02-28T03:59:54Z

Protected "Best practice tips for delivering apps to Windows Phone with 256 MB": Nokia-official ([edit=sysop] (indefinite) [move=sysop] (indefinite))

@@ Line 1: / Line 1: @@
-[[Category:Windows Phone]][[Category:Optimization]]
+[[Category:Windows Phone]][[Category:Optimization]][[Category:Windows Phone 7.5]]
 {{FeaturedArticle|timestamp=20120304}}
 {{Abstract|This article provides recommended best practices for preparing your Windows Phone apps for the [http://www.developer.nokia.com/Devices/Device_specifications/Lumia_610/ Nokia Lumia 610] and other 256 MB Windows Phone devices.}}
@@ Line 8: / Line 8: @@
 * [[Opting your app out from Windows Phone with 256 MB]]
 * [[Video playback guidance for Nokia Lumia 610]]
 * [http://windowsteamblog.com/windows_phone/b/wpdev/archive/tags/performance/ Windows Phone Developer Blog] (Performance)
 ** [http://windowsteamblog.com/windows_phone/b/wpdev/archive/2012/03/07/optimizing-apps-for-lower-cost-devices.aspx Optimising apps for lower cost devices]
@@ Line 437: / Line 438: @@
 For more on how to diagnose memory leak on WP7 see Windows Phone's blog [http://windowsteamblog.com/windows_phone/b/wpdev/archive/2012/02/01/memory-profiling-for-application-performance.aspx Memory Profiling for Application Performance].
-The recommended best practice is to know how to [http://blogs.msdn.com/b/wpftesting/archive/2009/03/21/finding-managed-memory-leaks-in-wpf-and-silverlight-applications.aspx Find Managed Memory Leaks in WPF and Silverlight applications], profile your app during heavy use and listen to your users regarding overall app performance. If users are reporting "the app is getting 'tired' as time progresses" or "after I use the app for an hour the app always crashes" those are telltale signs of a memory leak. Look at what's on the managed heap during a specific period of time and determine if it actually should be there.[[Category:Windows Phone 7.5]]
+The recommended best practice is to know how to [http://blogs.msdn.com/b/wpftesting/archive/2009/03/21/finding-managed-memory-leaks-in-wpf-and-silverlight-applications.aspx Find Managed Memory Leaks in WPF and Silverlight applications], profile your app during heavy use and listen to your users regarding overall app performance. If users are reporting "the app is getting 'tired' as time progresses" or "after I use the app for an hour the app always crashes" those are telltale signs of a memory leak. Look at what's on the managed heap during a specific period of time and determine if it actually should be there.

← Older revision		Revision as of 05:15, 30 November 2012
Line 437:		Line 437:
	For more on how to diagnose memory leak on WP7 see Windows Phone's blog [http://windowsteamblog.com/windows_phone/b/wpdev/archive/2012/02/01/memory-profiling-for-application-performance.aspx Memory Profiling for Application Performance].		For more on how to diagnose memory leak on WP7 see Windows Phone's blog [http://windowsteamblog.com/windows_phone/b/wpdev/archive/2012/02/01/memory-profiling-for-application-performance.aspx Memory Profiling for Application Performance].

−	The recommended best practice is to know how to [http://blogs.msdn.com/b/wpftesting/archive/2009/03/21/finding-managed-memory-leaks-in-wpf-and-silverlight-applications.aspx Find Managed Memory Leaks in WPF and Silverlight applications], profile your app during heavy use and listen to your users regarding overall app performance. If users are reporting "the app is getting 'tired' as time progresses" or "after I use the app for an hour the app always crashes" those are telltale signs of a memory leak. Look at what's on the managed heap during a specific period of time and determine if it actually should be there.	+	The recommended best practice is to know how to [http://blogs.msdn.com/b/wpftesting/archive/2009/03/21/finding-managed-memory-leaks-in-wpf-and-silverlight-applications.aspx Find Managed Memory Leaks in WPF and Silverlight applications], profile your app during heavy use and listen to your users regarding overall app performance. If users are reporting "the app is getting 'tired' as time progresses" or "after I use the app for an hour the app always crashes" those are telltale signs of a memory leak. Look at what's on the managed heap during a specific period of time and determine if it actually should be there.[[Category:Windows Phone 7.5]]

@@ Line 8: / Line 8: @@
 * [[Opting your app out from Windows Phone with 256 MB]]
 * [[Video playback guidance for Nokia Lumia 610]]
 }}
 {{ArticleMetaData <!-- v1.2 -->

@@ Line 388: / Line 388: @@
 If we run this app and click our button many times in short and rapid succession we will see the following memory footprint:
-[[File:Windows_Phone_Sound_Memory_Footprint.png]]
+[[File:Windows Phone Sound Memory Footprint.png]]
 You can see that even though {{Icode|SoundEffects}} aren't being reused or disposed, the Garbage Collector whenever it does a full GC run will dispose of the {{Icode|SoundEfffect}}. This situation might be acceptable for 512 MB devices. But this is especially bad for 256 MB devices since this gradual accumulation of memory could easily pass 60 MB before getting garbage collected. In our simplified example we had almost no visuals and no actual game logic we've approached 40MB~ of memory usage. Not disposing or reusing {{Icode|SoundEffects}} becomes much more noticeable in terms of overall memory footprint when your working set is just 60 MB.

@@ Line 7: / Line 7: @@
 * [[Techniques for memory analysis of Windows Phone apps]]
 * [[Opting your app out from Windows Phone with 256 MB]]
 }}
 {{ArticleMetaData <!-- v1.2 -->

@@ Line 213: / Line 213: @@
 </code>
-By setting {{Icode|IsHitTestVisible=False}} you're essentially saying that the Bing Maps control is static. By disallowing user navigation in the Bing {{Icode|<Maps />}} control you're essentially stopping the excessive image loading this control might perform. The only images that will get loaded are for those initial properties set by you.
+By setting {{Icode|IsHitTestVisible}}={{Icode|False}} you're essentially saying that the Bing Maps control is static. By disallowing user navigation in the Bing {{Icode|<Maps />}} control you're essentially stopping the excessive image loading this control might perform. The only images that will get loaded are for those initial properties set by you.
 However, if you need to allow the user to navigate in the map, that quick and dirty won't work. For that use-case it's recommended you use the {{Icode|BingMapsTask}}. The {{Icode|BingMapsTask}} will open up a separate app and tombstone your app when memory gets tight. So make sure to build tombstoning support into your app.

@@ Line 309: / Line 309: @@
 The recommended best practice is for app developers to review any long list with images, memory profile those pages and make UX changes where required. A strong first step would be to memory profile ListBox replacements that use Data Virtualization, such as [http://blogs.msdn.com/b/ptorr/archive/2010/10/12/procrastination-ftw-lazylistbox-should-improve-your-scrolling-performance-and-responsiveness.aspx Peter Torr's LazyListBox] or [http://blogs.msdn.com/b/delay/archive/2010/09/08/never-do-today-what-you-can-put-off-till-tomorrow-deferredloadlistbox-and-stackpanel-help-windows-phone-7-lists-scroll-smoothly-and-consistently.aspx David Anson's DeferredLoadListBox]. If just changing the ListBox control variant doesn't work then you'll need to consider UX changes. For example consider using Paging, placing different categories of data into different pages or using a Silverlight Toolkit LongListSelector. UX changes depend on your specific business domain and UX requirements.
-== Tip #9 - Consider disabling Disable page transitions ==
+== Tip #9 - Consider disabling page transitions ==
 Page transitions are the animations that take place when the user navigates between pages (such as flip-in and flip-out). On WP7 those animations are commonly enabled through the Silverlight Toolkit for Windows Phone using the {{Icode|TransitionFrame}} and {{Icode|TransitionService}}. In this section we'll focus on the memory impacts of using the {{Icode|TransitionFrame}} and {{Icode|TransitionService}}. We'll see that memory consumption of page transitions is about 5MB~. Those 5MB~ could turn out to be important when you have 60 MB working set versus 90 MB working set. We should call out that any and all implementations of Page Transitions would cause this memory footprint, and not just the Silverlight Toolkit implementation. Any implementation of having 2 pages animate at the same time will inherently require considerable memory.
@@ Line 365: / Line 365: @@
+}
 </code>
 The recommended best practice is for app developers to disable page transitions on 256 MB devices unless they've tested their apps on 256 MB devices and overall memory usage doesn't exceed 90 MB.
 == Tip #10 - Avoid initialising the same SoundEffects multiple times ==