Międzyoperacyjna biblioteka natywna

Omówienie

Interoperacyjność z bibliotekami natywnymi (wcześniej określana jako podejście „Slim Binding”) to wzorzec dostępu do natywnych pakietów SDK w aplikacjach .NET MAUI, w tym na platformach .NET for Android, .NET for iOS i .NET for Mac Catalyst. Chodzi o to, aby utworzyć własną abstrakcję lub cienką warstwę pośrednią z uproszczonym interfejsem API dla natywnych zestawów SDK, które chcesz wywoływać z poziomu platformy .NET. Natywne projekty bibliotek/frameworków „wrapper” są tworzone w Android Studio przy użyciu języków Java/Kotlin i/lub w Xcode przy użyciu Objective-C/Swift. Takie podejście jest szczególnie korzystne, gdy potrzebujesz tylko małego wycinka powierzchni interfejsu API zestawu SDK, ale działa również dobrze w przypadku większego użycia powierzchni interfejsu API w tym samym czasie.

Informacje o tym, kiedy i dlaczego należy używać międzyoperacyjności biblioteki natywnej

Interoperacyjność z bibliotekami natywnymi to bardzo skuteczne podejście do integracji z bibliotekami natywnymi, choć nie zawsze musi być najlepszym rozwiązaniem w danym projekcie. Ogólnie rzecz biorąc, jeśli już utrzymujesz powiązania i nadal czujesz się komfortowo, nie ma potrzeby zmiany podejścia. W przypadku projektów wymagających szerokiego użycia interfejsu API biblioteki lub dla dostawców obsługujących deweloperów programu .NET MAUI tradycyjne powiązania mogą być nadal bardziej odpowiednie. Interoperacyjność z bibliotekami natywnymi oferuje jednak alternatywę, która jest często łatwiejsza do zrozumienia, wdrożenia i utrzymania.

Kluczową zaletą mechanizmu Native Library Interop jest jego skuteczność w przypadku prostych interfejsów API. Gdy opakowania obejmują wyłącznie typy proste obsługiwane przez platformę .NET, istniejące narzędzia do tworzenia powiązań mogą generować niezawodne definicje przy minimalnej ręcznej ingerencji, która jest często konieczna w przypadku tradycyjnych powiązań. Dzięki temu proces jest prosty, zwłaszcza że implementacja wrappera API zazwyczaj opiera się na dokumentacji SDK i często pozwala bezpośrednio kopiować z dokumentacji dostawcy.

Chociaż początkowa konfiguracja może być bardziej skomplikowane, zarządzanie aktualizacjami bazowych zestawów SDK zwykle wymaga mniejszego nakładu pracy. Aktualizacje często obejmują po prostu dostosowanie wersji i ponowne skompilowanie projektu. Nawet jeśli w interfejsach API lub zestawach SDK wystąpią niekompatybilne zmiany, interfejs API otoki i sposób użycia aplikacji .NET najprawdopodobniej pozostaną stabilne, dzięki czemu wymaganych będzie mniej zmian niż w przypadku tradycyjnych powiązań językowych.

Podsumowując, współpraca z bibliotekami natywnymi zapewnia kilka korzyści:

• Upraszcza poniższą dokumentację zestawu SDK przy użyciu języków natywnych i narzędzi
• Wymaga mniej ręcznej ingerencji do utworzenia działających powiązań
• Ułatwia konserwację i zmniejsza częstotliwość niezbędnych aktualizacji
• Zwiększa izolację aplikacji przed zmianami w podstawowych zestawach SDK

Mimo że rozwiązywanie łańcuchów zależności (szczególnie w systemie Android) może wymagać podobnego nakładu pracy, jak tradycyjne powiązania, usprawnione zalety implementacji i konserwacji sprawiają, że natywna biblioteka międzyoperacyjna jest atrakcyjnym wyborem dla wielu projektów.

Opis aplikacji Maui.NativeLibraryInterop

Istotne wyzwanie podczas tworzenia i utrzymywania powiązań utworzonych za pośrednictwem międzyoperacyjności biblioteki natywnej polega na ręcznym połączeniu projektów natywnych, ich natywnych zależności, danych wyjściowych kompilacji i projektu biblioteki powiązań platformy .NET. Maui.NativeLibraryInterop pomaga szybko rozpocząć ten proces, bazując na przykładach i dostosowując je do potrzeb własnej aplikacji.

Część tej funkcji obejmuje organizowanie części procesu kompilacji za pomocą wywołań programu MSBuild. Może to obejmować:

• Rozwiązywanie lub pobieranie natywnych zależności zestawu SDK
• Kompilowanie projektu natywnego powiązania slim i jego zależności
• Przenoszenie wymaganych artefaktów natywnych do oczekiwanego katalogu roboczego
• Generowanie definicji interfejsu API dla projektu biblioteki powiązań

Projekty powiązań Androida dodadzą element @(AndroidGradleProject), który wskazuje na plik build.gradle i będzie używany do kompilowania projektu Gradle:

<ItemGroup>
    <AndroidGradleProject Include="../native/build.gradle.kts" >
        <ModuleName>newbinding</ModuleName>
        <!-- Metadata applicable to @(AndroidLibrary) will be used if set, otherwise the following defaults will be used:
        <Bind>true</Bind>
        <Pack>true</Pack>
        -->
    </AndroidGradleProject>
</ItemGroup>

Projekty powiązań dla systemu iOS dodadzą element @(XcodeProject), który odwołuje się do natywnego projektu otoki w Xcode:

<ItemGroup>
    <XcodeProject Include="../native/NewBinding/NewBinding.xcodeproj">
        <SchemeName>NewBinding</SchemeName>
        <!-- Metadata applicable to @(NativeReference) will be used if set, otherwise the following defaults will be used:
        <Kind>Framework</Kind>
        <SmartLink>true</SmartLink>
        -->
    </XcodeProject>
</ItemGroup>

Projekty powiązań systemu Android generują definicję interfejsu API automatycznie, uwzględniając wszelkie opcjonalne modyfikacje ręczne, takie jak te zaimplementowane za pośrednictwem pliku przekształcenia Metadata.xml .

Projekt biblioteki powiązań systemu iOS musi zawierać jawnie zdefiniowany interfejs API. Aby w tym pomóc, narzędzie Objective-Sharpie musi zostać uruchomione na wygenerowanym natywnym frameworku, aby utworzyć plik definicji API (ApiDefinition.cs) obok niego. Służy to jako przydatne odwołanie podczas tworzenia i obsługi pliku ApiDefinition.cs używanego przez projekt powiązania systemu iOS.

Wymagane zależności natywne są osadzone w asemb­lacji powiązań. Gdy projekt platformy .NET dodaje odwołanie do projektu natywnego, zależności natywne są automatycznie uwzględniane w aplikacji.