プログラマから見たWindows 10 #3 ~UWP Bridgeとは

開発の橋本孔明です。

7月29日にWindows 10の正式版がリリースされました。
Windows 10では、ストア アプリを増やすための施策が用意され、そのひとつが「UWP Bridge」と総称される技術群です。UWP(Universal Windows Platform) Bridgeには、「Westminster」「Centennial」「Astoria」「Islandwoods」の4種類がありますが、今回はその概要を解説します。

4種類のUWP Bridge

LogoHTML5 Project Westminster(ウェストミンスター)

  • WebブラウザコントロールをUWPアプリ化する
LogoWindows Project Centennial(センテニアル)

  • .NET、Win32で作成された.MSIをUWPアプリ化する
    (生成されたUWPはWindows Mobileでは実行できない)
LogoAndroid Project Astoria(アストリア)

  • Android(Java/C++)の.APKをUWPアプリ化する
LogoAppStore Project Islandwoods(アイランドウッズ)

  • iOSのObjective Cソースを元にUWPアプリ化する

Windows 10正式版について

7月29日、待望のWindows 10正式版のリリースが開始されました。
実際にリリースされたのはBuild 10240で、Insider Previewの最終バージョンと同一のものでした(Windows Updateでの更新やアプリの更新が含まれるため、完全に同一なものではありませんが)。

さて、前回の番外編「Windows 10へのアップグレード抑止設定ツール」は、多くの反響をいただきました。Windows 10はメジャー バージョンアップとしては初の「無償アップグレード」となっているため、既存Windowsユーザーの注目度もひときわ高いものと思われます。
もちろん、基本的には「最新のWindowsを使う」ことが推奨されます。

Windows 10では様々な新機能の他に「OSコア部分のチューニング」がWindows 8.1以上に進められており、OS本体のディスク占有量の低減、OS側のメモリ使用量の削減など、タブレット端末での使用ケースの増加を見据えた軽量化が行われ、同時に全体的な動作も高速化していますので、特にWindows 7からのアップグレードでは目に見えてパフォーマンス向上を体感できるのではないかと思います。

同時に、やはり一部のアプリやハードウェアの互換性の問題により、すんなりとWindows 10への移行が行えないケースもあります。筆者の2011年モデルのMacBook Air(BootCamp+Windows 7)をWindows 10にアップグレードしてみたところ、Apple TouchPadのドライバが動作しなくなり、タッチパッドが使用できませんでした。
もともとこのモデルはWindows 8にも非対応だったのでそれについては仕方ないと考えていますが、汎用的なパーツを多用しているデスクトップ機はまだしも、Windows 7時代に登場したノートやタブレットなど、特殊ハードウェアを多用しているデバイスでは問題が起こりやすくなっているものと思われます。
ちなみに、当該のMacBook Airでは、「Windows 7に戻す」を選択したところ、ものの数分で元のWindows 7環境が無事に復元されました。

アプリ開発の新機軸

筆者もさっそくメインの開発環境をWindows 10に変更し、Visual Studio 2015などもインストールしてWindows 10対応の準備を進めています。

そのWindows 10では、Windows 8/8.1時代に「ストア アプリが少ない」とさんざん言われてきたことへの対応としてなのか、アプリを増やすためのさまざまな施策が用意されています。そのうちのひとつが「UWP Bridge」と総称される技術群です。
「UWP Bridge」には大きく分けて4つの技術が含まれているのですが、共通しているのは「他プラットフォーム向けに展開されているアプリやコンテンツを、UWPアプリ(一部は「UWPアプリのようなもの」)として簡単にコンバートし、Windows ストアに登録してもらおう」という点です。

すでに各所で紹介されている内容が多く含まれているものの、今回はこの4つを紹介します。特に後半2つはMicrosoftの「本気度」がうかがえます。

Project Westminster(ウェストミンスター)

LogoHTML5

AndroidやiOSのアプリには、ウェブブラウザ コントロール1つだけを全画面で表示し、そこに表示されるウェブサイト側でコンテンツを用意する、いわゆる「ハイブリッド アプリ」、スマホの世界では「ガワネイティブ」と呼ばれる種類のものがあります。

Project Westminsterは、まさにこのようなタイプのUWPアプリを簡単に作るための機構です。Visual Studioに、対象となるウェブサイトのURLやアクセス権の設定などを記述したプロジェクトファイルを読み込ませるだけで、UWPアプリとして出力することができます。
Project Westminsterで作成されたアプリでは、その中で動作するJavaScriptからWindows 10のAPIを呼び出すことができる機構も用意されているので、Windows 10固有の機構(タイル通知など)に対応させることもできます。

Project Westminsterは、UWP Bridgeの中では一足先に正式版が実装されました。詳しくは下記のウェブサイトを参照してください。

Project Westminster紹介ページへ

Project Centennial(センテニアル)

LogoWindowsProject Centennialは、従来のCWA(Classic Windowsアプリ)を、Windows ストアで配信できる「UWPアプリのようなもの」に変換するという機構です。Classic Windowsアプリとは本連載の第2回「プログラマから見たWindows 10~アプリケーション互換性 #2で紹介したように、ネイティブのWin32アプリあるいは.NET Frameworkアプリ(Windows FormsまたはWPF)のことです。
「UWPアプリのようなもの」と書いたとおり、完全なUWPアプリとしてのスペックは満たしません。例えば、これで作ったアプリの動作はデスクトップ版のWindows 10に限られ、Windows 10 Mobileなどでは動作しません。

Project Centennialで変換するための元となるものは「MSIパッケージ」です。普通のデスクトップ アプリを作った場合、必要となるファイルを集めたインストーラ パッケージを作成して配布することが多いわけですが、それらの配布形態のうちMSI形式で作成したパッケージを解析・変換することで、UWPアプリとしてのパッケージを生成します。ですので、MSI以外で配布パッケージを作成している場合は、まずそこから変更する必要があります。

変換元のデスクトップ アプリで使用していた各種Windows APIの呼び出しは管理された同名のAPIへとマッピングされ、レジストリやAppDataフォルダへのデータ保存といった、システムを「汚す」要素は各アプリ専用のデータストレージ内にリダイレクトされるようになります。

また当然ながら、膨大なWindows APIのすべてをUWPアプリのプラットフォームがサポートしているわけではありません。古いAPIや特殊用途のAPIには対応していないものも多いでしょうし、特殊なファイル操作を行ったり、複数のプロセスの連携やシステム フックを使うような複雑な構造のアプリにも対応できないものと考えられます。

さて、Project Centennialでアプリを変換・配布することには、従来の配布形態を続けることと比べてどのようなメリットが考えられるのでしょうか。

現在言われているシナリオとしては

  • ストア配信となるため、課金をMicrosoft任せにでき、独自の販売システムを構築する必要がない
  • プロモーション機能が弱いベンダーでも、アプリの内容次第ではMicrosoftによるプロモーションが得られる
  • アップデートやアンインストール、β版やトライアル版の提供といった仕組みもMicrosoft側が提供してくれる
  • ユーザーのOS環境(レジストリ、システム ファイルなど)を不必要に汚してしまうことが無い
  • アプリは保護環境下で動作するため、万一の誤動作でシステムを破壊してしまったりする危険性が少ない

などが挙げられます。

基本的に、「ファイルを作成または読み込む」「編集する」「ファイルを保存する」という、典型的な「ファイル編集型」のアプリが変換候補となるでしょう。

Project Astoria(アストリア)

LogoAndroid簡単に書くと「Windows 10 MobileでAndroidアプリを動かせるようにするフレームワーク」です。こちらもProject Centennialと同様に「UWPアプリのようなもの」になるだけで、Project Centennialとは逆に、デスクトップ版のWindows 10では動作しないものとなります。

動作構造としては、AndroidアプリのAPKパッケージ(Java、またはNDKとC++言語で開発したもの)をそのままラップしたUWP版のアプリ パッケージを作成し、それをWindows ストアで配信します。Windows 10 Mobileには、このアプリを動作させるためのAndroid互換サブシステムがWindowsカーネルの直上に組み込まれる予定です。
初期の一部報道ではこの情報が誤解され、「Windows 10 MobileではAndroidアプリが動作する」といった表現も見られましたが、上記のようにあくまで「開発者が変換」したアプリだけが動作するものなので注意が必要です。

ちなみに、AndroidアプリでGoogle Mapsを使用している場合はBing Mapに、Google Adsを使用している場合はBing Adsにリダイレクトされるとのことです。

また、どうしても構造が異なってしまうアプリ内課金システム関係や、Windows 10固有の機構へアクセスするため、変換対象となるAndroidアプリ上のコードから使用できるAPIセットも提供されるようです。

Project Islandwoods(アイランドウッズ)

LogoAppStoreAstoriaがAndroidアプリ対応なのに対し、IslandwoodsはiOSアプリを動作させるための仕組みです。各プロジェクトの頭文字が合わせてありますので覚えやすいでしょう。
ただ、IslandwoodsはAstoriaとは動作原理が全く異なるものとなります。

こちらは、VisualStudio 2015に「Objective-Cコンパイラ」「Xcodeプロジェクト インポータ」「iOS API(NS***)互換ライブラリ」を追加し、iOSアプリを再ビルドするだけでUWPアプリとしてビルドできるようにする仕組みです。Astoriaが、配布用のAPKパッケージを元に変換するのに対し、こちらはソースコード レベルで互換性を確保します。
Astoria同様、Windows 10固有の機構に対応するためのAPIがObjective-Cバージョンとして用意されるでしょう。

Build 2015では、有名なiOSゲーム アプリ「Candy Crush Saga」を実際にコード無変更でビルドし、動作するデモが披露されました。

iOSといってもいろいろなバージョンがありますが、Microsoftでは具体的にどのバージョンに対応ということは示さず、よく使われているAPIを中心に順次実装を進めていく予定とのことです。

終わりに

UWP Bridgeは、絶対数の不足を指摘されることが多い、ストア登録アプリの増加を狙ったMicrosoftの野心的な取り組みであるといえるでしょう。

ただ、残念ながら現時点ではProject Westminsterを除いて一般的に試せる状態ではなく、今夏を目処に追加情報が発表される予定にとどまっています。今後に期待していきたいと思います。

また、ウェブテクノロジはCWAのみならず、Android・iOSアプリ資産も多く保有していますので、UWP Bridgeの研究を進めていきたいと考えています。

タグ: , , , , | 2016/08/31 更新 |

コメントはこちら