Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
未来XAMLの1msに
泣かないために
めとべや東京 #9
あ す
自己紹介
@tmyt
関東でソフトウェア開発の仕事をしているという噂
Windows ストアアプリとかWindows Phoneアプリとか作って
ます
アプリ作って生きていきたい
Microsoft MVP for Windows P...
アプリの紹介宣伝
最近まともに作ったやつだけ
Aristea
Mimosa
Mimosa
Windows Phone 8.1向け
いわゆるIIJmioのクーポンアプリ
バックグラウンドタスクで情報収集していません
そんなめんどくせーことやってられっか
UWP移植の実験台にする予定
Aristea
Windows 8.1/Windows Phone 8.1向け
PCで実装したものを電話で動かしている
事前のパフォーマンス評価がPCとエミュレータなので電話実機
での動作がやばい
本日の経緯
ねぇねぇなにやればいいの
拝承
XAMLを70ms高速化していただきたく
電話のスペックのおさらい
Q501WH
SoC: MSM8916 (1.2GHz)
MSM8916
ARM Cortex-A53 (64bit)
Geekbench Score: 466
(参考) Intel i7 4600U
G...
電話のスペックのおさらい
Q501WH
SoC: MSM8916 (1.2GHz)
MSM8916
ARM Cortex-A53 (64bit)
Geekbench Score: 466
(参考) Intel i7 4600U
G...
実際にどれぐらい違うのか
Intel i7-4600U v.s. Qualcomm Snapdragon 400
private void ButtonBase_OnClick(object sender, RoutedEventArgs e...
PC
Emulator
MADOSMA
レイアウトにかかった時間で比較
PC (i7-4600U) 1.4sec
Phone (Emulator) 4.96sec
Phone (MADOSMA) 22.22sec
レイアウトにかかった時間で比較
PC (i7-4600U) 1.4sec
Phone (Emulator) 4.96sec
Phone (MADOSMA) 22.22sec
16倍遅い!!
Windows Phoneでの課題
Pivotの初回切り替えが遅い
アカウントのスイッチが遅い
とっても遅くて5秒とか最悪もっとかかっている
PCで評価していたコードをWindows Phoneで動作させたから
原因を調べてみる
VS2015のパフォーマンス測定
VS2015でパフォーマンス分析がかなり詳細にできるように
Windows 10だけでなくWidows Phone 8.1でも使えます
ちなみにWPFもいけますよ!
DiskI/O, XAMLレイアウト...
パフォーマンス分析ツールの起動
タイムライン分析
デバッグスタート!
適当にデバッグ終了
しばらくするとこういうのが出てきます
-- ここあたりで画像
-- ここあたりで画像
遅い
XAMLの計算その他XAML関連の処理が遅い
どう見ても遅い
ContentPresenterのレイアウトに180msもかかっている
これが10個並ぶと1800msつまり約2秒。相手は死ぬ
もう少しみてみる
ちょろっとだけ出てた画像を詳しくみるといろいろわかります
レイアウトとパースがほとんどを占めている現実
レイアウト
パース
実際に高速化していく
基本的にはMSDNとChannel9を見ます
Data Binding: Boost Your Apps' Performance Through New
Enhancements to XAML Data Bindi...
UserControlをやめてみる
UserControlだとインスタンスを作るたびにXAMLがパースされ
る
TemplatedControlにすると初回にパースして保持される
実際にやってみるとこう
パース時間が消し飛んだだけ!
...
レイアウトの見直し
XAMLのレイアウトは再帰的に実行される
つまるところ複雑になると時間がふえる
ネストをできるだけ浅くする
つまりこういうのはよくない
リソースの見直し
引数はあくまでも文字列。クラスへの変換処理が実行される
<Rectangle Fill=“#FF00FF00” />
この場合、#FF00FF00のパース&SolidColorBrushへの変換処理が実行さ
れる
複数...
無駄な属性の設定をやめる
デフォルト値でいいような属性に値を入れない
いれると変換が走って遅くなる
ここもリソースと同じ感じ
たとえばこういう感じ
<ListView>
<ListView.ItemTemplate>
<DataTemplate>
<Grid>
<Grid.Resources>
<BooleanToVisibilityConverter x:Key="...
パネルの速度を意識する
子コントロールを複数並べられるPanelは並べ方で速度が変わ
る
Grid, StackPanel, Canvas などなど
複雑なGridは遅い、単純なレイアウトにできないか検討する
独自のパネルならレイアウト...
ListView on ScrollViewerの時に遅い
特に引っ張って更新をWindows 8.x向けに実装して、それを10
で動かしたときに起きるかも
ListViewがHeight=Infiniteでインスタンス化されてListVi...
いろいろするとこうなります
いま(14:29)測ったデータですがこんな感じです
合計時間が約1秒早くなっています
でもまだまだ遅いですね
これからどうにかします。。。
まとめ
XAMLの速度が足りないときはXAMLを見直す
とくに属性とかネストとか
常にパフォーマンスを気にする
定期的にパフォーマンス分析をしようね!
なにか遅いときはまず分析から
ListViewやばい
未来(あす)Xamlの1msに泣かないために
未来(あす)Xamlの1msに泣かないために
未来(あす)Xamlの1msに泣かないために
Upcoming SlideShare
Loading in …5
×

未来(あす)Xamlの1msに泣かないために

XAMLのパフォーマンスがつらいとき

未来(あす)Xamlの1msに泣かないために

  1. 1. 未来XAMLの1msに 泣かないために めとべや東京 #9 あ す
  2. 2. 自己紹介 @tmyt 関東でソフトウェア開発の仕事をしているという噂 Windows ストアアプリとかWindows Phoneアプリとか作って ます アプリ作って生きていきたい Microsoft MVP for Windows Platform Development (Jan. 2015- Dec.2015)です
  3. 3. アプリの紹介宣伝 最近まともに作ったやつだけ Aristea Mimosa
  4. 4. Mimosa Windows Phone 8.1向け いわゆるIIJmioのクーポンアプリ バックグラウンドタスクで情報収集していません そんなめんどくせーことやってられっか UWP移植の実験台にする予定
  5. 5. Aristea Windows 8.1/Windows Phone 8.1向け PCで実装したものを電話で動かしている 事前のパフォーマンス評価がPCとエミュレータなので電話実機 での動作がやばい
  6. 6. 本日の経緯 ねぇねぇなにやればいいの 拝承 XAMLを70ms高速化していただきたく
  7. 7. 電話のスペックのおさらい Q501WH SoC: MSM8916 (1.2GHz) MSM8916 ARM Cortex-A53 (64bit) Geekbench Score: 466 (参考) Intel i7 4600U Geekbench Score: 3190
  8. 8. 電話のスペックのおさらい Q501WH SoC: MSM8916 (1.2GHz) MSM8916 ARM Cortex-A53 (64bit) Geekbench Score: 466 (参考) Intel i7 4600U Geekbench Score: 3190 6.8倍!
  9. 9. 実際にどれぐらい違うのか Intel i7-4600U v.s. Qualcomm Snapdragon 400 private void ButtonBase_OnClick(object sender, RoutedEventArgs e) { var time = 0L; for (var k = 0; k < 10; ++k) { items.Items.Clear(); var sw = new Stopwatch(); sw.Start(); for (var i = 0; i < 2000; ++i) { var rect = CreateRectangle(); items.Items.Add(rect); } time += sw.ElapsedMilliseconds; } var dlg = new MessageDialog("" + (time / 10.0)); dlg.ShowAsync(); }
  10. 10. PC
  11. 11. Emulator
  12. 12. MADOSMA
  13. 13. レイアウトにかかった時間で比較 PC (i7-4600U) 1.4sec Phone (Emulator) 4.96sec Phone (MADOSMA) 22.22sec
  14. 14. レイアウトにかかった時間で比較 PC (i7-4600U) 1.4sec Phone (Emulator) 4.96sec Phone (MADOSMA) 22.22sec 16倍遅い!!
  15. 15. Windows Phoneでの課題 Pivotの初回切り替えが遅い アカウントのスイッチが遅い とっても遅くて5秒とか最悪もっとかかっている PCで評価していたコードをWindows Phoneで動作させたから 原因を調べてみる
  16. 16. VS2015のパフォーマンス測定 VS2015でパフォーマンス分析がかなり詳細にできるように Windows 10だけでなくWidows Phone 8.1でも使えます ちなみにWPFもいけますよ! DiskI/O, XAMLレイアウト, レンダリングなどなどの細かい情報 が見える CPU分析も含めると関数単位での細かい分析ができます ボトルネックを見つけよう
  17. 17. パフォーマンス分析ツールの起動
  18. 18. タイムライン分析
  19. 19. デバッグスタート!
  20. 20. 適当にデバッグ終了
  21. 21. しばらくするとこういうのが出てきます
  22. 22. -- ここあたりで画像
  23. 23. -- ここあたりで画像
  24. 24. 遅い XAMLの計算その他XAML関連の処理が遅い どう見ても遅い ContentPresenterのレイアウトに180msもかかっている これが10個並ぶと1800msつまり約2秒。相手は死ぬ
  25. 25. もう少しみてみる ちょろっとだけ出てた画像を詳しくみるといろいろわかります レイアウトとパースがほとんどを占めている現実 レイアウト パース
  26. 26. 実際に高速化していく 基本的にはMSDNとChannel9を見ます Data Binding: Boost Your Apps' Performance Through New Enhancements to XAML Data Binding https://channel9.msdn.com/Events/Build/2015/3-635 XAML Performance Fundamentals https://channel9.msdn.com/Events/Build/2013/3-157 XAML の読み込みの最適化 (XAML) https://msdn.microsoft.com/ja-jp/library/windows/apps/Hh994641.aspx Analyze UI responsiveness in Store apps (XAML) https://msdn.microsoft.com/en-us/library/dn263059.aspx
  27. 27. UserControlをやめてみる UserControlだとインスタンスを作るたびにXAMLがパースされ る TemplatedControlにすると初回にパースして保持される 実際にやってみるとこう パース時間が消し飛んだだけ! さすがにパースは別スレッドぽい
  28. 28. レイアウトの見直し XAMLのレイアウトは再帰的に実行される つまるところ複雑になると時間がふえる ネストをできるだけ浅くする つまりこういうのはよくない
  29. 29. リソースの見直し 引数はあくまでも文字列。クラスへの変換処理が実行される <Rectangle Fill=“#FF00FF00” /> この場合、#FF00FF00のパース&SolidColorBrushへの変換処理が実行さ れる 複数回あるとむっちゃ遅い <*.Resource>に追加を検討する しかしPage, UserControlなどの場合インスタンス化毎にリソー スの生成が走って遅い App.xamlに移すとちょっと早くなる 共有の色定数その他は積極的にApp.xamlへ移して速度稼ぐ コンバータも躊躇なくApp.xamlに置きまくる
  30. 30. 無駄な属性の設定をやめる デフォルト値でいいような属性に値を入れない いれると変換が走って遅くなる ここもリソースと同じ感じ
  31. 31. たとえばこういう感じ <ListView> <ListView.ItemTemplate> <DataTemplate> <Grid> <Grid.Resources> <BooleanToVisibilityConverter x:Key="BooleanToVisibilityConverter" /> </Grid.Resources> <StackPanel Orientation="Vertical"> <TextBlock Foreground="#ff000000" /> <TextBlock Foreground="#ffff0000" /> <TextBlock Foreground="#ff00ff00" /> </StackPanel> </Grid> </DataTemplate> </ListView.ItemTemplate> </ListView> App.xaml.cxにする リソースにする いらない!
  32. 32. パネルの速度を意識する 子コントロールを複数並べられるPanelは並べ方で速度が変わ る Grid, StackPanel, Canvas などなど 複雑なGridは遅い、単純なレイアウトにできないか検討する 独自のパネルならレイアウトの計算処理を高速できないか Canvasは絶対座標でレイアウトするので非常に高速。使えそう なら検討するべし https://msdn.microsoft.com/ja- jp/library/windows/apps/Hh994641.aspx
  33. 33. ListView on ScrollViewerの時に遅い 特に引っ張って更新をWindows 8.x向けに実装して、それを10 で動かしたときに起きるかも ListViewがHeight=Infiniteでインスタンス化されてListViewItem が大量に生成されることがあるかも とりあえずHeight=0を設定しておいてあとからよさげなサイズ に調整するといいよ 特にWindows 10で実行したときに起きているみたい
  34. 34. いろいろするとこうなります いま(14:29)測ったデータですがこんな感じです 合計時間が約1秒早くなっています でもまだまだ遅いですね これからどうにかします。。。
  35. 35. まとめ XAMLの速度が足りないときはXAMLを見直す とくに属性とかネストとか 常にパフォーマンスを気にする 定期的にパフォーマンス分析をしようね! なにか遅いときはまず分析から ListViewやばい

×