Ich habe die folgenden Aussagen hier
gelesen By default, all components of the same application run in the same process and most applications should not change this. However, if one needs to control which process a certain component belongs to, he can do so in the manifest file. The manifest entry for each type of component element—<activity>, <service>, <receiver>, and <provider>—supports an android:process attribute that can specify a process in which that component should run. One can set this attribute so that each component runs in its own process or so that some components share a process while others do not.
Ich möchte wissen, in welchen Szenarien ein Entwickler das gerne machen würde und verschiedene Komponenten in verschiedenen Prozessen laufen lassen würde und welchen Vorteil bringt das?
Eine weitere Aussage, die ich gelesen habe, ist
The <application> element in the manifest file also supports an android:process attribute, to set a default value that applies to all components
In Bezug auf die obige Aussage möchte ich wissen Warum sollte ein Entwickler das tun, es ist bereits ein Prozess mit einer Anwendung standardmäßig verbunden und alle Komponenten laufen innerhalb dieses Prozesses.
Kann jemand diese Dinge für mich klären, da ich nirgendwo sonst irgendwelche Details dazu bekomme
Danke
Nehmen wir das Beispiel von Google Chrome browser , das das Attribut android:process am besten verwendet hat. Vorher sollten wir verstehen, warum Multi-Prozess-Architektur in Betracht gezogen wurde.
Denken Sie an die alten Zeiten, als wir kooperatives Multitasking-Betriebssystem benutzten. Es gab einen einzigen Prozess und Anwendungen, die nacheinander in diesem einzelnen Prozess ausgeführt wurden. Das Problem mit dieser Architektur war, dass, wenn eine Anwendung sich schlecht benimmt, dieser einzelne Prozess abstirbt, indem das gesamte System heruntergefahren wird.
Heute ein modernes Betriebssystem, führen Sie Anwendungen in ihren eigenen Prozessen aus. Wenn sich eine Anwendung nicht richtig verhält, stirbt der Prozess, der sie hostet, ab und beeinträchtigt den Rest des Systems nicht.
Gleiches gilt für den Browser. Wenn eine Webseite sich nicht gut benimmt, bringt sie den gesamten Browser herunter, indem Webseiten, die auf anderen Registerkarten geöffnet sind, nicht verfügbar sind. Daher wurde Multi-Prozess-Architektur gebaut.
Separate Prozesse werden für Browser-Registerkarten verwendet, um die Browser-Anwendung vor Fehlern in der Rendering-Engine zu schützen. Jeder Renderprozess wird als Android-Dienst in einem separaten Prozess ausgeführt. Dies geschieht mithilfe des android:process -Tags von <service> element. Ein weiteres wichtiges Flag, das zum Rendern des Engine-Prozesses verwendet wird, ist android: isolateProcess . Dieses Flag stellt sicher, dass der Renderprozess keinen Zugriff auf die Systemressourcen wie Netzwerk, Anzeige und Dateisystem hat, indem er die Browser-Anwendung hochsicher macht.
Hier ist das Snippet der Manifest-Datei von chrome:
%Vor%Hier ist die Ausgabe der adb shell:
%Vor%Das Element in der Manifestdatei unterstützt auch ein android: Prozessattribut, um einen Standardwert festzulegen, der für alle gilt Komponenten
Standardmäßig ist der Name des Anwendungsprozesses der in <manifest> tag angegebene Paketname. Dies kann durch Angabe des Namens im android:process -Attribut des <application> -Tags außer Kraft gesetzt werden. Ein Anwendungsfall: Wenn mehrere Anwendungen im selben Prozess ausgeführt werden sollen, vorausgesetzt, dass diese Anwendungen von demselben Zertifikat signiert sind und die Benutzer-ID teilen.
Wenn der Name von <android:process> mit : beginnt, wird er für diese Anwendung privat, wie im Fall der Render-Engine von Chrome ( com.android.chrome:sandboxed_process5 ). Es impliziert Anwendungen, außer com.android.chrome kann nicht mit dieser Rendering-Engine kommunizieren.
Wenn der Name von <android:process> mit einem Kleinbuchstaben beginnt, wird er zum globalen Prozess. Von Dokumenten :
Dies ermöglicht Komponenten in verschiedenen Anwendungen, einen Prozess zu teilen, Ressourcenverbrauch reduzieren.
Zusammenfassung der Vorteile:
Grundsätzlich sollten Sie in der Lage sein, die Bedenken zu trennen und zu entscheiden, ob es sinnvoll ist, eine Multi-Prozess-Architektur anzuwenden.
Update 1 : @Budius-Kommentar hinzufügen
Jeder Prozess hat nur eine bestimmte Menge an verfügbarem Speicher. In der App, an der ich arbeite, machen wir eine rechenintensive Verarbeitung in großen Speicherfeldern. Diese Berechnungen werden immer in einem separaten Prozess ausgeführt, um sicherzustellen, dass genügend Speicher für das gesamte Ereignis zur Verfügung steht und nicht mit OutOfMemory abstürzt.
Der Grund dafür ist möglicherweise, dass Android Ihren Anwendungsprozess herunterfahren kann, um jederzeit Speicherplatz im System freizugeben, und Sie möchten die Situation möglicherweise mildern.
Angenommen, Sie haben ein sehr, sehr wichtiges Stück Code, das eine lange Zeit benötigt, um fertig zu werden, wäre es sehr schlecht, es mitten in der Arbeit zu töten (zum Beispiel eine finanzielle Transaktion in einer Banksoftware). Wenn Sie dieses Codeelement in einem Service einfügen, das in einem separaten Prozess vom restlichen Anwendungscode ausgeführt wird, wird Android% Service nicht beenden, das möglicherweise noch ausgeführt wird, nachdem der Benutzer beendet wurde Ihre Bewerbung.
Aus der Dokumentation:
Wenn Sie entscheiden, welche Prozesse zu töten sind, wiegt das Android-System relative Bedeutung für den Benutzer. Zum Beispiel schließt es sich schneller einen Prozess, der Aktivitäten hostet, die nicht mehr sichtbar sind Bildschirm, im Vergleich zu einem Prozess mit sichtbaren Aktivitäten. Die Entscheidung Ob ein Prozess beendet werden soll, hängt also vom Status des Prozesses ab Komponenten, die in diesem Prozess ausgeführt werden.
Sie können mehr hier
lesen Im Allgemeinen wird ein Service verwendet, wenn Sie erwarten, dass eine Nicht-UI-Aufgabe relativ lange dauert. Ein Activity , das nicht im Vordergrund bleibt, kann mit hoher Wahrscheinlichkeit vom Betriebssystem beendet werden, während ein Service unbegrenzt weiterlaufen kann.
A Service wird in einem separaten Prozess erstellt, wenn Sie nicht möchten, dass der Garbage Collector seine Arbeit beeinträchtigt. Der Garbage Collector wirkt sich in diesem Fall nur auf den Anwendungsprozess aus. Darüber hinaus hat ein Service in einem separaten Prozess den zusätzlichen Vorteil, dass es etwas weniger Speicher verbraucht als im Hauptanwendungs-Prozess.
Das Service , das Sie in einem separaten Prozess deklarieren, kann entweder privat für die Anwendung sein:
oder es kann global sein:
%Vor% Im letzteren Fall gibt es kein Doppelpunkt-Präfix. Ein Service in einem privaten Prozess kann nur mit Ihrer Anwendung interagieren, während ein Service in einem öffentlichen Prozess auch mit anderen Anwendungen umgehen kann. Dies ist hauptsächlich dann der Fall, wenn ein Service in einem separaten Prozess verwendet werden soll: Wenn Sie möchten, dass Ihre Anwendung Daten oder Funktionen mit anderen Anwendungen gemeinsam nutzt und im Hintergrund ausführt, ohne durch das Betriebssystem oder den GC gestört zu werden. Um die Dokumentation zu zitieren:
This allows components in different applications to share a process, reducing resource usage.