Auswahl von C++ oder C# für nativen Code
Architekturbewertung erforderlich: Diese Dokumentation wurde zur Unterstützung der Entwicklung gegen die "alte" oder "Legacy"-Architektur von React Native geschrieben. Sie ist möglicherweise nicht direkt auf die Entwicklung mit der neuen Architektur anwendbar und muss überprüft und möglicherweise aktualisiert werden. Informationen zu React Native-Architekturen in React Native Windows finden Sie unter Neu vs. Alt Architektur.
Die neuesten Informationen zur nativen Entwicklung unter Windows finden Sie unter Native Plattform: Übersicht.
React Native for Windows unterstützt das Schreiben von nativem Code sowohl in C++ als auch in C#, wobei jede Sprache ihre Vor- und Nachteile hat. Die Wahl der Sprache kann die Kompatibilität, die Entwicklererfahrung und die Leistung Ihres Projekts beeinflussen. Egal, ob Sie eine App oder ein natives Modul erstellen, Sie sollten die native Sprache wählen, die Ihren Anforderungen am besten entspricht.
Hinweis: In diesem Dokument bezieht sich C++ speziell auf C++/WinRT.
Allgemeine Überlegungen
Kompatibilitätsmatrix
Obwohl die Toolchain von React Native for Windows App- und Modulprojekte in beiden Sprachen unterstützt, gibt es Einschränkungen, wenn solche Projekte gemischt werden.
Die folgende Tabelle listet verschiedene Kompatibilitätsszenarien auf und gibt an, ob Apps, die in einer bestimmten Sprache geschrieben sind, Module in einer bestimmten Sprache konsumieren können.
- ✅ bedeutet, dass das Szenario funktioniert
- 🟨 bedeutet, dass das Szenario teilweise funktioniert (d.h. mit spezifischen Einschränkungen)
- 🟥 bedeutet, dass das Szenario nicht funktioniert
| C++ App | C# App | |
|---|---|---|
| C++ Modul | ✅ | ✅ |
| C++ Modul mit C++ NuGet-Abhängigkeit | ✅ | ✅ |
| C++ Modul mit C# NuGet-Abhängigkeit | 🟥 | 🟥 |
| C# Modul | 🟨 | ✅ |
| C# Modul mit C# NuGet-Abhängigkeit | 🟥 | ✅ |
| C# Modul mit C++ NuGet-Abhängigkeit | 🟥 | ✅ |
Wenn Sie also eine App schreiben, müssen Sie sich fragen, ob Sie native Module konsumieren müssen. Wenn ja, sollten Sie die Sprachen dieser Module genau prüfen, wenn Sie die Sprache für Ihre App festlegen.
Wenn Sie ein natives Modul schreiben, müssen Sie sich fragen, ob Sie Pakete von NuGet konsumieren müssen. Wenn ja, sollten Sie die Sprachen dieser Pakete genau prüfen, wenn Sie die Sprache für Ihr Modul festlegen.
Schließlich, wenn Sie vorhandenen nativen (Quell-)Code wiederverwenden möchten, sollten Sie dies ebenfalls berücksichtigen.
Hinweis: Wir arbeiten aktiv daran, die Fehler zu beheben, die diese Szenarien blockieren, und das Mischen von C#- und C++-Projekten zu verbessern. Weitere Details zu den tatsächlichen Fehlern, die die Kompatibilität blockieren, finden Sie in Issue #6819.
Entwicklererfahrung
Die C#-Entwicklung bietet Effizienz beim Schreiben von nativem Code für Windows, einschließlich
- Eine umfangreiche Standardbibliothek
- Ein reichhaltiges Ökosystem an Tools, Bibliotheken und Codebeispielen
- Eine Vielzahl von Syntaxoptionen für moderne Coding-Konventionen
Wenn Sie bereits ein Java-Entwickler sind oder planen, vorhandenen Java-Code von Android zu portieren, stellen Sie möglicherweise fest, dass die Entwicklung in C# weniger Aufwand erfordert als das Schreiben in C++.
Die C++/WinRT-Entwicklung bietet jedoch auch eigene Vorteile
- Zugriff auf das breitere Ökosystem von portablem C++-Code
- Ein reichhaltiges Ökosystem an Tools
- Vollständige Kontrolle über die Speicherverwaltung
Wenn Sie bereits ein C++-Entwickler sind oder planen, vorhandenen C++-Code zu verwenden, werden Sie möglicherweise feststellen, dass die Entwicklung in C++/WinRT am produktivsten ist.
Leistung
Generell kann Code, der in C++ geschrieben ist, schneller ausgeführt werden und weniger Speicher verbrauchen als Code, der in C# geschrieben ist. Das liegt daran, dass Sie mit C++ mehr Kontrolle über Ihre Speicherzuweisungen haben und C++ direkt in nativen Maschinencode für die Zielplattform (x86, x64, ARM usw.) kompiliert wird. Bei C# kann die Garbage Collection zu Leistungseinbußen führen, und obwohl C# schließlich in Maschinencode kompiliert wird (darauf kommen wir gleich zu sprechen), kompiliert es zunächst in eine Zwischensprache, oder IL.
In der Vergangenheit verließen sich C#-Apps auf die Just-in-Time (JIT)-Kompilierung ihrer IL in Maschinencode zur Laufzeit. Das bedeutet, dass die IL an die Rechner der Endbenutzer ausgeliefert wird und dieser JIT-Prozess erst stattfindet, wenn der Benutzer die App ausführt, was sich negativ auf die Leistung und die Startzeit der App auswirken kann.
Dies gilt jedoch nicht für UWP-Apps, die stattdessen standardmäßig die .NET Native Toolchain verwenden. Die .NET Native Toolchain (aktiviert beim Erstellen einer "Release"-Konfiguration Ihrer App) kompiliert Ihren IL-Code zur Build-Zeit in nativen Maschinencode. Daher wird beim Einreichen Ihrer App im Microsoft Store nur der fertige, "native-isierte" Code an die Rechner der Endbenutzer ausgeliefert. Dies verbessert die Leistung und die Startzeiten dieser Apps im Vergleich zu ihren nicht-"native-isierten" Gegenstücken. Weitere Informationen zur Leistung in .NET Native-Apps finden Sie unter Messung der Startverbesserung mit .NET Native.
Letztendlich kann nur eine ordnungsgemäße Leistungsanalyse und -prüfung Ihres tatsächlichen Codes feststellen, ob die Leistungsunterschiede der beiden Sprachen signifikant und/oder für Endbenutzer wahrnehmbar sind.
Hinweis zur Parität
Letztendlich, obwohl wir bestrebt sind, die Parität zwischen der Entwicklung mit C++ und C# aufrechtzuerhalten, hat jede ihre Vor- und Nachteile, und keine ist für alle Szenarien die beste. Der Kern und die überwiegende Mehrheit von React Native for Windows ist selbst in C++/WinRT geschrieben, um sowohl die Leistung zu maximieren als auch die gemeinsame Nutzung von C++-Code mit anderen Projekten auf anderen Plattformen zu erleichtern, einschließlich des Standard-React Native und React Native for macOS.
Aus ähnlichen Gründen bevorzugen Microsoft-Entwickler die Mitarbeit an Community-Modulen in C++ anstelle von C#.
Wenn Ihre App oder Ihr Modul jedoch bereits C# verwendet, sollten Sie sich befugt fühlen, weiterhin C# zu verwenden.
Zusätzliche Ressourcen
Erste Schritte mit UWP für iOS-Entwickler: Wahl der Programmiersprache