Bearbeiten: Diese Frage ist jetzt etwas veraltet, da Google uns die Möglichkeit gegeben hat, sie zu erfassen ViewModel zu den Navigationsgrafiken. Der bessere Ansatz (anstatt zu versuchen, aktivitätsbezogene Modelle zu löschen) wäre, spezifische Navigationsdiagramme für die richtige Anzahl von Bildschirmen und den entsprechenden Umfang zu erstellen.

Unter Bezugnahme auf die android.arch.lifecycle.ViewModel Klasse.

ViewModel ist auf den Lebenszyklus der UI-Komponente beschränkt, auf die sie sich bezieht, also in a Fragment-basierte App, das wird der Fragment-Lebenszyklus sein. Das ist eine gute Sache.

In einigen Fällen möchte man a teilen ViewModel Instanz zwischen mehreren Fragmenten. Insbesondere interessiert mich der Fall, wo Viele Bildschirme beziehen sich auf dieselben zugrunde liegenden Daten.

(Die Dokumentation schlägt einen ähnlichen Ansatz vor, wenn mehrere verwandte Fragmente auf demselben Bildschirm angezeigt werden, aber dies kann umgangen werden, indem ein einzelnes Hostfragment gemäß der folgenden Antwort verwendet wird.)

Dies wird in der diskutiert offizielle ViewModel-Dokumentation:

ViewModels können auch als Kommunikationsschicht zwischen verschiedenen Fragmenten einer Aktivität verwendet werden. Jedes Fragment kann das ViewModel mit demselben Schlüssel über seine Aktivität abrufen. Dies ermöglicht eine entkoppelte Kommunikation zwischen Fragmenten, sodass sie nie direkt mit dem anderen Fragment sprechen müssen.

Mit anderen Worten, um Informationen zwischen Fragmenten auszutauschen, die verschiedene Bildschirme darstellen, die ViewModel sollte sich auf die erstrecken Activity Lebenszyklus (und laut Android-Dokumentation kann dies auch in anderen gemeinsam genutzten Instanzen verwendet werden).

Im neuen Jetpack-Navigationsmuster wird jetzt empfohlen, eine „Eine Aktivität/Viele Fragmente“-Architektur zu verwenden. Das bedeutet, dass die Aktivität für die gesamte Nutzungsdauer der App aktiv ist.

dh alle geteilt ViewModel Instanzen, die im Bereich sind Activity Lebenszyklus wird nie gelöscht – der Speicher bleibt in ständiger Verwendung.

Um Speicherplatz zu sparen und zu jedem Zeitpunkt so wenig wie nötig zu verwenden, wäre es schön, Shared löschen zu können ViewModel Instanzen, wenn sie nicht mehr benötigt werden.

Wie kann man a ViewModel von seinem ViewModelStore oder Halterfragment?

Schnelle Lösung ohne zu verwenden Navigation Component Bibliothek:

getActivity().getViewModelStore().clear();

Dies wird dieses Problem lösen, ohne die einzubeziehen Navigation Component Bibliothek. Es ist auch eine einfache Codezeile. Es wird diese löschen ViewModels die zwischen geteilt werden Fragments über die Activity

Wenn Sie den Code überprüfen hier Sie werden herausfinden, dass Sie die bekommen können ViewModelStore von einem ViewModelStoreOwner und Fragment, FragmentActivity zum Beispiel implementiert diese Schnittstelle.

Also von dort aus könntest du einfach anrufen viewModelStore.clear()die, wie die Dokumentation sagt:

 /**
 *  Clears internal storage and notifies ViewModels that they are no longer used.
 */
public final void clear() {
    for (ViewModel vm : mMap.values()) {
        vm.clear();
    }
    mMap.clear();
}

Hinweis: Dadurch werden alle verfügbaren ViewModels für den bestimmten LifeCycleOwner gelöscht, Sie können jedoch kein bestimmtes ViewModel löschen.

Wie OP und Archie sagten, hat Google uns die Möglichkeit gegeben, ViewModel auf Navigationsdiagramme auszurichten. Ich werde hier hinzufügen, wie es geht, wenn Sie die Navigationskomponente bereits verwenden.

Sie können alle Fragmente auswählen, die innerhalb des Navigationsdiagramms gruppiert werden müssen, und right-click->move to nested graph->new graph

Jetzt werden die ausgewählten Fragmente wie folgt in ein verschachteltes Diagramm innerhalb des Hauptnavigationsdiagramms verschoben:

<navigation app:startDestination="@id/homeFragment" ...>
    <fragment android:id="@+id/homeFragment" .../>
    <fragment android:id="@+id/productListFragment" .../>
    <fragment android:id="@+id/productFragment" .../>
    <fragment android:id="@+id/bargainFragment" .../>

    <navigation 
        android:id="@+id/checkout_graph" 
        app:startDestination="@id/cartFragment">

        <fragment android:id="@+id/orderSummaryFragment".../>
        <fragment android:id="@+id/addressFragment" .../>
        <fragment android:id="@+id/paymentFragment" .../>
        <fragment android:id="@+id/cartFragment" .../>

    </navigation>

</navigation>

Tun Sie dies jetzt innerhalb der Fragmente, wenn Sie das Ansichtsmodell initialisieren

val viewModel: CheckoutViewModel by navGraphViewModels(R.id.checkout_graph)

Wenn Sie die Viewmodel-Fabrik passieren müssen (möglicherweise zum Injizieren des Viewmodels), können Sie dies folgendermaßen tun:

val viewModel: CheckoutViewModel by navGraphViewModels(R.id.checkout_graph) { viewModelFactory }

Stellen Sie sicher, dass es R.id.checkout_graph und nicht R.navigation.checkout_graph

Aus irgendeinem Grund das Nav-Diagramm erstellen und verwenden include Es in das Hauptnavigationsdiagramm zu verschachteln, funktionierte bei mir nicht. Wahrscheinlich ist es ein Bug.

Quelle: https://medium.com/androiddevelopers/viewmodels-with-saved-state-jetpack-navigation-data-binding-and-coroutines-df476b78144e

Danke, OP und @Archie, dass sie mich in die richtige Richtung gewiesen haben.

Ich glaube, ich habe eine bessere Lösung.

Wie von @Nagy Robi angegeben, könnten Sie die löschen ViewModel per Anruf viewModelStore.clear(). Das Problem dabei ist, dass ALLE darin enthaltenen Ansichtsmodelle gelöscht werden ViewModelStore. Mit anderen Worten, Sie haben keine Kontrolle darüber, welche ViewModel zu löschen.

Aber laut @mikehc hier. Wir könnten tatsächlich unsere eigenen erstellen ViewModelStore stattdessen. Dadurch können wir genau steuern, in welchem ​​Umfang das ViewModel vorhanden sein muss.

Hinweis: Ich habe niemanden gesehen, der diesen Ansatz verwendet, aber ich hoffe, dass dies ein gültiger ist. Dies ist eine wirklich gute Möglichkeit, Bereiche in einer Einzelaktivitätsanwendung zu steuern.

Bitte geben Sie einige Rückmeldungen zu diesem Ansatz. Alles wird geschätzt.

Aktualisieren:

Seit Navigationskomponente v2.1.0-alpha02, ViewModels könnten nun einem Flow zugeordnet werden. Der Nachteil dabei ist, dass Sie implementieren müssen Navigation Component zu Ihrem Projekt und Sie haben auch keine granulare Kontrolle über den Umfang Ihres Projekts ViewModel. Aber das scheint eine bessere Sache zu sein.

Wenn Sie das nicht möchten ViewModel umfasst zu werden Activity Lebenszyklus, können Sie es auf den Lebenszyklus des übergeordneten Fragments beschränken. Wenn Sie also eine Instanz der ViewModel Bei mehreren Fragmenten in einem Bildschirm können Sie die Fragmente so anordnen, dass sie alle ein gemeinsames übergeordnetes Fragment teilen. Auf diese Weise, wenn Sie die instanziieren ViewModel Sie können einfach dies tun:

CommonViewModel viewModel = ViewModelProviders.of(getParentFragment()).class(CommonViewModel.class);

Hoffentlich hilft das!

Es scheint, als wäre es bereits in der neuesten Version der Architekturkomponenten gelöst worden.

ViewModelProvider hat folgenden Konstruktor:

    /**
 * Creates {@code ViewModelProvider}, which will create {@code ViewModels} via the given
 * {@code Factory} and retain them in a store of the given {@code ViewModelStoreOwner}.
 *
 * @param owner   a {@code ViewModelStoreOwner} whose {@link ViewModelStore} will be used to
 *                retain {@code ViewModels}
 * @param factory a {@code Factory} which will be used to instantiate
 *                new {@code ViewModels}
 */
public ViewModelProvider(@NonNull ViewModelStoreOwner owner, @NonNull Factory factory) {
    this(owner.getViewModelStore(), factory);
}

Was im Fall von Fragment Scoped ViewModelStore verwenden würde.

androidx.fragment.app.Fragment#getViewModelStore

    /**
 * Returns the {@link ViewModelStore} associated with this Fragment
 * <p>
 * Overriding this method is no longer supported and this method will be made
 * <code>final</code> in a future version of Fragment.
 *
 * @return a {@code ViewModelStore}
 * @throws IllegalStateException if called before the Fragment is attached i.e., before
 * onAttach().
 */
@NonNull
@Override
public ViewModelStore getViewModelStore() {
    if (mFragmentManager == null) {
        throw new IllegalStateException("Can't access ViewModels from detached fragment");
    }
    return mFragmentManager.getViewModelStore(this);
}

androidx.fragment.app.FragmentManagerViewModel#getViewModelStore

    @NonNull
ViewModelStore getViewModelStore(@NonNull Fragment f) {
    ViewModelStore viewModelStore = mViewModelStores.get(f.mWho);
    if (viewModelStore == null) {
        viewModelStore = new ViewModelStore();
        mViewModelStores.put(f.mWho, viewModelStore);
    }
    return viewModelStore;
}

Ich schreibe gerade eine Bibliothek, um dieses Problem zu lösen: scoped-vm, schau es dir gerne an und ich freue mich über jedes Feedback. Unter der Haube verwendet es den von @Archie erwähnten Ansatz – es verwaltet einen separaten ViewModelStore pro Bereich. Aber es geht noch einen Schritt weiter und löscht ViewModelStore selbst, sobald das letzte Fragment, das Viewmodel von diesem Bereich angefordert hat, zerstört wird.

Ich sollte sagen, dass derzeit das gesamte Viewmodel-Management (und diese Bibliothek besonders) von a betroffen ist schwerwiegender Fehler mit dem Backstack, hoffentlich wird es behoben.

Zusammenfassung:

• Wenn Sie sich darum kümmern ViewModel.onCleared() nicht angerufen wird, ist es (vorerst) am besten, es selbst zu löschen. Aufgrund dieses Fehlers haben Sie keine Garantie dafür, dass das Ansichtsmodell von a fragment wird jemals gelöscht.
• Wenn Sie sich nur Sorgen um durchgesickerte machen ViewModel – Keine Sorge, sie werden wie alle anderen nicht referenzierten Objekte von der Garbage Collection erfasst. Fühlen Sie sich frei, meine Bibliothek für eine feinkörnige Scoping zu verwenden, wenn es Ihren Bedürfnissen entspricht.