はじめに
アプリの起動が速くなると話題の NativeAOT を試してみました。
設定項目は少ないのですが、うまくいかないと意外と悩みます。私も .csproj を手動で編集してようやく動作させることができました。
同じところでハマる人もいるかもしれないので、手順をまとめておきます。
1. .csproj を編集する
WinUI3プロジェクトの .csproj に以下の設定を追加します。
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<WindowsPackageType>None</WindowsPackageType>
<PublishAot>True</PublishAot>
</PropertyGroup>
...
設定項目の意味は以下のとおりです。
| 設定 | 説明 |
|---|---|
WindowsPackageType |
None を指定すると、EXE をダブルクリックして起動できる Unpackaged アプリになります。 |
PublishAot |
True を指定すると、発行時に NativeAOT が適用されます。 |
2. ビルド構成を選択する
ビルド構成は以下のように設定します。
3. 発行する
アプリのプロジェクトを右クリックし、発行 を選択します。
発行プロファイルとして win-x64.pubxml を選び、発行 をクリックします。
NativeAOT が有効になっている場合、発行時の出力に以下のメッセージが表示されます。
2>Generating native code
通常の発行とは異なり、ネイティブコードの生成処理が行われていることが確認できます。
4. 実行する
発行が完了すると、以下のフォルダーに NativeAOT 化された EXE が出力されます。
bin\Release\net8.0-windows10.0.19041.0\win-x64\publish
生成された EXE は、そのままダブルクリックで実行できます。
起動速度を比較してみる
通常の Release ビルドでは、次のフォルダーに EXE が出力されます。
bin\x64\Release\net8.0-windows10.0.19041.0\win-x64
一方、NativeAOT で発行した EXE は次のフォルダーに出力されます。
bin\Release\net8.0-windows10.0.19041.0\win-x64\publish
実際に同じアプリを起動して比較すると、違いは一目瞭然です。
| 通常の Release | NativeAOT |
|---|---|
 |
 |
どちらも同じアプリですが、NativeAOT 版はダブルクリック後すぐにウィンドウが表示されます。
体感でも分かるくらい起動が速くなるので、一度試してみる価値はあります。
「えっ？あまり変わらない？」と思うかもしれません。
ただし、この比較は何度もアプリを起動した後の状態です。
通常の .NET アプリも一度起動すると、JIT コンパイルなどの影響で起動が速くなっています。
初回起動では、NativeAOT 版との差はもう少し分かりやすくなります
今回のサンプルは小さいプロジェクトなので差は控えめですが、アプリの規模が大きくなるほど NativeAOT の効果は感じやすくなるのかなと思います。
ちなみに、GIF作成が不器用ですいません（笑）
比較する場合はページをリロードした直後の1回目の表示をご確認ください。
おわりに
NativeAOT は起動速度や配布のしやすさなど多くのメリットがありますが、まだすべてのライブラリと相性が良いわけではありません。
リフレクションを多用するライブラリなどでは対応が必要になる場合もあるため、後から NativeAOT 化しようとすると、思った以上に修正が必要になることがあります。
そのため、最終的に NativeAOT で公開する予定があるのであれば、プロジェクトの初期段階から NativeAOT を有効にして開発を進めるのが良いかもしれません。
途中で問題が見つかっても早い段階で対応できるので、後からまとめて修正するよりも楽になるケースが多いと思います。