PS: In diesem Artikel wird erläutert, wie Abhängigkeiten aus zwei Aspekten erhalten werden: „vor dem Verpacken“ und „nach dem Verpacken“.
Die Funktion zum Abrufen von AB-Paketabhängigkeiten
Wie wir alle wissen, gibt es eine zusätzliche Sicherung der Ressource R in C, wenn die Ressourcen in einem AB-Paket (wir nennen es C) auf andere Ressourcen (wir nennen es R) verweisen, die nicht in AB-Paketen verpackt sind ist einfach Es ist in Ordnung, wenn es eine zusätzliche Sicherung von R in einem C gibt, aber wenn es viele andere AB-Pakete Cx gibt, die eine Sicherung von R haben, dann ist dies Ressourcenredundanz und ist unnötig. Dies veranlasst uns auch, R in AB zu packen .-Paket (wir nennen es D), dann haben diese Cx nur noch eine Abhängigkeit vom D-Paket und verfügen nicht über so viele zusätzliche Ressourcen.
Wenn das AB-Paket geladen und wiederhergestellt wird und es von anderen AB-Paketen abhängt, müssen wir zuerst diese abhängigen AB-Pakete laden, um sicherzustellen, dass die AB-Paketressourcen normal angezeigt werden, ganz zu schweigen davon, dass diese abhängigen Pakete möglicherweise auch davon abhängen on Bei anderen Paketen handelt es sich hierbei um ein rekursives Traversierungsproblem.
Das Laden abhängiger Paketressourcen beansprucht Speicher. Wenn die Verpackung unangemessen ist, werden viele nutzlose Ressourcen gleichzeitig geladen und Speicher verbraucht. Dies ist ein Tabu in der Spieleentwicklung, daher ist es wichtig, die Abhängigkeiten der Verpackung zu klären.
Ermitteln der AB-Paketabhängigkeiten vor dem Packen
Normalerweise verwendet die alte Methode das AssetBundle-System (die neueste empfiehlt die Verwendung des Addressable-Systems) für Verpackungsvorgänge. Es gibt zwei Methoden:
- Legen Sie den AB-Paketnamen und das Suffix manuell fest: Dies ist die gebräuchlichste Methode. Die Abhängigkeitserfassung in diesem Artikel basiert ebenfalls auf dieser Methode. Diese Methode belässt den AB-Paketnamen, zu dem die Ressource gehört, in der .meta-Datei der Ressource . Dies ist auch die Grundlage für die Abhängigkeitsabfrage.
- Dynamisch durch AssetBundleBuild-Code festgelegt: Diese Methode wird in Projekten mit einer großen Menge an Ressourcen angezeigt. Der Vorteil ist definitiv, dass sie Ärger erspart. Schließlich müssen Sie nicht den AB-Pfad jeder Ressource einzeln festlegen, sondern dies Dies bedeutet auch, dass wir entweder die Konfigurationsdateien finden oder den Code selbst verfolgen müssen. Außerdem geht es darum, zu beurteilen, ob das Projekt diese Methode verwendet. Daher ist diese Situation komplizierter. Machen wir uns also vorerst keine Sorgen.
Wenn es sich um die AB-Paketstrategie von Methode 1 handelt, müssen wir nur das von Unity bereitgestellte AssetDatabase-Objekt verwenden, um dies zu erreichen. Die spezifischen Vorgänge lauten wie folgt:
var allAssetBundleNamesInProject = AssetDatabase.GetAllAssetBundleNames();
var unusedAssetBundleNamesInProject = AssetDatabase.GetUnusedAssetBundleNames();
var abAllDependencies = AssetDatabase.GetAssetBundleDependencies(assetBundleName, true);
var abDirectDependencies = AssetDatabase.GetAssetBundleDependencies(assetBundleName, false);
Sie sollten in der Lage sein, die Bedeutung zu verstehen, indem Sie sich die Variablennamen ansehen. Mit diesen Schnittstellen können Sie den AB-Paketnamen, direkte AB-Paketabhängigkeiten und alle AB-Paketabhängigkeiten abrufen.
PS: Für Unity bezieht sich die direkte Abhängigkeit hier auf den AB-Namen der Ressource, von der die AB-Ressource abhängt. Das heißt, wenn eine AB-Ressource A von einer Nicht-AB-Ressource B abhängt, B jedoch von AB-Ressource C abhängt , liegt es auf der Hand, dass A als direkt von C abhängig angesehen werden sollte, Unity jedoch davon ausgeht, dass zwischen A und C keine direkte Abhängigkeit besteht, sodass es eine Situation geben wird, in der ein AB-Paket nur alle abhängigen Ressourcen, aber keine direkt abhängigen Ressourcen hat .
Lassen Sie mich hier erklären, dass sich alle Abhängigkeiten auf das Paket Dx beziehen, von dem Paket AB und Paket C direkt abhängt, und dass es möglicherweise auch Paket Ex gibt, das davon abhängt. Diese Abhängigkeiten umfassen alle Pakete, von denen Dx direkt abhängt, und das darüber liegende Ex .
Wenn wir Abhängigkeiten analysieren, müssen wir auch die Abhängigkeiten des verwendeten AB-Pakets analysieren. Daher müssen wir einen oben festgelegten Unterschied erfragen, um den Namen des verwendeten AB-Pakets zu erhalten.
var usedAssetBundleNamesInProject = allAssetBundleNamesInProject.Except(unusedAssetBundleNamesInProject).ToArray();
PS: Mit diesen Abhängigkeiten können Sie tatsächlich viele Dinge tun, z. B. einen gerichteten azyklischen Graphen der AB-Paketbeziehungen erstellen, diesen Graphen dann in verbundene Untergraphen unterteilen und aufteilen, welche AB-Pakete innerhalb einer Gruppe voneinander abhängig sind. usw. Ich werde diesen Teil der Anwendung je nach Situation später teilen.
Abrufen der AB-Paketabhängigkeiten nach dem Packen
Dies ist relativ einfach. Unabhängig davon, welche Methode Sie zum Packen von AB verwenden, muss nach dem Packen von AB eine allgemeine Datei vorhanden sein, in der die AB-Paketinformationen aufgezeichnet werden (der Dateiname hängt vom Pfadordnernamen Ihrer Verpackung ab), dann nur wir Sie müssen die .manifest-Datei dieser Datei laden, um dieselben Informationen wie vor dem Packen zu erhalten.
var assetBundle = AssetBundle.LoadFromFile(path);
var manifest = assetBundle.LoadAsset<AssetBundleManifest>("AssetBundleManifest");
var abNames = manifest.GetAllAssetBundles();
var abDirectDependencies = manifest.GetDirectDependencies(abName)
var abAllDependencies = manifest.GetAllDependencies(abName)
PS: Denken Sie daran, die geladene AB-Ressource zu entladen, sonst erhalten Sie eine Fehlermeldung, wenn Sie versuchen, sie erneut zu laden.