Freigeben über


Erstellen einer universellen Windows-App mit mehreren Instanzen

In diesem Thema wird beschrieben, wie Sie UWP-Apps (Universelle Windows-Plattform) mit mehreren Instanzen erstellen.

Ab Windows 10, Version 1803 (10.0; Build 17134) können Ihre UWP-Apps mehrere Instanzen unterstützen. Wenn eine Instanz einer UWP-App mit mehreren Instanzen ausgeführt wird und eine nachfolgende Aktivierungsanforderung erfolgt, wird die Plattform die vorhandene Instanz nicht aktivieren. Stattdessen wird eine neue Instanz erstellt, die in einem separaten Prozess ausgeführt wird.

Einwilligung in Mehrinstanzenverhalten

Wenn Sie eine neue Anwendung mit mehreren Instanzen erstellen, können Sie die Multiinstanz-App-Projektvorlagen.VSIX-installieren, die im Visual Studio Marketplaceverfügbar sind. Nachdem Sie die Vorlagen installiert haben, stehen sie im Dialogfeld Neues Projekt unter Visual C# > Windows Universal (oder Andere Sprachen > Visual C++ > Windows Universal) zur Verfügung.

Hinweis

Die Projektvorlage für das Multi-Instance-App-Projekt ist nicht mehr verfügbar. Die VSIX-Vorlage war eine Einfachheit, daher müssen Sie stattdessen das vorhandene Projekt ändern, wie unten beschrieben. Achten Sie darauf, die Konstante DISABLE_XAML_GENERATED_MAIN den Projektbuildsymbolen hinzuzufügen, da dies verhindert, dass der Build ein Standard-Main() generiert. Dies ermöglicht die Verwendung einer speziell geschriebenen app-spezifischen Version von Main().

Zwei Vorlagen werden installiert: Multi-Instance UWP-App, die die Vorlage zum Erstellen einer Mehrinstanzen-App bereitstellt, und Multi-Instance-Umleitungs-UWP-App, die zusätzliche Logik bereitstellt. Mit dieser Logik können Sie entweder eine neue Instanz starten oder selektiv eine bereits gestartete Instanz aktivieren. Vielleicht möchten Sie z. B. nur eine Instanz beim Bearbeiten desselben Dokuments verwenden, sodass Sie die Instanz mit der geöffneten Datei in den Vordergrund holen, anstatt eine neue Instanz zu starten.

Beide Vorlagen fügen der SupportsMultipleInstances Datei package.appxmanifest hinzu. Beachten Sie das Namespace-Präfix desktop4: Nur Projekte, die auf den Desktop abzielen, unterstützen die Mehrfachausführung.

Hinweis

Wenn Ihre App auf Windows 10, Version 2004 (Build 19041) oder höher ausgerichtet ist, können Sie das neuere Attribut uap10:SupportsMultipleInstances anstelle von desktop4:SupportsMultipleInstances verwenden. Der uap10 Namespace ist der bevorzugte Ansatz für neuere Anwendungen.

<Package
  ...
  xmlns:desktop4="http://schemas.microsoft.com/appx/manifest/desktop/windows10/4"
  IgnorableNamespaces="uap mp desktop4">
  ...
  <Applications>
    <Application Id="App"
      ...
      desktop4:SupportsMultipleInstances="true">
      ...
    </Application>
  </Applications>
   ...
</Package>

Umleitung der Mehrinstanzaktivierung

Die Unterstützung für Mehrfachinstanzen von UWP-Apps geht über die bloße Möglichkeit hinaus, mehrere Instanzen der App zu starten. Sie ermöglicht Anpassungen in Fällen, in denen Sie auswählen möchten, ob eine neue Instanz Ihrer App gestartet wird oder ob eine bereits ausgeführte Instanz aktiviert ist. Wenn die App beispielsweise gestartet wird, um eine Datei zu bearbeiten, die bereits in einer anderen Instanz bearbeitet wird, können Sie die Aktivierung an diese Instanz umleiten, anstatt eine andere Instanz zu öffnen, die bereits die Datei bearbeitet.

Sehen Sie sich dieses Video zum Erstellen von UWP-Apps mit mehreren Instanzen an, um sie in Aktion zu sehen.

Die Multi-Instance-Umleitungs-UWP-App Vorlage fügt SupportsMultipleInstances der Datei "package.appxmanifest" hinzu, wie oben gezeigt, und fügt Ihrem Projekt eine Program.cs (oder Program.cpphinzu, wenn Sie die C++-Version der Vorlage verwenden), die eine Main() Funktion enthält. Die Logik für die Aktivierungsumleitung erfolgt in der Main-Funktion. Die Vorlage für Program.cs wird unten angezeigt.

Die AppInstance.RecommendedInstance-Eigenschaft stellt die von der Shell bereitgestellte bevorzugte Instanz für diese Aktivierungsanforderung dar, falls eine vorhanden ist (oder null, falls keine vorhanden ist). Wenn die Shell eine Einstellung bereitstellt, können Sie die Aktivierung auf diese Instanz umleiten oder sie ignorieren, wenn Sie möchten.

public static class Program
{
    // This example code shows how you could implement the required Main method to
    // support multi-instance redirection. The minimum requirement is to call
    // Application.Start with a new App object. Beyond that, you may delete the
    // rest of the example code and replace it with your custom code if you wish.

    static void Main(string[] args)
    {
        // First, we'll get our activation event args, which are typically richer
        // than the incoming command-line args. We can use these in our app-defined
        // logic for generating the key for this instance.
        IActivatedEventArgs activatedArgs = AppInstance.GetActivatedEventArgs();

        // If the Windows shell indicates a recommended instance, then
        // the app can choose to redirect this activation to that instance instead.
        if (AppInstance.RecommendedInstance != null)
        {
            AppInstance.RecommendedInstance.RedirectActivationTo();
        }
        else
        {
            // Define a key for this instance, based on some app-specific logic.
            // If the key is always unique, then the app will never redirect.
            // If the key is always non-unique, then the app will always redirect
            // to the first instance. In practice, the app should produce a key
            // that is sometimes unique and sometimes not, depending on its own needs.
            string key = Guid.NewGuid().ToString(); // always unique.
                                                    //string key = "Some-App-Defined-Key"; // never unique.
            var instance = AppInstance.FindOrRegisterInstanceForKey(key);
            if (instance.IsCurrentInstance)
            {
                // If we successfully registered this instance, we can now just
                // go ahead and do normal XAML initialization.
                global::Windows.UI.Xaml.Application.Start((p) => new App());
            }
            else
            {
                // Some other instance has registered for this key, so we'll 
                // redirect this activation to that instance instead.
                instance.RedirectActivationTo();
            }
        }
    }
}

Main() ist das erste, was ausgeführt wird. Das wird vor OnLaunched und OnActivatedausgeführt. Auf diese Weise können Sie ermitteln, ob dies oder eine andere Instanz aktiviert werden soll, bevor ein anderer Initialisierungscode in Ihrer App ausgeführt wird.

Der obige Code bestimmt, ob eine vorhandene oder neue Instanz Ihrer Anwendung aktiviert ist. Ein Schlüssel wird verwendet, um zu bestimmen, ob eine vorhandene Instanz vorhanden ist, die Sie aktivieren möchten. Wenn Ihre App beispielsweise gestartet werden kann, um die Dateiaktivierungzu behandeln, könnten Sie den Dateinamen als Schlüssel verwenden. Anschließend können Sie überprüfen, ob eine Instanz Ihrer App bereits mit diesem Schlüssel registriert ist und aktivieren, anstatt eine neue Instanz zu öffnen. Dies ist die Idee hinter dem Code: var instance = AppInstance.FindOrRegisterInstanceForKey(key);

Wenn eine instanz, die mit dem Schlüssel registriert ist, gefunden wird, wird diese Instanz aktiviert. Wenn der Schlüssel nicht gefunden wird, erstellt die aktuelle Instanz (die Instanz, die derzeit Mainausgeführt wird) das Anwendungsobjekt und startet die Ausführung.

Hintergrundaufgaben und Multiinstanzerstellung

  • Out-of-proc-Hintergrundaufgaben unterstützen die Multiinstanzunterstützung. In der Regel führt jeder neue Trigger zu einer neuen Instanz der Hintergrundaufgabe (obwohl technisch gesehen mehrere Hintergrundaufgaben im selben Hostprozess ausgeführt werden können). Dennoch wird eine andere Instanz der Hintergrundaufgabe erstellt.
  • In-proc-Hintergrundaufgaben unterstützen keine Mehrinstanzfähigkeit.
  • Hintergrundaudioaufgaben unterstützen keine mehrfache Instanzierung.
  • Wenn eine App eine Hintergrundaufgabe registriert, überprüft sie in der Regel zuerst, ob die Aufgabe bereits registriert ist, und löscht sie dann erneut, oder führt nichts aus, um die vorhandene Registrierung beizubehalten. Dies ist weiterhin das typische Verhalten bei Apps mit mehreren Instanzen. Eine Multi-Instancing-App kann sich jedoch entscheiden, pro Instanz einen anderen Namen für die Hintergrundaufgabe zu registrieren. Dies führt zu mehreren Registrierungen desselben Triggers, und mehrere Instanzen von Hintergrundaufgaben werden aktiviert, wenn der Trigger ausgelöst wird.
  • App-Dienste starten eine separate Instanz der Hintergrundaufgabe des App-Diensts für jede Verbindung. Dies bleibt für Apps mit mehreren Instanzen unverändert, d. h. jede Instanz einer Multiinstanz-App erhält eine eigene Instanz der Hintergrundaufgabe des App-Diensts.

Weitere Überlegungen

  • Multi-Instancing wird von UWP-Apps unterstützt, die auf Desktopprojekte abzielen.
  • Um Racebedingungen und Konflikte zu vermeiden, müssen Apps mit mehreren Instanzen Schritte unternehmen, um den Zugriff auf Einstellungen, den app-eigenen Speicher und alle anderen Ressourcen (z. B. Benutzerdateien, Datenspeicher usw.) zu partitionieren und zu synchronisieren, die zwischen mehreren Instanzen geteilt werden können. Standardsynchronisierungsmechanismen wie Mutexes, Semaphoren, Ereignisse usw. sind verfügbar.
  • Wenn die App über SupportsMultipleInstances in der Datei "Package.appxmanifest" verfügt, müssen ihre Erweiterungen SupportsMultipleInstancesnicht deklarieren.
  • Wenn Sie SupportsMultipleInstances zu einer anderen Erweiterung hinzufügen, mit Ausnahme von Hintergrundaufgaben oder App-Diensten, und die App, die die Erweiterung hostet, nicht auch SupportsMultipleInstances in ihrer Datei "Package.appxmanifest" deklariert, dann wird ein Schemafehler generiert.
  • Apps können die ResourceGroup--Deklaration in ihrem Manifest verwenden, um mehrere Hintergrundaufgaben auf demselben Host zu gruppieren. Dies steht in Konflikt mit der Multiinstanzerstellung, bei der jede Aktivierung in einen separaten Host wechselt. Daher kann eine App nicht sowohl SupportsMultipleInstances als auch ResourceGroup in ihrem Manifest deklarieren.

Beispiel

Siehe Beispiel für mehrere Instanzen für ein Beispiel für die Umleitung von Aktivierungen mit mehreren Instanzen.

Siehe auch

AppInstance.FindOrRegisterInstanceForKeyAppInstance.GetActivatedEventArgsAppInstance.RedirectActivationToApp-Aktivierung behandeln