Silverlightというと、どうしてもユーザインターフェース部分の技術にばかり目がいきがちですが、RIA(Rich Internet Applications)登場の背景[1] を考えれば、「 アプリケーションの配布」も押さえておきたい重要な要素です。
[1] 2000年代前半、クライアントサーバ型の業務アプリケーションは同時接続数問題とクライアントへの配布問題を抱え、Webアプリケーションへと移行する動きが活発化しました。Webアプリケーション化したことで、配布の手間がなくなり管理コストは大きく下がりましたが、エンドユーザからはアプリケーションの操作性に関する不満の声が上がりました。2000年代中盤になると、Ajax(Asynchronous JavaScript+XML)を活用し、飛躍的に操作性を高めた業務アプリケーションも登場するようになりますが、開発効率やその後の保守性といった面で課題が残りました。
このような流れから、クライアントサーバ型アプリケーションの高い操作性とWebアプリケーションの配布のしやすさとが両立するアプリケーション形態として、RIA(Rich Internet Applications)が注目されるようになりました。
本稿では、Silverlight業務アプリケーションの配布における重要なポイントを、アプリケーションの提供側と利用者側の両方の視点を踏まえ、解説します。
Silverlightランタイムのインストール
そもそもクライアントにアプリケーションをインストールするという概念が存在しないのが、HTMLベースのWebアプリケーションです。Silverlightでも、アプリケーションそのもののインストールは不要ですが、アプリケーションの実行基盤であるSilverlightランタイムはインストールが必要となる場合があるため、まずここを押さえておかねばなりません。
Silverlightランタイムの普及率
エンドユーザのPCにすでにSilverlightランタイムがインストールされていれば、インストール作業は不要です。Rich Internet Application Statistics というサイトで公開されている、日本国内のSilverlightランタイム普及率を見てみると、下のグラフのようになっています。
図1 Silverlightのバージョン別普及率 ※2011年8月の統計
なお、いまのところ OSにSilverlightランタイムはプリインストールされていませんが、PCメーカーが出荷時にプリインストールしているPCはいくつか存在します。
Silverlightランタイムのサイレントインストール
1台でもSilverlightランタイムがインストールされていない環境があれば、インストール作業は避けて通れません。とくに、ハードウェアと一緒にアプリケーションをエンドユーザへ納品するようなケースでは、一度に何十台、何百台といったPCへのインストールが発生します。Silverlightランタイムは、WSUSやActive Directoryのグループポリシーなどを使って、複数台のPCに対してサイレントインストールさせることが可能です。これらのSilverlightランタイムの展開方法については、下記の「Silverlight デプロイメントガイド」に詳細な内容が記載されていますので、こちらを確認しておくとよいでしょう。
Silverlightランタイムのサイズ
一方、Silverlightランタイムのインストールにエンドユーザの介在が発生する場合、ダウンロード時間とインストール時間に直接的な影響を及ぼすSilverlightランタイムのインストーラサイズは、重要な要素です。Silverlightは、最初のバージョンである1.0の時点からこの点を重要視しており、最新のバージョン4でもそのサイズは5MB台に抑えられています。
なお、実際のインストールにかかる時間は環境によって異なりますが、筆者の手元にある4年前のPCですら16秒程でインストールが完了しました。この結果から、多くのPCにおいて20秒以内でのインストール完了が期待できます。
Silverlightアプリケーションのサイズ
Silverlightランタイムのダウンロードは初めの1回だけで済みますが、アプリケーションのダウンロードは基本的に毎回発生します。そして、アプリケーションのダウンロード時間は、エンドユーザにとってはアプリケーションの起動時間そのものとなるため、Silverlightにおいてアプリケーションのサイズはとても重要な要素となります。
Silverlightアプリケーションにおいて、アプリケーションのサイズ肥大化の要因となる要素はいくつか存在しますが、最も大きな割合を占めるのはアプリケーションで使用している外部ライブラリの存在です。
アプリケーションサイズ肥大化の大きな要因
先の項目で、Silverlightは、ランタイムのインストーラサイズをできる限り小さくすることに努めていることを紹介しました。このため、Silverlightでは、標準クラスライブラリであってもその一部はSilverlightランタイムに含まれていません。それらは外部ライブラリとして扱われ、アプリケーションの一部としてXAPファイル[2] という形式にパッケージ化されます。
たとえば、業務アプリケーションでよく使われるデータグリッドは、「 System.Windows.Controls.Data.dll」というアセンブリ内に含まれており、Silverlightランタイムには含まれていません。そのため、データグリッドを使用するアプリケーションでは、必ず「System.Windows.Controls.Data.dll」がXAPファイルに含まれることになります。
以下の図は、同じデータをリストボックスに表示した場合とタブコントロール上のデータグリッドに表示した場合に、アプリケーション(XAPファイル)のサイズがどのくらい違うかを表したものですが、この程度の小さなサンプルでも倍くらいのサイズに肥大化してしまうことを確認できます。
図2 XAPファイルのサイズ比較
XAPファイルのサイズ
317KB 613KB
外部ライブラリのパッケージ化を工夫することによるXAPファイルのサイズ削減方法は、大きく分けて3つの方法が存在します。
アプリケーションライブラリキャッシュを使用する
アセンブリをオンデマンドで読み込む
ツールによる最適化でアセンブリサイズを小さくする
[2] Silverlightでは、アプリケーション本体のDLLファイル(アセンブリ)や画像などのリソース、外部ライブラリなど、アプリケーションで必要となるファイルすべてがZIP圧縮され、XAPファイルという1つのファイルにパッケージ化されます。Silverlightアプリケーションのサイズは、イコール、XAPファイルのサイズであると言えます。
アプリケーションライブラリキャッシュを使用する
Silverlightでは、外部ライブラリのアセンブリをパッケージ化せずにXAPファイルの外に出し、Webブラウザにキャッシュさせるといった設定が「アプリケーションライブラリキャッシュ」という名称で用意されています。この方法を使用した場合、エンドユーザが初めてアプリケーションを利用する際には、外部ライブラリを含むアプリケーションに必要なすべてのファイルがダウンロードされますが、その際に外部ライブラリはWebブラウザにキャッシュされるため、2回目以降はアプリケーション本体のアセンブリのみがダウンロードされます。具体的な設定方法は、以下のページに記載されています。
この方法は、ライブラリの更新頻度がアプリケーションの更新頻度よりも低い場合に有効です。ただし、ブラウザ外実行ではこの方法を使用することができないため、注意が必要です。
アセンブリをオンデマンドで読み込む
アプリケーションの起動時には最小限の外部ライブラリだけを読み込むようにしておき、必要になった際に都度外部ライブラリを動的に読み込むようにすることで、アプリケーションの起動時間を短くすることができます。具体的な方法は、以下のページに記載されています。
この方法は、Silverlightの機能として用意されているわけではないため、必要になったタイミングで外部ライブラリのアセンブリをダウンロードし、それをもとに処理を行うといった部分をある程度作り込む必要があります。また、そのような動作に合わせてアプリケーション全体の構成をうまく調整する必要があるため、採用のハードルは比較的高いと言えます。
ツールによる最適化でアセンブリサイズを小さくする
外部ライブラリはアセンブリといった単位で分けられていますが、実際にはそのアセンブリに含まれているすべてのクラスを使用しているわけではありません。たとえば、先の図2の例ではデータグリッドとタブコントロールを使用したことで「System.Windows.Controls.Data.dll」と「System.Windows.Controls.dll」という2つのアセンブリがXAPファイルに追加されています。しかしながら、「 System.Windows.Controls.Data.dll」ではDataPagerクラス、「 System.Windows.Controls.dll」ではDatePickerクラスなど、これらのアセンブリにはアプリケーションで使用されていない多くのクラスが存在しています。
これら使用されていないクラスをXAPファイルから削除し、Silverlightアプリケーションを最適化するのが、XapOptimizerというツールです。XAPファイル内のアセンブリを解析し、使われていないクラスやXAMLリソースを削除することで、アプリケーションサイズを小さくします。また、クラス名を、意味を持たない文字列に置き換える難読化機能も備えており、リバースエンジニアリングを困難にすることも可能です。XapOptimizerは、アプリケーションのスリム化と知的財産権の保護を一度に実現します。
XapOptimizer 1.0J
http://www.grapecity.com/tools/jp/?g/xapoptimizer/
先のデータグリッドとタブコントロールを使用したアプリケーションをXapOptimizerで解析すると、下の図のように「System.Windows.Controls.dll」ではCalenderやChildWindowといった多数のクラスが使用されていないことを確認することができます。
図3 XapOptimizerによるアプリケーションの解析結果 ※灰色の文字で書かれたクラスが使用されていないクラス
これらの使用されていないクラスをXAPファイルから除外することで、613KBあったXAPファイルは下の図のように469KBにスリム化されます。
図4 XapOptimizerを使って最適化を行った結果
XapOptimizerを試してみる
XapOptimzerはデモアプリケーションが用意されています。デモアプリケーションでは5MB以上のXAPファイルを最適化できないなどいくつかの制限がありますが、実際に試すことが可能です。ぜひ、お手持ちのサンプルアプリケーションなどを使って試してみてください。
XapOptimizerデモアプリケーション
http://www.grapecity.com/tools/jp/?g/xapoptimizer/demo/
図5 XapOptimizerデモアプリケーション