バグを説明する
UWPアプリの起動時間は、プロジェクトに含まれるアセットの数に比例します(たとえば、ビルドアクションが_Content_に設定されたイメージ)。 何もしない単純な空白のページであっても、アプリケーションパッケージに多くのアセットが存在するだけで、アプリの読み込みが非常に遅くなりますが、コードはそれらにまったく触れていません。
バグを再現する手順
動作を再現する手順:
Assets
フォルダーに1000個の小さな画像を追加します(アイコンでも十分です)利便性を高めるために、ここGitHubで簡単な再現を作成しました。 2つのアプリが含まれています。1つはアセットのない単純な空白のUWPアプリで、もう1つは多くの画像コンテンツアセットを含む空白のUWPアプリです(ただし、まったく使用されていません)。
予想される行動
アプリがコンテンツファイルをまったく使用しない場合、アプリの起動時間に影響を与えることはありません(ファイルはパッケージとともに既にデプロイされているため、アプリは起動時にそれらを操作しないでください)。
スクリーンショット
_プロファイラー出力_
プロファイラーには、ウィンドウのサイズ変更に費やされたすべての起動時間が表示されることに注意してください。
デバッグ中、この待機時間中にCPUまたはRAMのアクティビティがほとんどないことがわかります。
バージョン情報
NuGetパッケージバージョン:不要、従来のUWPで十分
| Windows10バージョン| 問題を見ましたか? |
| :--------------------------------- | :-------------------- |
| インサイダービルド(xxxxx)| はい|
| 2019年11月の更新(18363)| はい|
| 2019年5月の更新(18362)| はい|
| 2018年10月の更新(17763)| はい|
| 2018年4月の更新(17134)| |
| 秋のクリエイターアップデート(16299)| |
| クリエイターアップデート(15063)| |
| デバイスフォームファクター| 問題を見ましたか? |
| :-------------------- | :------------------- |
| デスクトップ| はい|
| モバイル| はい|
| Xbox | |
| Surface Hub | |
| IoT | |
追加のコンテキスト
コンテンツアイコン画像がたくさんある私のアプリでこれにずっと前に気づきました、しかし今私はついにそれがこれほど遅く起動する根本的な原因が何であるかを発見しました。
@ Austin-Lamb @ bartekk8再現は、プラットフォームビットのみを使用します(winUIは使用しません)。
@ranjeshj確かに、 Microsoft.UI
を追加してもかまいません。 残念ながら、UWPの問題(開発者に見られる)を報告するのにこれ以上の場所はありません。そのため、ここに問題を投稿しました。 Windowsフィードバックにも再投稿しますが、そこから開発者チームに届くかどうかはわかりません。
@MartinZikmundあなたは正しいレポを持っています:)。 WinUI3では、プラットフォームビットがOSから移動されています。 したがって、ここでこの問題を追跡できます。 報告していただきありがとうございます。
最も参考になるコメント
@MartinZikmundあなたは正しいレポを持っています:)。 WinUI3では、プラットフォームビットがOSから移動されています。 したがって、ここでこの問題を追跡できます。 報告していただきありがとうございます。