p>In an a href="http://windowsteamblog.com/windows_phone/b/wpdev/archive/2012/04/19/memory-profiling-launching-graphs-and-markers.aspx">earlier post/a> we looked at how we can gain broad insight into an application scenario"™s memory characteristics and how the graph and markers drew our attention to ranges of execution for further analyses. Recall that in the a href="http://windowsteamblog.com/windows_phone/b/wpdev/archive/2012/02/01/memory-profiling-for-application-performance.aspx">memory leak diagnosis case/a> we chose to analyze only the time range over which we observed the increase in memory usage. Indeed, that is a key first step to the analysis: filtering the memory activity data by a time range. The b>Heap Summary /b>view is the result of such filtering, and represents the population of the heap during the chosen time range./p> h1>Heap Summary View/h1> p>The Heap Summary view presents, in tabular form, a demographic analysis of the population of the heap./p> p>In human population demographics, data collection happens through a census as well as through a continuous update to registries that track births, deaths, migration of place of residence and the like. The data collection in the case of heap population demographics is no different. "Births" map to allocations, "deaths" map to objects"™ memory collected by the GC, and "migration of place of residence" maps to the migration of objects between the Gen0 region of the heap and the Gen1 region. A census of the heap at the start of time range identifies all incumbent objects (i.e. that were in existence). Births, deaths, and migrations are updated continuously, and a final census at the end of the time range identifies all the objects that were retained. In order to have a consistent terminology, we refer to the incumbent objects at the start as objects that were "retained" at the start./p> p>Managed Silverlight Visual elements (i.e. objects that go into the Silverlight visual tree) are not just plain old managed objects. These might be facades with backing native-implementations holding native memory and during the course of execution might create and hold on to texture memory. Casual use of such elements in code can even lead to subtle leaks. From this perspective, subsequent analysis can be made easier if Silverlight Visual elements were tracked and reported separately from plain old managed objects. And this is precisely how they are tracked and reported through the Heap Summary view. Continuing with the demographic analogy, such classification has precedent in social demographics where human populations have been classified on ethnicity./p> p>Armed with this context, let us study the following Heap Summary view from the a href="http://windowsteamblog.com/windows_phone/b/wpdev/archive/2012/02/01/memory-profiling-for-application-performance.aspx">memory leak diagnosis case/a>:/p> p>a href="http://windowsteamblog.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-53-84-metablogapi/1055.image_5F00_797B31D3.png">img style="display: inline; background-image: none;" title="image" border="0" alt="image" src="http://windowsteamblog.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-53-84-metablogapi/7536.image_5F00_thumb_5F00_086260EE.png" width="508" height="365" />/a>/p> p>The shaded region across the graph and markers indicates the time range used as the filer./p> p>The census at the start reports 5576 instances of managed type objects accounting for about 283 KB and 26 instances of Silverlight Visual elements accounting for about 13 KB. In terms of incumbency the plain old managed objects dominate./p> p>The churn happening within the selected time range is reported as 10615 instances allocated (births) and 11590 instances collected (deaths), accounting for about 23 MB each. The counts and sizes are somewhat balanced and cancel each other out to an extent. And this is borne out by the census at the end for the managed objects; the census at the end reports 4601 instances of managed type objects accounting for about 223 KB, which is just a little lower than what we had at the start. However, it also reports 69 instances of Silverlight Visual elements accounting for about 4 MB now (up from 13KB at the start)./p> p>When we correlate this table with the graph, our suspicion is drawn towards the Silverlight visuals. Why did their count go up, and why are they accounting for so much more memory? Within the filtered time range, memory usage has been steadily increasing too. Could we be leaking memory? Could we be leaking some part of visual tree itself? And there even seem to be images being loaded along the way; might we be leaking their texture memory too? We wonder./p> p>Clearly, the next lead to follow is to get more visibility into what are those "Retained Silverlight Visuals at End"./p> h1>Summary/h1> p>The Heap Summary view presents, in tabular form, a demographic analysis of the population of the heap. Interpreting the data in the table and correlating it with the graph and markers by itself can be used to make educated guesses at what could potentially be the problem, but equally importantly it serves to inform the next step in the performance investigation, as we shall see./p>div style="clear:both;">/div>img src="http://windowsteamblog.com/aggbug.aspx?PostID=581472" width="1" height="1">

p>The Windows Phone Browser team has a goal of delivering the best web browsing experience on a smartphone. This goal has many components within our team: from the a href="http://windowsteamblog.com/windows_phone/b/windowsphone/archive/2011/09/22/designing-ie9-mobile-putting-sites-in-the-spotlight.aspx">UI of the browser/a>, compatibility with a wide array of website layouts, and of course buttery-smooth rendering performance. However, even if we execute flawlessly on our end, we are missing a crucial piece - delivering a great web experience is fundamentally a i>partnership/i> between our team and web developers. Achieving this goal means working together to ensure that your content and services are delightful for users to consume on Windows Phone. /p> p>We understand that web development resources are always limited as you keep up with the increasing traffic from mobile devices, and the elusive "write once, run everywhere" promise of web development has not perfectly materialized. However, with IE9 for Windows Phone 7.5, we took a big step in the direction of this promise. By sharing a codebase with IE9 for the PC, we achieved identical a href="http://windowsteamblog.com/windows_phone/b/wpdev/archive/2011/09/22/ie9-mobile-developer-overview.aspx">support for new web standards/a> and pushed the envelope on real-world performance with a href="http://youtu.be/PfYeoR3Ug4E">industry-leading hardware acceleration/a>. We wanted to hear about developing for IE9 on WP7.5 from web developers directly, so we decided to collect some feedback and share it on the blog. /p> p>ESPN.com recently deployed their premium web experience to Windows Phone, and we thought it would be great to hear what they had to say about developing for IE9 on Windows Phone. As a side note, ESPN started looking into supporting Windows Phone because of a simple request I made on their support page. Lots of folks on my team are sports fans and were asking me about the site's experience on WP7.5, so I just dropped ESPN a note like any user would. The message was quickly routed to the mobile site team; I have immense respect for ESPN"™s responsiveness and the system they have place to address user feedback. Here's what Mike Marrone, technical lead, had to say about developing for IE9 on WP7.5:/p> blockquote> p>Overall, it was an easy process. We support only WP7.5 and IE9 thanks to its very good CSS3/HTML5 support. We are in a convenient position of having an existing legacy mobile site that older devices can fallback to. Honestly, development for WP7.5 boiled down to a fairly basic process - IE9 on the PC, being nearly the same browser, was a great dev tool to get most of the way there before final QA on actual devices./p> /blockquote> blockquote> p>Some other more specific development notes:/p> ul> li>The "display: box" CSS style is not supported on WP7.5. We use this in carousel experiences to transition elements left or right 100% of the viewport without having to programmatically determine the viewport size (which means the browser automatically updates the positioning upon device rotation, etc.). On WP7.5, we actually used a better alternative thanks to it being the only browser that currently supports the CSS "vw" unit (VERY useful). br />i>[Amin] See /i>a href="http://www.w3.org/TR/css3-values/#viewport-relative-lengths">i>here/i>/a>i> and /i>a href="http://snook.ca/s/1000">i>here/i>/a>i> for more information on vw units./i>/li> li>The bulk of our CSS differences between WP7.5 and other supported devices was with gradients. WP7.5 has an easy fallback with filters so it was not a big development issue. br />i>[Amin] See /i>a href="file://tkzaw-pro-19/MyDocs4/aminl/My Documents/MSFT/Blog posts/msdn.microsoft.com/en-us/library/ms532997(v=vs.85).aspx">i>here/i>/a>i> for information on using Gradient Filters in IE9./i>/li> li>JavaScript touch events would be a nice addition. br />i>[Amin] We hear you, stay tuned!/i>/li> /ul> p>We look forward to your continued great progress in mobile./p> /blockquote> p>As you can imagine, this was music to our ears! We often use IE on the PC to investigate bugs, and it was great to hear that the tools work well for web development outside of our offices too. We appreciate the feedback (it will inform our plans for future releases) and welcome additional feedback through the comments below. /p> p>IE9 on Windows Phone is set up to support rich web experiences with great performance, and often all it takes is a href="http://windowsteamblog.com/windows_phone/b/wpdev/archive/2011/08/29/introducing-the-ie9-on-windows-phone-mango-user-agent-string.aspx">updating user-agent logic/a> and using a href="http://blogs.msdn.com/b/ie/archive/2010/03/19/the-css-corner-about-css-corners.aspx">standards based (as opposed to vendor prefixed) HTML & CSS/a>. ESPN invested a reasonable level of resources to do that and delivered a delightful experience to its users. I've definitely started to see the site pinned to Start around here, and I wouldn't be surprised if our senior managers are secretly checking ESPN during meetings./p> p>Here's a before (left) and after (right) screenshot of the ESPN.com experience on Windows Phone 7.5. We want to say thanks to ESPN, and we look forward to seeing more rich experiences light up!/p> p align="left">a href="http://windowsteamblog.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-53-84-metablogapi/5504.image_5F00_1C927520.png">img style="display: inline; background-image: none;" title="image" border="0" alt="image" src="http://windowsteamblog.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-53-84-metablogapi/2110.image_5F00_thumb_5F00_6DCCBC7D.png" width="241" height="400" />/a>     a href="http://windowsteamblog.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-53-84-metablogapi/6232.image_5F00_780DBB10.png">img style="display: inline; background-image: none;" title="image" border="0" alt="image" src="http://windowsteamblog.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-53-84-metablogapi/3652.image_5F00_thumb_5F00_6C0BCADC.png" width="241" height="400" />/a>/p> p>i>Special thanks to Krys Krycinski, Mike Marrone, and James Ballow at ESPN./i>/p> p>Amin Lakhani br />Program Manager, Windows Phone/p>div style="clear:both;">/div>img src="http://windowsteamblog.com/aggbug.aspx?PostID=581178" width="1" height="1">

p>Today I"™ll outline the latest steps we"™re taking in our ongoing effort to keep the quality bar high in our rapidly growing Marketplace. I know most of you share our goal of a great shopping experience and already go out of your way to follow our policies and guidance. For others, I hope this insight into a few near-term changes we"™re putting in place helps save you time and reduces your risk of having apps pulled from the Marketplace./p> p>b>Avoiding trademark trouble/b>/p> p>When a trademark or copyright owner contacts us about a suspected violation, we investigate and pull apps when the complaint is valid. Lately we"™ve been doing more of this, especially for trademark misuse. Sometimes the requests come from the owners of big, well-known brands. Other times they come from new brands. Either way, we often find trademark violations are unintentional: some developers just aren"™t clear on what constitutes a violation. But these investigations"”and the time and money they can cost"”can be avoided by doing a little homework before submitting or updating your app./p> p>If you"™re developing an app, please consult our a href="http://msdn.microsoft.com/en-us/library/hh184842(v=vs.92).aspx">content policy/a> covering trademarks and this related a href="http://msdn.microsoft.com/en-us/library/hh347118(v=VS.92).aspx">Q&A/a>. (The a href="http://www.uspto.gov/trademarks/basics/trade_defin.jsp">U.S. Trademark and Patent Office/a> also has helpful background and a trademark search tool.) Our rules boil down to this: Your registered publisher name and everything about your app"”name, logo, description, screenshots"”must be unique and free of trademarked content unless (1) you own the trademark, (2) you"™ve secured permission from the owner to use it, or (3) you"™re using a trademarked name (i>not/i> a logo) to describe your app"™s features or functionality without suggesting that the app is actually published by the trademark owner. /p> p>For example, using "Microsoft App Co." as your publisher name would cause problems because "Microsoft" is a trademarked term. By the same logic, you couldn"™t call your app "MSN" or "YouTube". However, you may be able to make an app called "Reader for MSN," as long as you don"™t use the MSN logo or otherwise suggest that the app is published by Microsoft./p> p>b>Keeping the quality bar high /b>/p> p>I"™ve a href="http://windowsteamblog.com/windows_phone/b/wpdev/archive/2011/09/29/taking-a-tougher-stance-on-bulk-app-publishing.aspx" target="_blank">posted before/a> about our efforts to help ensure that apps in Marketplace offer clear value. One of those efforts concerns bulk publishing"”developers who send us hundreds of similar apps simultaneously. Today I want to mention two related issues on our radar that could affect developers working on app genres that lend themselves to bulk publishing. /p> p>First, we"™re seeing developers submit the same app to multiple Marketplace categories, a violation of our policies. Instead, you should pick a single category that best reflects the content and function of your app. This not only helps customers find your app but gives all developers an equal opportunity to have their app discovered where people expect. Developers who submit the same app across multiple categories will have it removed from the catalog./p> p>Second, when you create multiple closely-related apps"”say, a series of quote apps that vary by theme"”the Marketplace tile images must reflect the unique features of each individual app. They cannot be duplicates or near duplicates of each other. Your branding also shouldn"™t dominate the tile. Here are a few examples of dos and don"™ts:/p> p>a href="http://windowsteamblog.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-53-84-metablogapi/2845.image_5F00_7B79CB49.png">img style="border: 0px currentcolor; margin-right: auto; margin-left: auto; float: none; display: block; background-image: none;" title="image" border="0" alt="image" src="http://windowsteamblog.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-53-84-metablogapi/2705.image_5F00_thumb_5F00_39FF18F0.png" width="642" height="201" />/a>/p> p>a href="http://windowsteamblog.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-53-84-metablogapi/5047.image_5F00_671405BE.png">img style="border: 0px currentcolor; margin-right: auto; margin-left: auto; float: none; display: block; background-image: none;" title="image" border="0" alt="image" src="http://windowsteamblog.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-53-84-metablogapi/0172.image_5F00_thumb_5F00_0D75E90A.png" width="641" height="209" />/a>/p> p>Creating unique, easily distinguishable app tiles helps customers see at a glance what"™s different about the apps you"™re publishing, improving the shopping experience and potential for downloads./p> p>b>Cleaning up keywords/b>/p> p>Some developers have been violating Marketplace policy by entering more than the five allowed keywords for an app. A keyword is a word or short phrase that describes your app. Entered during the App Hub submission process, these words or phrases are always separated by commas./p> p>Starting this week, we"™re going to start enforcing the five keyword rule for all current and future Marketplace apps. Any app that exceeds this number will have i>all/i> its keywords deleted. Affected developers will be notified and can then enter five new keywords in App Hub. We"™re taking this action to help ensure that customers are able to find the most relevant set of apps for their search"”including yours. /p> p>We"™re also starting to examine app keywords for relevancy. We"™ve noticed some developers have been entering keywords that are popular search terms"”"Justin Bieber," "YouTube""”but are totally unrelated to their app and what it does. If we find a keyword that"™s not relevant to your app"™s function or content, we"™ll delete that keyword. Additionally, if you suspect that other developers are using high-impact keywords unrelated to their app"” "Skype" for a tic-tac-toe game, for example"”email a href="mailto:reportapp@microsoft.com">reportapp@microsoft.com/a> with the details and we"™ll investigate./p> p>b>Refining our approach to content policy enforcement /b>/p> p>The final issue I want to discuss is one that affects all major app stores today: the treatment of apps that are "racy" or sexual in nature. We"™re committed to offering a diverse selection of safe and quality apps that appeal to a wide range of customer interests. Items that some customers view as entertainment, others may consider inappropriate. This is a challenge for any big retailer, whether they operate online or down the street./p> p>We think the right solution is (a) to be transparent about what"™s acceptable and (b) to show the right merchandise to the right customer in the right place. Our content policies are a href="http://msdn.microsoft.com/en-us/library/hh184842(v=vs.92).aspx">clearly spelled out/a>: we don"™t allow apps containing "sexually suggestive or provocative" images or content. What we do permit is the kind of content you occasionally see on prime-time TV or the pages of a magazine"™s swimsuit issue./p> p>Admittedly, it"™s tricky catering to such a wide range of people and markets. But we take this responsibility seriously and evaluate and discuss questionable cases. Recently we decided that we could improve the shopping experience for i>all /i>our customers by a more stringent interpretation and enforcement of our existing content policy./p> p>Specifically, we will be paying more attention to the icons, titles, and content of these apps and expect them to be more subtle and modest in the imagery and terms used. Apps that don"™t fit our standard will need to be updated to remain in the store. This is about presenting the right content to the right customer and ensuring that apps meet our standards. We will also monitor customer reaction to apps and reserve the right to remove ones that our customers find offensive/p> p>While this change might require a little extra work on the part of a small number of developers, there are plenty of creative and appropriate ways to comply: showing male or female models in silhouette, for example, is one possible alternative. Here are a few other examples of app tiles that pass muster:/p> p>a href="http://windowsteamblog.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-53-84-metablogapi/5481.image_5F00_05EA799D.png">img style="border: 0px currentcolor; margin-right: auto; margin-left: auto; float: none; display: block; background-image: none;" title="image" border="0" alt="image" src="http://windowsteamblog.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-53-84-metablogapi/7633.image_5F00_thumb_5F00_175ADA75.png" width="483" height="97" />/a>/p> p>If you"™re one of the handful of impacted developers, we will be reaching out to you within the next few days with more specific guidance on changes you need to make. If you don"™t hear from us, there is no immediate action you need to take. /p> p>I hope this post has provided some useful tips and helpful insight into our policies, and how they"™re evolving to reflect both customer and developer feedback and the growing size and reach of the Windows Phone Marketplace. We"™re committed to our developer community and appreciate your feedback on how we can make Marketplace better for you and your customers. I look forward to hearing your thoughts./p>div style="clear:both;">/div>img src="http://windowsteamblog.com/aggbug.aspx?PostID=581070" width="1" height="1">

p>I wanted to make sure you saw the Windows Phone consumer blog today, because my colleague Mazhar a href="http://windowsteamblog.com/windows_phone/b/windowsphone/archive/2012/04/24/two-marketplace-changes-and-how-they-affect-you.aspx">highlights/a> two changes to the Marketplace shopping experience that developers should be aware of./p> p>First, we"™re removing the option to browse and buy Windows Phone apps from the Zune PC software, a change that started rolling out this afternoon. Second, in the coming weeks we"™ll also start requiring that customers have Windows Phone 7.5 installed on their phone to buy, download, update, or review apps in Marketplace. /p> p>Mazhar"™s post has more details and background. But I want to highlight one important way the removal of the Windows Phone store from Zune impacts developers./p> p>It"™s important to make sure you"™re using the correct protocol for direct links to your app in Marketplace. This "deep link," as it"™s also called, makes it easy for customers to pull up your app in the phone and web stores. The correct format is: /p> p align="center">em>http://windowsphone.com/s?appId={GUID}/em>/p> p>You"™ll find more details on deep links a href="http://msdn.microsoft.com/en-us/library/ff967553(v=vs.92).aspx">here on MSDN/a>. If you use the older em>zune:///em>strong> /strong>format for links, customers will see an error message. Just something to keep in mind./p> p>One final update for today: We just released the OS software required to bring Marketplace to customers in Bahrain, Israel, Iraq, Kazakhstan, Qatar, Saudi Arabia, Thailand, UAE and Vietnam. These nine markets"”which are already open for app submissions"”were part of the larger Marketplace  expansion a href="http://windowsteamblog.com/windows_phone/b/wpdev/archive/2012/03/15/app-hub-accepting-submissions-for-new-markets-soon.aspx">I outlined/a> last month. Our hardware partners can now create phones for these markets and begin their final launch preparations. /p> p>Mazhar will have more to say about these new storefronts in the weeks ahead./p>div style="clear:both;">/div>img src="http://windowsteamblog.com/aggbug.aspx?PostID=580787" width="1" height="1">

p>The fourth of the four principles I mentioned in a href="http://windowsteamblog.com/windows_phone/b/wpdev/archive/2012/03/07/optimizing-apps-for-lower-cost-devices.aspx">Optimizing Apps for Lower Cost Devices/a> is Respond to User Input./p> p>A responsive UI is a basic expectation that users have of apps.  Failing to respond to user input can frustrate users and can ultimately drive them away to other apps that are more responsive./p> p>The basic guidance here is to keep as much activity off of the UI thread as possible until absolutely necessary.  The UI thread is what processes user input for you, so any code you execute on that thread will interfere with this processing.  Unless you're updating elements of your UI, you generally should not be executing code on the UI thread./p> p>A quick way to check whether a block of code is running on the UI thread is to call a href="http://msdn.microsoft.com/en-us/library/system.windows.threading.dispatcher.checkaccess(v=vs.95).aspx">Deployment.Current.Dispatcher.CheckAccess()/a> inside that block of code (Intellisense won't show this method but it is there and useful).  This will return true if the code is executing on the UI thread, so if this returns true and you're not updating your UI, then you've found code that could be moved to background threads./p> p>An easy way to move code to background threads is to wrap it in a call to a href="http://msdn.microsoft.com/en-us/library/kbf0f1ct(v=vs.95).aspx">ThreadPool.QueueUserWorkItem()/a>./p> pre>code>// Running on the UI thread.br />...br />/code>/pre> pre>code>/code>code>// Running on a background thread.br />ThreadPool.QueueUserWorkItem((o) =>br />{br />    ...br />}/code>/pre> p>The a href="http://msdn.microsoft.com/en-us/library/y5htx827(v=vs.95).aspx">ThreadPool/a> is (as its name suggests) a pool of background threads that are waiting to execute work items for you.  a href="http://msdn.microsoft.com/en-us/library/kbf0f1ct(v=vs.95).aspx">QueueUserWorkItem/a> enables you to register blocks of code that will execute on the next available background thread in the ThreadPool.  Note that use of ThreadPools is common and encouraged across many platforms (including a href="http://msdn.microsoft.com/en-us/library/windows/apps/windows.system.threading.aspx">Windows 8/a>) so familiarizing yourself with them will serve you well in future projects./p> p>When you are ready to update your UI, you will need to return to the UI thread.  You can return to the UI thread at any time from a background thread by wrapping your code in a call to a href="http://msdn.microsoft.com/en-us/library/system.windows.threading.dispatcher(v=vs.95).aspx">Deployment.Current.Dispatcher.BeginInvoke()/a>./p> pre>code>// Running on a background thread.br />ThreadPool.QueueUserWorkItem((o) =>br />{br />    ...br />br />    // Running on the UI thread.br />    Deployment.Current.Dispatcher.BeginInvoke(() =>br />    {br />        ...br />    }br />}/code>/pre> p>If you try to update your UI from a background thread, you will receive an UnauthorizedAccessException with the message "Invalid cross-thread access."  In these cases, wrap the offending code in a call to a href="http://msdn.microsoft.com/en-us/library/system.windows.threading.dispatcher(v=vs.95).aspx">Deployment.Current.Dispatcher.BeginInvoke()/a> as shown above to execute it on the UI thread as required./p> p>In addition to being able to control whether your code executes on the UI thread or on background threads, you also have options to do the same with framework code in several places./p> p>Image decoding is an expensive operation that can harm interactivity significantly if executed on the UI thread, particularly if you're loading many images at a time.  The framework allows you to specify a href="http://msdn.microsoft.com/en-us/library/system.windows.media.imaging.bitmapcreateoptions(v=vs.95).aspx">BitmapCreateOptions/a> to control whether image decoding executes on the UI thread or on background threads.  Be sure to use the a href="http://msdn.microsoft.com/en-us/library/system.windows.media.imaging.bitmapcreateoptions(v=vs.95).aspx">BackgroundCreation/a> option to move image decoding to background threads./p> p>The built-in ProgressBar control has a href="http://www.jeff.wilcox.name/2010/08/performanceprogressbar/">known performance problems/a> that can harm UI performance as a result of its animations executing on the UI thread.  Use the SystemTray a href="http://msdn.microsoft.com/en-us/library/microsoft.phone.shell.progressindicator(v=VS.92).aspx">ProgressIndicator/a> for the best performance as the a href="http://msdn.microsoft.com/en-us/library/microsoft.phone.shell.progressindicator(v=VS.92).aspx">ProgressIndicator/a> is a shell component that will not interfere with your UI thread.  A bonus to using the a href="http://msdn.microsoft.com/en-us/library/microsoft.phone.shell.progressindicator(v=VS.92).aspx">ProgressIndicator/a> is that your UX will more closely match the UX of the built-in experiences./p> p>If you're using animations in your app, use a href="http://msdn.microsoft.com/en-us/library/system.windows.media.animation.storyboard(v=vs.95).aspx">Storyboards/a> wherever possible as these run on an important background thread known as the compositor thread and will not interfere with your UI thread.  If you're familiar with a href="http://msdn.microsoft.com/en-us/library/cc295346(v=expression.40).aspx">Expression Blend/a>, it can be particularly useful for generating Storyboards./p> p>With code now running off of the UI thread for a given page, you should also focus on optimizing navigation between pages./p> p>To keep page load times and in-app navigation responsive, defer loading activities until the first frame is rendered. The guidance for a href="http://windowsteamblog.com/windows_phone/b/wpdev/archive/2012/04/03/optimize-startup-time.aspx">optimizing startup time of your MainPage/a> applies to optimizing the startup time of subsequent page loads as well. Enabling the a href="http://msdn.microsoft.com/en-us/library/ff941094(v=VS.92).aspx">TiltEffect/a> is a great way to acknowledge user input and indicate that navigation is in progress. This will make your app look and feel more like the first party experiences as well./p> p>Many apps add page transition animations to add style to in-app navigations. While this is a great practice to make your apps more dynamic, excessive use of transition animations can delay load times, particularly when the generation/execution of the animations result in spikes in memory/CPU usage.  If transition animations are causing performance problems in your app, disabling them completely, or at least a href="http://msdn.microsoft.com/en-us/library/hh855083(v=vs.92).aspx">on low-memory devices only/a>, can significantly improve in-app navigation performance./p> p>Maintaining a responsive UI is important regardless of the platform you are targeting.  By offloading work to background threads and keeping in-app navigation fast, you'll provide the best possible experience to your users./p>div style="clear:both;">/div>img src="http://windowsteamblog.com/aggbug.aspx?PostID=580771" width="1" height="1">