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でファイルのスキャンなどをさせていた。
![フォトアプリ](/img/2024/08/24/3785160/l/a0d6f5940fb22124.png)
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」というオプションが付いている。
![フォトアプリ](/img/2024/08/24/3785161/l/9641522238ac3392.png)
現在のフォトアプリ(Photos.exe)は起動すると、自分自身をもう1つビューアーウィンドウ用に起動する。画像は、ビューアーウィンドウ用プロセスの子プロセスが表示する。すでにプログラムはメモリ中に読み込まれているため、高速に画像を表示することが可能
2つ目以降のPhotos.exeのビューアープロセスは、最初のビューアープロセスの子プロセスとなっている(Process Explorerなどで見るとわかる)。これは、画像ウィンドウを開くのを高速化するためだ。プロセスは簡単に自分自身を子プロセスとして起動できる。しかも、プログラムコード部分はすでにメモリにあり、これを共有するため、実行ファイルをメモリに読み込み実行環境を構築する必要がなく、起動時間が短くなる。
また、フォトレガシー(UWP版フォト)では、Win32別プロセスとして動作していたモジュール側とプロセス間通信を使ってデータを交換していたが、Photos.exeでは、同一プロセス内での処理となるため、メモリ共有などで高速なデータ交換が可能になる。このあたりも、フォトアプリが高速動作できる原因だ。
Windows 10から、標準搭載アプリのUWP化が進んだが、Windows 11からWinUI 3アプリ化に切り替わった。WinUI 3化により、フォトアプリは多くのメリットが得られた。フォトアプリはこうした方向性の“代表作”ともいえる。
誰もが、「トロ」いアプリより「スカッ」と動くアプリを好むのは当たり前の話。Windows 10から、ここに至るまで、壮大な「遠回り」があり、ようやく「本道」に戻ってきた感じがある。もっとも、Microsoftとしては、まだ「マルチプラットフォーム」アプリ自体は諦めていないようだが……。
![](/img/blank.gif)
この連載の記事
-
第445回
PC
次期Windows 11ではAndroidのファイルをエクスプローラーからアクセス可能になる -
第444回
PC
外部ファイルをExcelに読み込む際の作業を効率化するPower Queryの活用 -
第443回
PC
Windows Terminalで採用されたCascadia Codeフォントを使うとプログラムを書くとき断然見やすい -
第442回
PC
Copilot+ PCで実現されるローカル推論で「対クラウド企業」を指向するMicrosoft -
第441回
PC
WSL以前から40年以上続く、Windows(Microsoft)とUNIXとの関わり -
第440回
PC
そもそも「Copilot+ PC」とは何なのか? -
第439回
PC
今更more.comを使うのか!? Windowsでのページングを考える -
第438回
PC
Windowsはなぜ再起動が必要になるのか? -
第437回
PC
Windowsが今更(?)開発者に優しくなろうとしている!? 「Dev Home」は開発者にとって使い物になる? -
第436回
PC
Copilot+PCとともにWindowsのデバイス間連携に大きな変化!? Project ROMEの逆襲? - この連載の一覧へ