Resourcesディレクトリのメリットと問題点
Unityのプロジェクトには、先週(Assetsについて――Unityアセットマッピング)に言及したルート・ディレクトリの以外、UnityのAssetsディレクトリの下に、特別な働きがある固定的なフォルダーがある。でも、これらのフォルダーは、新規作成したプロジェクトのディレクトリに、デフォルトで作成されなかったです。Unity 2018.3.8で空のプロジェクトを作成して、Assetsに入って確認しましょう。
一、特別なプロジェクトディレクトリ
まず、Unityのデフォルトの空のプロジェクトのディレクトリを見てください。以下に示すように：
1、新しいプロジェクトのデフォルトディレクトリ
古いバージョンでは、Unityが空のプロジェクトを作成した後、空のAssets
以外何もありません。今は、AssetsにデフォルトでScenesディレクトリがあり、中にはSampleSceneのデフォルトの空白のシーンがあります。Assetsのレベルでは、Packagesディレクトリがあります。これは2018年にPackagesManagerと一緒に現れ、現在のプロジェクトによって導入されたPackagesを表示します。ただし、このディレクトリは読み取り専用であり、操作できないことに注意してください。すべての変更は、PackagesManagerウィンドウを介して行われます。もちろん、ディスクの対応するディレクトリに手動でJsonファイルを変更することもできます。それも効果は得られますが、あまり推奨しません。
2.Unityの特別ディレクトリ
新しいプロジェクトにはデフォルトでScenesディレクトリが与えられていますが、このディレクトリには特別な意味はありません。シーンを任意のカスタムディレクトリに保存できます。
（1）Editor
最初に紹介するのはこのディレクトリです。このディレクトリは開発を支援するために使用され、1つまたは複数にすることができ、任意のサブディレクトリの下に置くことができます。主な機能は、Unityエディターモードで提供されるスクリプトとインターフェイスをコンパイルして、研究開発を支援し、さまざまなアセットチェックを作成し、ツールを生成し、Unityのツールバーやウィンドウバーなどをカスタマイズすることです。 Editorディレクトリ内のすべてのスクリプトが公式リリースパッケージにコンパイルされるわけではありません。多くの優れたプラグインは、Unityが提供するエディターの拡張インターフェイスを介して、機能拡張を実現するのです。
（2）Editor Default Resources
これは、Editorと組み合わせて使用する必要があります。むき出しの拡張パネルやツールは見栄えがよくありません。美化されたアセットを追加すると、プラグインやツールがさらに高級に見えます。このディレクトリは唯一的であり、アセットのルートディレクトリにのみ配置できることに注意してください。
（3）Plugins
このディレクトリは、コード以外のライブラリファイルを保存するためのものです。たとえば、導入されたサードパーティコード、SDKによってアクセスされるさまざまなjarパッケージ、.aファイル、.soファイル、framworkファイルなど、これらのライブラリファイルは、Unityのコンパイル時にDLLにリンクされます。
（4）Resources
これはEditorと同じで、Assetsの下の任意のディレクトリに配置でき、任意の数のコピーを配置できます。Resourcesディレクトリ内のすべてのファイルは、特別なBundlesに直接パッケージして、ゲームを起動すると、シリアル化されたマッピングテーブルが生成され、メモリにロードされます。
（5）Gizmos
このディレクトリは比較的に簡単です。つまり、UnityのSceneウィンドウにいくつかの補助的なマーキング、アイコン、またはその他の記号を表示し、ポジショニングリアセットの開発を支援するのに用いられます。例えば：
ボタンはSceneウィンドウの右上隅にあります。Sceneウィンドウであるため、Gameウィンドウおよびリリース後は表示されないことに注意してください。
（6）StreamingAssets
このファイルはUnityの重要なファイルです。Unityがプログラムまたはゲームをリリースし、アセットがパッケージ化される場所は2つだけです。1つはResourcesディレクトリで、もう1つはStreamingAssetsです。このディレクトリ内のアセット、ファイル、またはその他のものは、そのまま最終的なApkまたはiOSパッケージにコピーされます。
上記の特別なディレクトリ以外、通常のプロジェクトには、他に多くの導入されたプラグインまたはカスタムディレクトリがあります。以前に書いた記事を参考してください。それは、複数の人やさまざまな機能のコラボレーションに適応するように、Unityプロジェクトディレクトリを計画するために使用されました。
リンク：https://zhuanlan.zhihu.com/p/77058380（中国語注意）
二、Resourcesの詳説
Resourcesが広く使われる理由は、使い方がとても簡単で、同期して読み込まれるからだと思います。一般的に、正式な商用プロジェクトでは、AssetBundleを使用してアセットを外部にリリースします。 AssetBundlesアプローチには、次のような多くの欠点があります。
（1）パッケージ内のアセットの状況を視覚的に確認することはできません。
（2）非同期ロードには、Hierarchy面倒なコールバック処理が必要です。
（3）デバッグ時には、Hierarchyからアセットを直接特定することはできません。
（4）使用する前に、時間をかけてパッケージ化する必要があります。特に開発中は、パッケージ化することを忘れると、アセットを頻繁に調整するとBugが発生する可能性があります。
前に述べたように、UnityはResourcesとAssetBundlesの2つの方法でアセットを処理します。したがって、AssetBundleの開発期間は使いにくいため、ほとんどの場合、Resourcesを使います。
では、Resourcesを使用したら問題なくなるのでしょうか？
1、Resourcesのディレクトリのベストプラクティス
欠点について話す前に、Unity公式がResources使用へのベストプラクティスを見てみましょう。
使いないでください！！
驚かないでください、これは公式の態度です。いくつかの理由で、Unityはアセットを使いすぎることを望んでいません。理由は次のとおりです。
Resourcesのアセットは、アプリケーションの起動時間とビルド時間を増加させます。
Resourcesのアセットは、量増えて更新することはできません。これは、モバイルゲーム開発の致命的なポイントです。
したがって、公式はAssetBundlesを使用することをお勧めします。
実際、あまり気にする必要はありません。何年にもわたる開発の結果、ソリューションはすでに蓄積されています。少し後で触れますが、最大の解決策は、シリーズのテーマであるAddressable Asset Systemです。まず、このソリューションがない時どのような解決策があるかについて検討します。
2、どのような状況でResourcesを使用できますか
Resourcesには致命的な欠点がありますが、存在は合理的です。また、次のようないくつかの使用場面があります。
（1）一部のアセットは、プロジェクトのライフサイクル全体に使用するもの
（2）重要ですが、メモリをあまり使用しないもの
（3）変更の必要はあまりなく、プラットフォームを差別化する必要も特にないもの。
（4）システム起動時の最小限の起動に使用されたもの
もう1つの場面は、上司にいくつかの効果をすばやく表示する必要がある場合、Demoをすばやく完了したい場合、またはチュートリアルや記事を作成し、ソリューションのプレゼンテーションを共有したい場合に、Resourcesを使用すると時間を節約できます。ただし、確立されたプロジェクトを正式な本番環境で使用することにした場合は、必ずAssetBundlesで書き直してください。
3、Resourcesのシリアル化
前述のように、プロジェクトをビルドすると、Resourcesディレクトリ内のすべてのファイルがシリアル化されたファイルにマージされます。ファイルには、独自のmetadata情報とインデックス情報が含まれます。内部的には、赤黒木でアセット検索を実現し、対応するFile GUIDとLocal IDのインデックスに使用され、シリアル化されたファイルにオフセットを記録することにも使用されます。
公式の実際のテストデータによると、10,000個のAssetsを含むResourcesディレクトリは、ローエンドのモバイルデバイスで初期化するのに5〜10秒以上かかる場合があります。しかし実際には、開始時にこれらのAssetsはすべて使用されているわけではありません。
4.開発中の代替案
ResourcesとAssetBundlesの不便さについては前に説明しましたが、アセットの欠点なしに開発中にすばやくロードできるソリューションはありますか？それはAssetDatabaseです。
これはエディターモードのUnityアセットロードクラスであり、従来のCreate、Delete、Save、Loadなどの一般的なインターフェイスを提供し、同期的にロードされます。したがって、アセット管理クラスを自分で作成し、マクロを使用してEditorモードを区別し、EditorでAssetDatabaseを使用してアセットを直接ロードし、非同期コールバックをシミュレートしてAssetBundlesのロードプロセスに似たものにします。非Editorモードで、通常のAssetBundleのロードをコールします。
このアセットマネージャーは、作成するのが非常に面倒ですが、プロセスが正しくデバッグされると、後で処理する必要はありません。 AssetDatabaseについては、説明しません。より詳細なドキュメントを見つけました。https://www.jianshu.com/p/2cae2f082f66を参照してください。
AssetDatabaseソリューション以外、Addressable Asset Systemもあります。これは2018年以降に正式に導入されました。これは、今まで言ったことをカプセル化して組み合わせ、開発中のアセット管理のいくつかの問題点を解決します。しかし、これについて話す前に、次の記事はAssetBundlesのシステム知識を説明する予定です。
UWA公式サイト：https://jp.uwa4d.com
UWA公式ブログ：https://blog.jp.uwa4d.com
UWA公式Q＆Aコミュニティ(中国語注意)：https://answer.uwa4d.com
