Windows 11のフォトアプリがUWPからWin32アプリになったことで今更わかるUWPの問題点

Windows 11のフォトアプリは、WinUI 2を使うUWPアプリから WinUI 3を使うDesktopアプリに切り替わった

　現在のWindows 11に搭載されている「フォト」アプリは、UWPではなくWindows App SDKを使うDesktopアプリ（Win32アプリ）になっている。

WinUI 3を使うDesktop/Win32アプリケーションになったフォトアプリ。写真をクリックすると、別ウィンドウが開き、複数のビューアーウィンドウを同時に開くことができる

　簡単に言えば、フォトアプリ（Photos.exe）は、通常のEXE実行ファイルである。また、従来のUWP版フォトアプリは、現在では「Microsoft フォト レガシ」として、Microsoftストアから入手が可能だ。

旧フォトアプリは、現在では「フォトレガシ」と呼ばれ、Microsoftストアからインストールが可能。画像をクリックすると、同じウィンドウ内に画像が開き、複数ウィンドウを同時に開くことができない

　フォトアプリは、WinUI 2を使うUWPアプリから、今年の4月頃にWinUI 3を使うDesktopアプリに切り替えられた。ある意味でフォトアプリは、WinUI 2（UWP）からWinUI 3への切り替えの「サンプル」的な要素があった。

　WinUI 3は、かつてはProject ReUnionと呼ばれていたものだ。UWPでしか利用できなかったWinUIなどをDesktopアプリケーションで利用できるように作られた。このあたりについては、以前の記事を参照してほしい（「UWPからデスクトップアプリに回帰すべく、MSが送り出した「Project REUNION」」）。Windows App SDKは、UWPの見栄えを持つDesktop／Win32アプリケーションを開発するためのものと言える。

　1981年のMS-DOSからPCに関わるMicrosoftは、多数の技術を生み、新しい技術で古い技術を置き換えてきた。ただ、互換性を保つことは守られており、互換性の問題でいきなりアプリが起動不可能になることはほとんどない。

　ここ数年ぐらいは、利用率が減った旧技術の廃棄には積極的で、Windowsの内部モジュールに関しても積極的に書き換えている。書き換えが多い分、アップデートごとの修正項目も少なくない。しかし、好意的に解釈すれば、Windows自体の更新に積極的になったのだとも言える。

　Windows 8のストアアプリを発展させ、Windows 10でマルチプラットフォームを目指したUWPアプリには、新しいWinUIという見栄えのするユーザーインターフェース（UI）技術が組み込まれた。しかし、いかんせん人気がなく、従来のDesktopアプリで も動作できるWinUI 3を開発し、Windows App SDKとして提供することになった。

UWPが抱えてた問題の1つはWindows自体のアップデートと 同じタイミングで更新する必要がある点

　フォトアプリはUWPであるがゆえに、いくつかの問題を抱えていた。WinUI3化、Desktopアプリケーション化は、その問題から抜け出すために必要なことだった。逆に言えば、UWPにはそれだけの問題があったということだ。

　大きな問題の1つは、UWPはWindowsの機能にのみ依存するため、Windows自体のUpdateと同じタイミングで更新する必要があることだ。特にWindows 10のときには、年2回のアップデートでのみWindowsの機能が追加された。

　このため、従来のフォトアプリは、改良されてWindowsの新機能などに対応したとしても、該当のWindowsが一般に配布されなければ実行できなかった。フォトアプリのプレビュー版を試用するには、プレビュー版のWindowsが実行されていることが必要条件だった。

　Windows 11になって、機能追加のタイミングは増えたが、それでも最短で月1回のアップデートでしかWindowsに新機能が追加されない。実際にはそこまで多くはなく、新機能の追加は2～3ヵ月に1回だ。Windows自体の機能追加にはさまざまな検証が必要になり、頻繁にするのは難しい。また、追加機能によってはWindows SDK側の更新も必要になる。

　UWPアプリの配付は、Windowsのアップデートが完了しないと開始されない。個々のユーザーのWindowsは、世界中で一斉にアップデートされるのではなく、ある程度の時間幅（数日から1週間程度）をもって実施される。

　さらに特定ハードウェアなどのインストール問題があれば、Safeguard Holds（「Windows 10で秋の大型アップデートが始まったのに、春のアップデートも落ちてこないマシンがあるのはなぜ？」）により、問題が解決されるまでは特定機種のWindowsのアップデートが一時停止される。となると、世間では複数のWindowsバージョンの上で、複数の異なるフォトアプリが動くことになる。これはサポート上、かなり面倒だ。

　これに対して、DesktopアプリがベースになったWinUI3アプリは、Window App SDKのモジュール更新を、Windows自体のバージョンとは無関係にいつでもできる。配布は、Windowsと同じくWindows Updateを使うが、更新周期は短く、Windows自体よりも少ない作業量で更新が可能。これによりフォトアプリは、高い頻度でアップデートできるようになった。

　フォトアプリは、Windows標準アプリ（Inboxアプリ）であるがゆえに、サポート期間中のWindowsの複数バージョンに対応しなければならない。同一のUWPアプリを複数のWindowsバージョンに対応させると、内部が複雑になってしまう。また、Microsoftストアでは、同じ名前、同じバージョン番号を持つプログラムを複数登録することができない。

　こうした理由から多くのWindows標準アプリのパッケージは複雑な状態となる。Windows 10／11兼用とすると、Windows 10のためのサポートモジュールを入れる必要があるなどパッケージが大きくなってしまう。Windows 10と11でバージョンを変えて2つのパッケージを配布することも可能だが、今度はパッケージの管理が面倒になる。

UWPにはセキュリティを高めるためさまざまな制限がある Desktopアプリになったことで動作が速くなった

　UWPにはセキュリティを高めるためにさまざまな制限が加えられている。これを低整合性（lowIL。Low Integrity Level）と言い、その実行環境をAppContainerと呼ぶ。ここでは、利用できるAPIが制限され、プログラムと分離された状態で実行される。これに対して、従来のWin32/Desktopアプリケーションの実行環境は、midleILと呼ばれ、その実行環境をMSIX Containerという。midleILでは、lowILよりも制限が少なく、システムへのアクセスも大部分が許される。

　UWPではフォルダのアクセスには、ユーザーの許可が必要になる。しかし、従来の画像ビューアーや写真アプリケーションでは、ユーザーが画像を保存しているさまざまなフォルダをスキャンしており、フォトアプリも同程度の使い勝手を実現する必要がある。また、フォルダやファイルのアクセスに対して強いセキュリティチェックがなされ、実行環境が分離されることから、UWPアプリ用に用意されたファイル関連のAPIは、あまり性能が高くなかった。

　そもそも、WinRTやWinUIは、Win32の上に高いセキュリティを持たせて実装されているため、同等のAPIは、速くてもWin32と同程度、場合によっては遅くなってしまう。

　このために、フォトアプリはWin32/Desktopアプリをサービスとして動作させ、Win32APIでファイルのスキャンなどをさせていた。

UWP時代のフォトアプリは、UWPアプリとC++で作成したWin32プログラムがセットになっていて、IPC（Inter Process Communication。プロセス間通信）で接続していた（画像はWindows Developer Blogから引用 https://blogs.windows.com/windowsdeveloper/2024/06/03/microsoft-photos-migrating-from-uwp-to-windows-app-sdk/）

　パッケージにWin32プログラムを入れるには、Full-trustと呼ばれる許可を付けないと、Microsoftストアで配布できない。Microsoft社内からのMicrosoftストア登録がどうなっているのかは知らないが、サードパーティの開発者がFull-trustを得るのは敷居が高い。筆者も、ストアにDesktopプログラムを申請しようとしたとき、条件などを理解しないままFull-trustになってしまい、開発や申請を進めることができなかった

　とまあ、最終的にはあまり行儀の良くないUWPアプリになってしまったフォトアプリだが、それでも高いパフォーマンスが出せなかったという。

　Desktopアプリとなったフォト（Photos.exe）は、Windows本来の速さで動作できる。ただし、Photos.exeは、画像ファイルを表示させるごとに自分自身を起動する。画像表示ウィンドウは、別のプロセスになっている。何も画像を表示させていないときもビューアー用のプロセスが起動しており、画像ウィンドウが開くたびにプロセスが増える。タスクマネージャーでPhotos.exeを探すとわかるが、常に2つのPhotos.exeが起動しており、コマンドラインを表示させると、2つ目のPhotos.exeには、「ms-photos:spareprocess-viewer」というオプションが付いている。

現在のフォトアプリ（Photos.exe）は起動すると、自分自身をもう1つビューアーウィンドウ用に起動する。画像は、ビューアーウィンドウ用プロセスの子プロセスが表示する。すでにプログラムはメモリ中に読み込まれているため、高速に画像を表示することが可能

　2つ目以降のPhotos.exeのビューアープロセスは、最初のビューアープロセスの子プロセスとなっている（Process Explorerなどで見るとわかる）。これは、画像ウィンドウを開くのを高速化するためだ。プロセスは簡単に自分自身を子プロセスとして起動できる。しかも、プログラムコード部分はすでにメモリにあり、これを共有するため、実行ファイルをメモリに読み込み実行環境を構築する必要がなく、起動時間が短くなる。

　また、フォトレガシー（UWP版フォト）では、Win32別プロセスとして動作していたモジュール側とプロセス間通信を使ってデータを交換していたが、Photos.exeでは、同一プロセス内での処理となるため、メモリ共有などで高速なデータ交換が可能になる。このあたりも、フォトアプリが高速動作できる原因だ。

　Windows 10から、標準搭載アプリのUWP化が進んだが、Windows 11からWinUI 3アプリ化に切り替わった。WinUI 3化により、フォトアプリは多くのメリットが得られた。フォトアプリはこうした方向性の“代表作”ともいえる。

　誰もが、「トロ」いアプリより「スカッ」と動くアプリを好むのは当たり前の話。Windows 10から、ここに至るまで、壮大な「遠回り」があり、ようやく「本道」に戻ってきた感じがある。もっとも、Microsoftとしては、まだ「マルチプラットフォーム」アプリ自体は諦めていないようだが……。