冗長性を回避できるために、Unityの内蔵アセットはどのようにパッケージ化すればいいのか
今回の話題：
冗長性を回避できるために、Unityの内蔵アセットはどのようにパッケージ化すればいいのか
SpriteAtlasの「冗長性」問題
Meshの使用メモリについて
UGUI.Rendering.UpdateBatches時間コストが高い
PluginsのDLLはどのようにPackageに影響するか
AssetBundle
Q：今はAssetBundleをパッケージ化しようと思いますが、Unityの内蔵アセットはAssetBundle名を指定できますか？ AssetBundleにある内蔵アセットの冗長性は一般的にどのように解決しますか？
既存のデータを確認した後、内蔵アセットのパッケージ化により、AssetBundleの冗長処理では、内蔵アセットをローカルに抽出またはダウンロードし、アセットの参照関係を変更してから、パッケージがAssetBundle名を指定できるようになりました。Unityは、スクリプトがAssetBundleをパッケージ化する際に内蔵アセットのBundle名を指定することをサポートしますか。これにより、複数のアセットが同じ内蔵アセットに依存することを防ぎ、冗長性をもたらしますか？
A：Scriptable Build Pipelineを使用して実現できます。具体的な方法については、Addressableで内蔵のShaderをパッケージ化する方法を参照してください。
public static IList<IBuildTask> AssetBundleBuiltInResourcesExtraction() { var buildTasks = new List<IBuildTask>(); // Setup buildTasks.Add(new SwitchToBuildPlatform()); buildTasks.Add(new RebuildSpriteAtlasCache()); // Player Scripts buildTasks.Add(new BuildPlayerScripts()); buildTasks.Add(new PostScriptsCallback()); // Dependency buildTasks.Add(new CalculateSceneDependencyData()); #if UNITY_2019_3_OR_NEWER buildTasks.Add(new CalculateCustomDependencyData()); #endif buildTasks.Add(new CalculateAssetDependencyData()); buildTasks.Add(new StripUnusedSpriteSources()); buildTasks.Add(new CreateBuiltInResourcesBundle("UnityBuiltInResources")); //将CreateBuiltInShadersBundle改成自己创建的类 buildTasks.Add(new PostDependencyCallback()); // Packing buildTasks.Add(new GenerateBundlePacking()); buildTasks.Add(new UpdateBundleObjectLayout()); buildTasks.Add(new GenerateBundleCommands()); buildTasks.Add(new GenerateSubAssetPathMaps()); buildTasks.Add(new GenerateBundleMaps()); buildTasks.Add(new PostPackingCallback()); // Writing buildTasks.Add(new WriteSerializedFiles()); buildTasks.Add(new ArchiveAndCompressBundles()); buildTasks.Add(new AppendBundleHash()); buildTasks.Add(new PostWritingCallback()); // Generate manifest files // TODO: IMPL manifest generation return buildTasks; }
[MenuItem("AssetBundles/GenerateAB")] public static void GenerateAB() { var outputPath = "Assets/AssetBundles"; if (!Directory.Exists(outputPath)) Directory.CreateDirectory(outputPath); BuildTarget targetPlatform = BuildTarget.StandaloneWindows; var group = BuildPipeline.GetBuildTargetGroup(targetPlatform); var parameters = new BundleBuildParameters(targetPlatform, group, outputPath); var buildInput = ContentBuildInterface.GenerateAssetBundleBuilds(); IBundleBuildContent content = new BundleBuildContent(buildInput); var taskList = AssetBundleBuiltInResourcesExtraction(); //创建自己的task ReturnCode exitCode = ContentPipeline.BuildAssetBundles(parameters, content, out result, taskList); if (exitCode < ReturnCode.Success) return; var manifest = ScriptableObject.CreateInstance<CompatibilityAssetBundleManifest>(); manifest.SetResults(result.BundleInfos); File.WriteAllText(parameters.GetOutputFilePathForIdentifier(Path.GetFileName(outputPath) + ".manifest"), manifest.ToString()); }下記のコードはCreateBuiltInResourcesBundle.csからのもので，从CreateBuiltInShadersBundle.csから一つのクラスをコピーして、少しのコードを変更します：
public ReturnCode Run() { HashSet<ObjectIdentifier> buildInObjects = new HashSet<ObjectIdentifier>(); foreach (AssetLoadInfo dependencyInfo in m_DependencyData.AssetInfo.Values) buildInObjects.UnionWith(dependencyInfo.referencedObjects.Where(x => x.guid == k_BuiltInGuid)); foreach (SceneDependencyInfo dependencyInfo in m_DependencyData.SceneInfo.Values) buildInObjects.UnionWith(dependencyInfo.referencedObjects.Where(x => x.guid == k_BuiltInGuid)); ObjectIdentifier[] usedSet = buildInObjects.ToArray(); Type[] usedTypes = ContentBuildInterface.GetTypeForObjects(usedSet); if (m_Layout == null) m_Layout = new BundleExplictObjectLayout(); //Type shader = typeof(Shader); //for (int i = 0; i < usedTypes.Length; i++) //{ // if (usedTypes[i] != shader) // continue; // m_Layout.ExplicitObjectLocation.Add(usedSet[i], ShaderBundleName); //} //上面是打包内置Shader的操作，改成全部资源就可以了 foreach (ObjectIdentifier identifier in usedSet) { m_Layout.ExplicitObjectLocation.Add(identifier, ShaderBundleName); } if (m_Layout.ExplicitObjectLocation.Count == 0) m_Layout = null; return ReturnCode.Success; }テスト結果は次のとおりです。
UnityのデフォルトのEffectをprefabにしてAssetBundleにパッケージ化します（Package名はpsです）。特殊効果に使用される内蔵アセットがすべてこのAssetBundleに含まれていることがわかります。
SBPでパッケージ化した後は、次のようになります。
psのAssetBundleにアセットがないことがわかります。生成された内蔵AssetBundleにはpsによって使用される3つの内蔵アセットがあり、psはUnityBuiltInResourcesのAssetBundleに依存します。
AssetBundle
Q：SpriteAtlasについて、UIがレンダリング時に関連するSprite情報に従って対応するSpriteAtlaを見つけるということだと思いました。各UIレンダリングが同じAtlasを使用するようになり、Draw Callを減らすことができます。したがって、理論的には、Atlasの一枚で十分です。しかし、なぜAtlasのパッケージ化したAssetBundleには、Atlasに加えて、参照されている元の画像もあるのか。UIのAssetBundleパッケージにも、参照されている元の画像があります。
なぜそのような「冗長性」があるのか、そしてImageがアトラスを参照するのか画像を参照するのか？またはその原理は何ですか？
元のイメージがAtlasパッケージに配置されている場合、元のイメージはAtlasPackageに含まれていますが、UIPackageには含まれていません。元のイメージがAssetBundlePackageの外部に配置されている場合、AtlasPackageとUIPackageの両方に元のイメージがあります。それは何の原理でしょうか？
A1：最初にこの記事を読むことをお勧めします：
【Unity游戏开发】SpriteAtlas与AssetBundle最佳食用方案
SpriteAtlasを適切に使用する場合、AssetBundleを解凍すると、Textureと複数のSpriteの2つのアセットが含まれていることがわかります。Texture
はテクスチャであり、表示されるファイルサイズは大きいです。Spriteはテクスチャ全体でのスプライトのオフセット位置情報を記述したデータファイルとして理解でき、表示されるファイルサイズは小さいです。
したがって、これは冗長ではなく、正常です。
A2：ただし、確かに冗長性の問題があります。Prefab1とPrefab2が同じAtlasの Spriteを参照している場合、Atlasは少なくとも1つのAssetBundleにアクティブに含まれている必要があります。そうでない場合、2つのPackageに受動的に入力され、冗長性が発生します。
AtlasはAssetBundlePackageを設定しません。
Atlasは、AssetBundlePackageの1つにパッケージ化します。
Mesh
Q：Meshのメモリ使用量に関して、Unity 2020のMeshにはどのような情報が表示されますか？
ボーンをインポートする
ここでボーンをインポートしないと、頂点情報が占めるスペースが2倍に減りますが、ボーンをインポートした後の頂点情報には何を増加しますか？
ボーンをインポートしない
2番目の問題は次のとおりです。ボーンをインポートする場合、メモリ内のMeshは0.6MBを占有します。これは、上記のInspectorに表示されるもののほぼ2倍であり、他のモデルのテストも2倍です。
Read/Write Enabledを有効にすることが問題だと考えていましたが、このオプションがどうであれ、メモリ使用量は変わらないことがわかりました。このメモリ使用量はどのように発生しますか。また、Read/Write Enabledを有効にすると、2倍のメモリコストが発生しますか？
テストの結果、ボーンをインポートせずに、Read/Write Enabledを有効にする場合は、有効にしない場合の2倍のメモリが必要となります。Read/Write Enabledを有効にしないと、Inspectorと同じメモリを占有することがわかりました。
ボーンをインポート時にRead/Write Enabledが有効になっているかどうかは、Inspectorインターフェイスの表示メモリの2倍です。ボーンがインポートされた後、モデルの頂点がデフォルトで変更されると推測されます。これは、デフォルトでRead/Write Enabledを有効にするのと同じです。
A：最初の質問：
InspectorパネルのVertices列は、Meshの頂点属性（またはチャネル）を指します。Meshにチャネルのデータが含まれている場合、各頂点に頂点属性があることを意味します。
Unityによって定義された頂点チャネルは14があります。
ボーンがインポートされる場合、追加の頂点属性は頂点のボーンウェイトとボーンインデックスです。
Mesh.boneWeights()およびMesh.GetBonesPerVertex()を介してアクセスできます。
ただし、BoneWeightプロパティは、4つのfloat32と4つのint32、合計8×4=32Bytesを格納します。一つのBones indexは一つのByteに相当します。
(8×4+1)Byte/Vert x 5512Vert = 177.63KB
2番目の質問：ボーンアニメーションをインポートして、CPU側でスキニング計算を実行します。つまり、CPUで頂点属性を取得します。
UGUI
Q：テストレポートでは、UGUI.Rendering.UpdateBatchesの使用量が多いと書かれています。それは何の原因でしょうか。
A1：シーンにあるTransformが変更されたUI要素が多すぎます。シーン内で変更されたCanvasが3つあり、これらの3つのCanvasの下Transformが変更された要素が312あるようです。
A2：CanvasのUI要素がCanvasRenderer.SyncTransformを何度も（数百回程度）トリガーすると、親ノードUGUI.Rendering.UpdateBatchesの時間も比較的高くなります。
テスト後、Unity 2018、2019、および2020のバージョンで、SetActive（true）を呼び出してUI要素をDeactive状態からActive状態に変更すると、UI要素が配置されているCanvas内のすべてのUI要素がCanvasRenderer.SyncTransformをトリガーします。 Unity 2017のバージョンでは、このような操作はこのSetActive（true）自体の要素にのみ影響します。UnityのBugなのか、このように設計されているのかはわかりません。ただし、Unity 2018、2019、および2020バージョンでは、Scaleを0または1に設定する方法を使用して、UIを非表示にできるため、Scanleが変更したUI要素のみがCanvasRenderer.SyncTransformをトリガーします。
Script
Q：下図に示すように、プロジェクトを開けるとすぐにTimeline異常が報告されます。後で、Pluginsの下のDLLに関連していることがわかります。DLLTimelineを削除すると、正常になります。では、DLLがTimeline
に影響を与えるのはなぜですか。Timelineのこれらのオーバーロードされた関数はUnityEditor.CoreModuleにあるはずだが、どうやって見つけられないでしょうか？
A：Unityスクリプトには厳密なコンパイル順序があります：
precompiled DLL -> asmdefs -> StandardAsset -> Plugins -> Plugins/Editor -> Assets -> Editor。
プリコンパイルされたDLLには、同じ名前が記述されたPlayableBehaviourクラスが含まれている可能性が高く、同じメソッドが実装されています。
このDLLは、Unityによって[Package]の[Timeline]の前にロードおよびコンパイルされます。Timelineをコンパイルすると、2つのPlayableBehaviourが検出されるため、書き換えに適した方法が見つかりません。
上記の考えに従って、エラーをローカルで再現しました。
このDLL（ConsoleApp1.dll）をPluginsディレクトリにスローすると、同じエラーが表示されます（DLLは元の質問と回答から取得できます）。
UWA公式サイト：https://jp.uwa4d.com
UWA公式ブログ：https://blog.jp.uwa4d.com
UWA公式Q＆Aコミュニティ(中国語注意)：https://answer.uwa4d.com
