针对WindowsPhone开发的一些优化

今天在看一个博客,里面提到了一些有关性能优化的方法。现在在此记下以备后用。大家也可以去

http://www.cnblogs.com/magicboy110/archive/2010/12/13/1905019.html

看一下整个文章,学习学习!

 

1)

选择JPG还是PNG格式

一个最简单的提高性能的方法就是使用合适的图片格式。Windows Phone 中支持两种图片格式:JPG和PNG。通常,JPG格式解码速度比PNG更快,所以所有情况下都应该优先考虑JPG图片,除非,图片要使用透明的情况,此时必须用PNG,因为JPG不支持透明。

 

 

2)

将多媒体文件的BuildAction设置为Content

WP7上的多媒体处理针对文件和网络流做了优化,但是内存流没有。这就意味着包含在程序中的多媒体文件,如声音效果等,应当设置其Build ActionContent而不是Resource(关于Content和Resource的区别请参考《BuildAction之Content与Resource》)。当多媒体文件设置为Content时,安装后将直接以独立文件形式存储在应用程序安装目录中。而设置为Resource时,将存在于Dll文件中,一般使用时还要先将其从Dll文件中释放出来才能使用。也就说当一个多媒体文件编译为Content时可以直接播放。而编译为Resource时,在播放前要先将其从Dll中拷贝到一个文件中然后才能播放,这将很大的降低应用程序性能。下面的示意图展示了如何在VS中设置文件的BuildAction。

 

3)

Visibility属性

当设置一个元素的P:System.Windows.UIElement.Visibility属性(可见性)为Collapsed时,Silverlight不会在内存中保持该元素的任何视图数据,并且不会对元素做任何其他处理。因而,当通过将元素的Visibility设置为Visible,将元素重新显示到屏幕上时,必须在视图树中重新绘制该元素的视图。

 

Opacity属性与位图缓存

当启用位图缓存时,可以通过操作元素的P:System.Windows.UIElement.Opacity(透明度)属性来控制元素显示/隐藏以提高程序性能。启用位图缓存的方法是设置UI元素的CacheMode属性为T:System.Windows.Media.BitmapCache。位图缓存允许UI元素在首次渲染后将其视图数据缓存为位图。之后再次显示元素时就可以绕过渲染图形的过程,直接显示缓存的位图。编程中应避免在没有启用位图缓存的情况下操作Opacity属性,因为这会降低程序的性能。

当设置一个启用位图缓存的UI元素的Opacity为0时,Silverlight将会在内存中保存一个该元素的显示位图。当Opacity被重新设置为一个非0值时,将会应用标准的填充率。

 

 一般来说使用开启位图缓存的Opacity进行控件的隐藏和显示有更好的性能,但是具体也要通过两种方法都使用一遍来测试。

另外一提的是,关闭位图缓存,虽然性能有所削弱,但是由于必须重绘,图片显示效果提高。所以我们要在两者之间权衡。

 

4)

最小化应用程序集的大小

另一个提高应用程序启动性能的方法是最小化应用程序集的大小。当向Windows Phone应用商店提交应用时,应用中的程序集会被生成签名,以后程序每次启动时都会检查这个签名。检查程序集签名所用的时间会随着应用程序大小的增加而增加。因为签名检查的结果会被缓存,所以签名检查不会影响之后的程序加载速度,程序的第一次加载速度会受到影响。以下一些技巧可以减小程序集的大小。

  • 如果可能,尽量不要将程序中图片、多媒体、XML文件之类的的资源的BuildAction设置为Resurce,因为这样会使资源编译到应用程序集中,从而增加程序集大小。一般设置BuildAction为Content。
  • 通过斜线开头的路径设置图片的URI,如使用“/folder/myImage.jpg”替代“folder/myImage.jpg”。 
  • 使用JPG图片替代PNG图片,除非需要使用透明。 
  • 如果程序中使用了本地化,不要将本地化资源包含在主程序集中。为每种语言创建一个独立的附加程序集。

5)

将应用程序分解为多个小程序集 

可以考虑将程序分解为多个按需加载的小程序集以进一步缩短启动时间。要实现这个目的,可以在解决方案中新建一个Windows Phone类库项目专门承载按需加载的页面。之后在主程序项目中引用该类库项目。通过HyperLink控件或Navigate方法可以导航到这些页面。以下代码示范了如何导航到PageInExternalAssembly程序集中的ExternalPage.xaml页面。

private void button1_Click(object sender, RoutedEventArgs e)

{    

        // Use the name of the separate assembly when generating the Uri for the page    

        NavigationService.Navigate(new Uri("/PageInExternalAssembly;component/ExternalPage.xaml",           

        UriKind.Relative));

}

这就像我在以前博文中说如何改动DatePicker和TimePicker的英文一样。

 

6)

减少构造函数和Loaded事件中的代码

所有构造函数和Loaded事件中的代码都会在应用程序显示第一帧之前运行。页面和控件的构造函数解析XAML、实例化XAML中定义的对象是很耗时间的。因此应当限制在这些方法中再执行其他的耗时的操作。如果需要执行载入文件或其他的复杂处理,应当将其延迟到稍后的事件中,或在一个后台线程中延迟执行。一种方案是在LayoutUpdated的事件处理程序中执行这些耗时的操作。LayoutUpdated事件会在应用程序的第一帧显示之后才执行。以下示例演示了如何操作。

private bool _onNavigatedToCalled = false;

public Page()
{
    InitializeComponent();
    LayoutUpdated += new EventHandler(Page_LayoutUpdated);
}

protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
{
    _onNavigatedToCalled = true;
}

private void Page_LayoutUpdated(object sender, EventArgs e)
{
    if (_onNavigatedToCalled == true)
    {
        _onNavigatedToCalled = false;
        Dispatcher.BeginInvoke(() =>
            {
                // 添加你要做的事
            }
        );
    }           
}

但是大家不能一味地减少两个函数中的代码,毕竟一些控件的初始化和数据载入要在首页面载入之前进行。

7)

监控独立存储的使用

P:System.IO.IsolatedStorage.IsolatedStorageSettings.ApplicationSettings对象在第一次使用时(通常是应用程序启动时)从存储中加载并反序列化。可以在程序中创建一个包含计时器的帮助属性以测量反序列化应用程序设置所消耗的时间。如果数据序列化所用时间超过了100毫秒,就应该考虑将该过程移动到一个后台线程中执行。

如果要用来自独立存储的数据填充一个页面,应该在页面中创建一个ObservableCollection对象用以保存数据,并立即将该对象绑定到UI元素。然后用来自独立存储的数据填充这个ObservableCollection。如果需要,可以通过使用M:System.Windows.Threading.Dispatcher.BeginInvoke(System.Action)方法将数据填充工作分解到多个调用中。

8)

使用Manipulation 事件代替Mouse和Touch事件

Manipulation 事件是推荐的用户输入处理方式。从性能和硬件兼容性方面考虑,如果没有特殊的需求,应当避免在WP7上的Silverlight应用程序中使用Mouse事件。相反,应当用Manipulation 事件来替代。

T:System.Windows.Input.Touch类提供了E:System.Windows.Input.Touch.FrameReported事件用以获得每个单独的触摸点。尽管该事件在Windows Phone 7中仍然支持,但是不推荐用他来处理手势,如缩放之类。如果不需要获得每个单独触摸点,则应使用Manipulation 事件。

关于如何使用Manipulation 事件的更多信息,请参考How to: Handle Manipulation Events

 

9)

使用PerformanceProgressBar 代替ProgressBar

为了解决ProgressBar的性能问题,微软创建了一个替代的PerformanceProgressBar。PerformanceProgressBar将动画从UI线程移到了构图线程。

 

 

原作者的博客里还有许多东西,推荐大家去看看!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章