Lassen Sie uns über Android-Overlays sprechen.
Overlays oder RRO sind eine der wichtigsten Techniken zur Anpassung von Android.
Was genau ist also ein Overlay oder ein Rro?
Einfach ausgedrückt ist ein Runtime Resource Overlay oder RRO ein Paket, das die Ressourcenwerte eines Zielpakets
ändert.
Stellen Sie sich also vor, dass es sich um ein AP-Spiel handelt, dem nur eine Ressource gegenübersteht.
Was kann also mit Hilfe der RRO-Technik überlagert werden?
So kann RRO technisch alle Ressourcendateien wie Beschriftungen, Zeichenketten, Farben und andere ähnliche Quelldateien überlagern.
Es kann auch Treiber und Schriftarten überlagern.
Auf diese Weise können Sie das Erscheinungsbild einer Anwendung oder einer System-UI-Komponente dynamisch ändern.
In diesem einfachen Beispiel können Sie also sehen, dass ein blauer Androide durch die Verwendung der Ressourcen-Overlays in einen grünen Androiden
verwandelt wird.
Dabei kann es sich entweder um Laufzeit- oder statische Overlays handeln.
Was nicht durch Pfeile überlagert werden kann.
Sie können also keine Quelle überlagern.
Das bedeutet, dass die Java- oder Kotlin-Quellcodedateien überlagert werden würden.
Wenn Sie beispielsweise die Anwendungsstruktur betrachten, können Sie alles überlagern,
was sich im Ressourcenordner und im SABC-Ordner befindet, d. h. die Java- und Kotlin-Cluster, die nicht übersehen werden
können.
Schauen wir uns also den Prozess der Überlagerung der Ehrenliste genauer an.
Dieses Diagramm zeigt also einen Überblick darüber, wie eine Anwendung kompiliert und ausgeführt wird, und wird von einem
Pfeil überlagert.
Der obere Abschnitt zeigt also, wie eine normale Android-Anwendung in eine Android-App umgewandelt und ausgeführt wird.
Und der untere Teil zeigt, wie ein RRO-Projekt in einen Pfeil umgewandelt wird und in den App-Prozess
eingefügt wird.
Im Falle einer normalen Android-Anwendung haben wir also hauptsächlich diese Dateien, richtig?
Das Android-Manifest ist also eine der Codedateien, in denen wir eine Menge Dinge für die Anwendung konfigurieren.
Und dann haben wir die Java- und Kotlin-Dateien, in denen wir die Geschäftslogik und andere Logiken hervorheben, richtig?
Und auch wir haben die Ressourcen-Ordner, wo wir alle UI-Elemente wie das Layout und andere Bilder oder Zeichnung Fähigkeit,
Produkt oder die Ressource-Ordner ist die eine, die wir tatsächlich Overlay sind zu verwenden.
Richtig.
Wenn dieses Projekt also gebaut wird, wird es zu einem Epos.
Und wenn Sie einen beliebigen Anfang öffnen, können Sie sehen, dass sich darin das Android-Manifest oder etwas Ähnliches befindet.
Und dann haben wir die nächste Node-Textdatei, die im Grunde die kompilierte Form von Java- und Kotlin-Dateien
ist.
Und dann haben wir noch den Ressourcenhinweis und eine C-Datei, die im Grunde eine kompilierte Form der Ressourcendateien
ist.
Während der Ausführung wird der App-Prozess also die Klassen für Dex und Applesauce verwenden und
mit einem C beginnen, um die Anwendung auszuführen.
So läuft also eine normale Android-Anwendung.
Wenn also ein RRO im Geltungsbereich ist, dann haben wir RRO-Ressourcen in einer C- und RRO-ID-Map innerhalb des Prozesses gespeichert.
Ja.
Die in einem C gespeicherten rro-Ressourcen sind also nichts anderes als die Overlay-Ressourcen, die in der
rro api und dem rro I verfügbar sind. T. map ist nichts anderes als eine Vorlage, die alle Etikettenressourcen eins
zu eins abbildet.
Ja.
Werfen wir nun einen Blick auf den Abschnitt RRO.
Ein normales RRO-Projekt besteht also nur aus einem android manifest cortex symbol und den Ressourcendateien.
So auf Kompilierung oder eigenen Build-Prozess, wird dies in eine RRO-API-Spiel umgewandelt werden und in der RRO-AP-Spiel,
das Android manifest Cortex-Symbol und die Ressourcen dot RC, so dass die Ressourcen nicht RC C-Datei ist nichts
anderes als die kompilierte Form der Ressourcen-Datei.
Während des Ausführungsprozesses nimmt der App-Prozess diese Angaben auf und sie werden auch in einem C gespeichert.
Und wenn wir uns die RRO-ID-Map ansehen, um die entsprechende Ressource IPD für die Überlagerung mit der Quelle zu erhalten und
das Laufzeitwerkzeug zu bauen, überlagern wir im Grunde die App-Ressourcen Punkt ADC mit dem RRO-Ressourcenhinweis
RC.
Beachten Sie also bitte, dass nur die jeweilige Ressource überlagert wird.
Wenn Sie also zum Beispiel nur ein Layout-Beispiel überlagern, dann wird nur dieses spezielle Beispiel
alle anderen Ressourcen werden von der Apfelquelle verwendet und in einem C gespeichert.
Also kurz gesagt, während der Laufzeit wird der Prozess an der rro id Karte schauen und bekommen das Recht alle ein Etikett für die
Gesellschaft und Overlay, dass die Ressource auf der Oberseite der app, den Quellcode bei einem C.
So funktioniert also ein RRO-Overlay-Verfahren auf einer sehr hohen Ebene.
Betrachten wir eine reale Anwendung von statischem und dynamischem rro.
Nehmen wir ein Beispiel von Handyherstellern wie Samsung, Motorola oder Nokia, so könnten sie ein statisches Overlay verwenden
oder verschiedene Marken von Handys erstellen.
In diesem Fall können Sie also sehen, dass Marke X und Grand Y aus einem einzigen aosp-Systembild erstellt wurden.
Auf ähnliche Weise könnten sie dynamische Pfeile verwenden, um verschiedene Skins für ein System zu erstellen.
Ja.
Wie Sie hier oben auf den Marken X und Y sehen können, können sie dynamische Pfeile verwenden und eine blaue und eine
helle Haut erstellen.
Hier liegt also der Unterschied zwischen statischen und dynamischen Pfeilen.
Die statischen Pfeile werden zum Zeitpunkt der Erstellung angewendet und können später nicht deaktiviert werden, während die
dynamischen Pfeile zur Laufzeit aktiviert werden und zu einem späteren Zeitpunkt programmatisch aktiviert oder deaktiviert werden können.