Windows Phone

[アーティクル]
12/20/2016

Windows Phone アプリケーションを Marketplace にいち早く公開する

Windows Phone SDK 7.1 には、アプリケーションを Marketplace に提出する前に特定の認定ガイドラインへの準拠状態の評価や、Windows Phone 7.5 を対象とするアプリケーションのパフォーマンス向上を目的とした優れたツールが用意されています。この記事では、サンプルアプリケーションを使って Marketplace Test Kit と Performance Analysis ツールの使用方法を説明し、これらのツールによってアプリケーションの Marketplace への対応状況を評価する方法を紹介します。また、アプリケーションの最初の提出で Marketplace の承認を得られるよう、ツールのデータを使用してアプリケーションを強化する方法も示します。Marketplace 認定要件の詳細については、MSDN ライブラリの記事「Windows Phone のアプリケーション認定の要件」(https://msdn.microsoft.com/ja-jp/library/hh184843(v=VS.92).aspx) を参照してください。

今回使用するツールは、すべて Windows Phone SDK 7.1 に同梱されています。Windows Phone SDK 7.1 は、https://www.microsoft.com/downloads/ja-jp/details.aspx?familyid=0a373422-6680-46a7-89e1-e9a468a14259&displaylang=ja-nec からダウンロードできます。

サンプルアプリケーションとテストツール

Marketplace Test Kit と Performance Analysis ツールを実行するために、「Examine the Stamen」というサンプルアプリケーションを作成しました。これは、花を識別する簡単なアプリケーションです。このアプリケーションは、母が花を見分ける能力を上達できるようにと考えて作成しました。このアプリケーションでは、スタート画面に花の小さな画像をいくつか表示し、ユーザーがいずれかの花をタップすると、別のページに移動してその花の大きな写真が表示されます。もう一度タップすると、その花の名前がメッセージボックスに表示されます。アプリケーションの操作に応じて表示する画像を図 1 に示します (ちなみに、これらのスクリーンショットには Windows Phone エミュレーターの新しいスクリーンショットツールを使用しています)。詳細については、MSDN ライブラリの記事「方法: Windows Phone Marketplace 用のスクリーンショットを作成する」(https://msdn.microsoft.com/ja-jp/library/gg442300(VS.92).aspx) を参照してください。

Images Displayed in the Examine the Stamen Program 図 1 Examine the Stamen プログラムに表示される画像

このアプリケーションはまったく現実的なものではありませんが、携帯電話アプリケーションにおいては妥当なナビゲーションモデルです。このアプリケーションを、Visual Studio の Marketplace Test Kit を使って評価した後、Windows Phone Performance Analysis ツールで詳しく分析します。問題が 1 つでも特定されたら、ドキュメントを参考に問題の解決方法を調べ、ツールを使って再度テストします。

では、始めましょう。

Marketplace Test Kit を使用する

「Examine the Stamen」には、相応に魅力的な UI と妥当なナビゲーションモデルを作成しました。今後もっと花を増やす予定ですが、今はアプリケーションを Marketplace に公開することを考えます。これから行うべき手順は、Marketplace Test Kit を使用して、一連の自動テスト、監視対象のテスト、および手動テストで Marketplace へのアプリケーションの対応状況を評価することです。

テストを実行するには、Visual Studio でアプリケーションのプロジェクトを開き、[プロジェクト] メニューの [Marketplace Testkit を開く] をクリックします。

Visual Studio で新しいタブが開き、Marketplace Test Kit のテストスイートが表示されます。図 2 は、このテストキットの最初のページを示しています。

The First Page of the Marketplace Test Kit in Visual Studio 図 2 Visual Studio での Marketplace Test Kit の最初のページ

左側のタブに、使用できるテストスイートが表示されています。[アプリケーションの詳細] タブでは、自動テストを行うアプリケーションのイメージを指定します。自動テストでは、アプリケーションの XAP のサイズ、図像、およびスクリーンショットが認定要件を満たしているかどうかを評価し、アプリケーションで使用している機能を特定します。手動テストでは、アプリケーションを実行する手順が提供されていて、追加の認定ガイドラインに準拠していることを確認します。

今回は、監視対象のテストに注目します。4 つすべてのテストスイートの詳細については、MSDN ライブラリの「Windows Phone Marketplace Test Kit」(https://msdn.microsoft.com/ja-jp/library/hh394032(VS.92).aspx) を参照してください。

監視対象のテストスイートでは、アプリケーションが、以下のような重要な認定ガイドラインに準拠しているかどうかを評価します。

起動時間
ピーク時のアプリケーションメモリ使用量
戻るボタンの処理
ハンドルされない例外によるアプリケーションの予期しない終了

監視対象のテストを実行する

監視対象のテストを実行するには、アプリケーションのリリースビルドを起動し、デバイスに配置して (エミュレーター上ではテストは動作しません) 操作する必要があります。これを構成するオプションは、Visual Studio の標準ツールバーに用意されています。監視対象のテストを実行する際は、ユーザーの操作を想定してアプリケーションを操作し、考えられるナビゲーションパスをすべて実行することを目標にします。その間、テストキットによってアプリケーションが監視され、アプリケーションに関するデータが収集されます。

監視対象のテストによってアプリケーションをテストする際は、短時間にアプリケーションを終了して再度アクティブにした場合、アプリケーションがどのように動作するかもテストします。終了して再度アクティブにするこのプロセスを、"トゥームストーン" と呼びます。Windows Phone 7.5 では、アプリケーションは、トゥームストーン状態になる前に自動的に休止状態になります。

デバッグやテストを行うためにアプリケーションをすばやく強制的にトゥームストーン状態にするには、プロジェクトのプロパティで、[デバッグ] タブの [デバッグ中の非アクティブ化時に廃棄する] チェックボックスをオンにします。[プロジェクト] メニューの [プロパティ] をクリックして、プロジェクトのプロパティを開きます。図 3 は、このチェックボックスをオンにした状態を表示しています。トゥームストーンの詳細については、MSDN ライブリの「Windows Phone の実行モデルの概要」(https://msdn.microsoft.com/ja-jp/library/ff817008(v=VS.92).aspx) を参照してください。

Selecting the Option to Test Tombstoning in Project Properties 図 3 トゥームストーン処理をテストするためのプロジェクトのプロパティにおけるオプションの選択

これらのオプションを構成し終わったら、[Marketplace Test Kit] タブに戻ります。開発者によって登録されたデバイスをつなぎ、テストキットの [監視対象のテスト] ページで [アプリケーションを起動] をクリックします。

アプリケーションを起動したら、花を選択して名前をタップした後、戻るボタンを押してアプリケーションのスタートページに戻るというように、ページを前後にナビゲーションする操作を行います。スタートボタンをタップ後戻るボタンをタップして、アプリケーションを強制的にトゥームストーン状態にして再開します。

一般的なユーザーを想定した方法で操作し、アプリケーションをトゥームストーン状態にして再度アクティブにしたら、アプリケーションとテストセッションを停止します。最善の結果を得るようにテストセッションを終了するには、アプリケーションのスタートページで戻るボタンを押してアプリケーションを終了します。テストキットの [監視対象のテスト] ページで [アプリケーションを終了] をクリックすることもできますが、最も正確なテスト結果を得るため、戻るボタンを使ってアプリケーションを終了します。アプリケーションが終了すると、監視セッションも終了します。

テストセッション終了後、テストスイートによって結果の分析中であることが、テストキットの結果を示すステータスバーに表示されます。分析が完了すると、結果の表が更新されます。

アプリケーションの結果 (図 4 参照) は意外なものでした。

Test Results Showing Two Failures 図 4 2 つのエラーが表示されたテスト結果

アプリケーションは、このテストスイートの 4 つのテストのうち、2 つのテストでエラーになりました。起動時間があまりに遅く、メモリを使いすぎています。詳しく調査しましょう。

Performance Analysis ツールを使用する

一般に、アプリケーションが Marketplace で普及するには、高いパフォーマンスと応答性が必要です。最低でも、テストキットで判明したパフォーマンス上の問題は、調査して修正します。Windows Phone Performance Analysis ツール (プロファイラーとも呼ばれます) は、そのどちらのシナリオにも使用できます。

いったんテストキットを閉じ、プロファイラーを使用してアプリケーションの起動時間とメモリの問題を調べましょう。プロファイラーは、アプリケーションに存在する潜在的な問題や、その問題を修正するために考えられる解決策を把握できる優れたツールです。

プロファイラーには、2 つのオプションがあります。

実行のプロファイリング: 実行プロファイラーでは、アプリケーションのフレームレート、CPU 使用率、および全般的なメモリ使用量が評価されます。実行プロファイラーを使用すると、フィルレートを測定したり、作成される表示要素の数など、アプリケーションの実行に関する詳細を把握することができます。こうした詳細は、アプリケーションのパフォーマンスに影響を与える可能性があります。
メモリのプロファイリング: メモリプロファイラーでは、メモリ使用量、画像の読み込み数、およびガベージコレクションのイベント数が表示されます。メモリプロファイラーを使用すると、メモリ使用量の傾向を把握できます。これによってメモリリークが判明することもあります。

アプリケーションの問題がメモリの問題だけであることがわかっている場合を除いて、実行プロファイラーを選択します。今回はメモリに問題があることはわかっていますが、起動時間の問題も気になるため、まず実行プロファイラーでアプリケーションを調べることにします。

Visual Studio で開いているアプリケーションプロジェクトで、[デバッグ] メニューの [Windows Phone パフォーマンス分析の開始] をクリックします (注: Visual Studio Premium または Ultimate を使用している場合、[パフォーマンス分析の開始] は Windows Phone プロジェクトに適用できないため、使用しないでください)。

Performance Analysis ツールを開くと、Visual Studio で、現在のプロファイリングセッションの名前が表示された新しいタブが開きます。名前は、プロジェクト名とプロファイリングセッションの日時で構成されていて、その後ろにプロファイリング結果ファイルに使用される .sap サフィックスが付けられます。これらのファイルは常にプロジェクト内に保存されるため、複数回表示することが可能です。図 5 に、テストを実行する前のパフォーマンス分析用のタブを示します。

The Performance Analysis Tab Before Any Tests Have Been Run 図 5 テストを実行する前のパフォーマンス分析用タブ

プロファイラーのタブで、[実行] をクリックします。最良の結果を得るため、Visual Studio のツールバーにある配置とデバッグのオプションを指定するボックスで [Windows Phone Device] と [Release] が選択されていることを確認し、デバイスがつながっていてロックが解除された状態になるようにします。(注: プロファイラーの使用時はアプリケーションをエミュレーターに配置できますが、結果はデバイスでのパフォーマンスと同等の結果を示さない場合があります)。

[アプリケーションの起動] をクリックして、プロファイリングセッションを開始します。Marketplace Test Kit と同様、ユーザーによる操作を想定してアプリケーションを操作し、少なくとも 1 回はアプリケーションをトゥームストーン状態にして再開するようにします。Performance Analysis ツールの [プロファイルの停止] をクリックしてプロファイリングセッションを終了することもできますが、ここでは戻るボタンを使用してアプリケーションを終了します (最も正確な結果を得るためには、この方法でセッションを終了することをお勧めします)。プロファイラーによる結果は、分析に少し時間がかかりますが、ページにグラフ形式で表示されます (図 6 参照)。この結果はとても興味深いものでした。

Results of a Performance Analysis Test 図 6 パフォーマンス分析テストの結果

グラフに表示された CPU 使用率の緑色の部分は、画面の更新とタッチ入力を示しています。最初に高い CPU 使用率が見られますが、起動時間の遅さを考えれば驚くことではありません。また、画像が読み込まれる際にも CPU 使用率が大幅に急増しており、同時にメモリ使用量も徐々に増加しています。詳しく調査しなくてもこの結果を見れば、アプリケーションでの画像処理方法がメモリ使用量の問題に関係している可能性が高いことがわかります。アプリケーションで使用するメモリは、アプリケーションの終了と同時に解放されます。しかしこのグラフから考えると、テスト時間より数秒長くアプリケーションを実行すると、デバイスがクラッシュする懸念があります。

この状態で、[メモリ] オプションを選択して Performance Analysis ツールを再実行すると、増え続けるメモリ使用量の問題が裏付けられます。

問題を見つけて修正する

プロファイリングツールを使用して問題を見つけ出すには、グラフで問題のある領域を選択して、[監視の概要] セクションの指示を確認します。

実行プロファイラーの結果のグラフで、CPU 使用率の急増が見られる部分を選択します。[パフォーマンスの警告] セクションがすぐに更新され、調査すべき問題が表示されます (図 7 参照)。

A Performance Warning About High CPU Usage on the UI Thread 図 7 UI スレッドでの高い CPU 使用率に関するパフォーマンスの警告

監視の概要によると、アプリケーションでは UI スレッドの関数を実行するのに多くの CPU を使用しています。これによって、起動時間が遅くなったりパフォーマンス全体が低下したりしていることは間違いありませんが、メモリの問題がこれに起因しているかどうかは不明です。プロファイラーの優れた点は、従うべき指示が表示されることです。そこで、その指示どおりに作業します。[パフォーマンスの警告] メニューで、[CPU 使用率]、[関数] を順にクリックします。表が更新されるので、表示された表を [包括サンプル %] 列で並び替えます。アプリケーションによる関数の呼び出しは、名前空間名 (ここでは、疑い深く MemoryLeak とします)、クラス名、およびメソッド名からなる完全修飾名が付けられ、青く表示されます。また、関数の呼び出しはコード内のメソッドへのリンクになっています。図 8 に、これらの結果を示します。

The Peformance Analysis Tool Shows Methods That Might Be Causing Problems 図 8 問題の原因となっている可能性のあるメソッドが表示された Peformance Analysis ツール

この結果を見ると、2 ページ目を読み込む際、メソッドを実行するのに多くの CPU を使用していることがわかります。起動時間に関する問題の解決にはならないでしょうが、メモリの問題の一因となっている可能性があることは確実です。

リンクをクリックして、FlowerPage.OnNavigatedTo メソッドを確認します。このメソッドでは、花のオブジェクトの一覧を作成し、LoadBitmap メソッドを使用して各花のビットマップを読み込みます。通常の LoadBitmap メソッドの呼び出しを以下に示します。

bitmap = LoadBitmap("/MemoryLeak;component/Images/tulip.jpg");

そして、リソースを読み込む LoadBitmap メソッドです。

private BitmapImage LoadBitmap(string urlString)
{
  var streaminfo = App.GetResourceStream(new Uri(urlString, UriKind.Relative)); 
  BitmapImage bitmap = new BitmapImage();
  bitmap.SetSource(streaminfo.Stream);
  return bitmap;
}

ユーザーがページに移動すると、メインページでクリックされた花の名前をナビゲーション URI から抽出し、同じ花の画像を FlowerPage に読み込みます。

メモリの問題が画像の読み込みによって発生していることは明らかとなりましたが、次は何をすればよいでしょう。

監視の概要で提供される情報では不十分で、アプリケーションのパフォーマンスの問題を解決できない場合は、MSDN や Web でパフォーマンスガイダンスを確認することをお勧めします。役に立つリソースをいくつか次に示します。

「Windows Phone 用アプリケーションのパフォーマンスに関する考慮事項」(「メディア」セクション) (https://msdn.microsoft.com/ja-jp/library/ff967560(VS.92).aspx#BKMK_Media)
「Windows Phone のパフォーマンス向上のテクニック」(https://msdn.microsoft.com/ja-jp/library/hh202904(VS.92).aspx)
Silverlight for Windows Phone パフォーマンスチームのブログ (wpdev.ms/slmperf、英語)
Windows Phone アプリケーションのパフォーマンスを分析し、向上させる (MIX 11 のビデオ) (wpdev.ms/mixwpperf、英語)
エキスパートレッスン: 成功する Windows Phone アプリケーションをビルドするためのヒント (MIX11 のビデオ) (wpdev.ms/mixwptoptips、英語)

パフォーマンスの調査とアプリケーションへのリソースの読み込みを開始して、重要な事項がないか確認します。「Windows Phone 用アプリケーションのパフォーマンスに関する考慮事項」の「メディア」セクションによると、Windows Phone はファイルを使用するように最適化されているため、画像ファイルはリソースではなくコンテンツとして設定する必要があります。メディアファイルをリソースとしてコンパイルすると、使用前にコンテンツがファイルにコピーされます。これが、パフォーマンスを低下させる原因です。

画像ファイルのビルドアクションを [コンテンツ] に変更し、これに合わせてコードに少し変更を加えます。

LoadBitmap メソッドで、SetSource を呼び出すのではなく、BitmapImage の UriSource を指定します。

private BitmapImage LoadBitmap(string urlString)
{
  BitmapImage bitmap = new BitmapImage();
  bitmap.UriSource = new Uri(urlString, UriKind.Relative);
  return bitmap;
}

LoadBitmap を呼び出したら、各ビットマップに関連 URL を渡します。

bitmap = LoadBitmap("/Images/tulip.jpg");

テストキットツールと Performance Analysis ツールを再実行する

Marketplace Test Kit と Performance Analysis ツールによって明らかになった問題を解決したら、これらのツールを再度実行しましょう。

アプリケーションを再コンパイルして Marketplace Test Kit を再び実行すると、結果に信じられないほどの違いが現れます (図 9 参照)。これで、アプリケーションは 4 つすべてのテストに合格です。起動時間はすばらしいとは言えませんが、少なくとも合格点には達しています。

Changing Image Handling Results in Passing All Four Marketplace Tests
図 9 4 つすべての Marketplace Test Kit テストに合格したことによる画像処理結果の変化

最後に、実行プロファイラーを実行します。結果が大きく違うのがわかります (図 10 参照)。

Image Handling Changes Result in CPU and Memory Performance Analysis Improvements
図 10 画像処理の変化による CPU とメモリのパフォーマンス分析結果の向上

これで、ユーザーがページ間を移動するたびに CPU 使用率が大幅に急増したり、画像が繰り返し読み込まれたりすることはなくなり、画像はアプリケーションの起動時に一度だけ読み込まれるようになります。このグラフでは、アプリケーションのメモリ使用量が一定に保たれていて、変更を加える前のアプリケーションより比較的少ないことも確認できます。次に、CPU 使用率の増加が少ない箇所を選択して、結果 (図 11 参照) を確認します。

Investigating a CPU Spike Shows No Performance Warnings
図 11 CPU 使用率の急増を調査したことによって表示されなくなったパフォーマンスの警告

プロファイラーではパフォーマンスの問題が検出されず、ひと安心です。次は、アプリケーションを Marketplace に提出するための計画を立てます。アプリケーションが承認されるという確信はありますが、引き続きアプリケーションを改良して、必要があれば更新プログラムを提出することも可能です。

今回のパターンを利用する

今回は、Marketplace Test Kit と Performance Analysis ツールを使用して、サンプルの Windows Phone アプリケーションに存在する問題を特定して解決する方法を説明しました。これらのツールは、Visual Studio に統合されており、Windows Phone SDK の一部としてインストールされます。Marketplace Test Kit では、アプリケーションが認定要件を満たしているかどうかを判断でき、Performance Analysis ツールでは、メモリや CPU のパフォーマンスに関する問題を特定できます。アプリケーションを Marketplace に提出する前に、今回紹介したパターンと同様のパターンに従うことをお勧めします。

ここで紹介したツール (Marketplace Test Kit のテストスイートすべてを含む) を使用する
すべての問題を特定して解決する
再度テストして問題が修正されたかどうかを確認する

このパターンに従えば、問題を早く見つけて、より良いアプリケーションをすばやく作成できますし、アプリケーションは一度目の提出で Marketplace から承認を得られるようになるでしょう。

Cheryl Simmons は、マイクロソフトの Windows Phone 開発者向けコンテンツチームでシニアプログラミングライターを務めています。

この記事のレビューに協力してくれた技術スタッフの Pratap Lakshman、Raghuram Lanka、および Nitin Madnikar に心より感謝いたします。