Międzyoperacyjna biblioteka natywna

Omówienie

Międzyoperacyjna biblioteka natywna (wcześniej nazywana podejściem "Slim Binding") odnosi się do wzorca uzyskiwania dostępu do natywnych zestawów SDK w aplikacjach MAUI platformy .NET, w tym platformy .NET dla systemów Android, .NET dla systemów iOS i .NET dla komputerów Mac Catalyst. Chodzi o to, aby utworzyć własną abstrakcję lub cienką "otokę" z uproszczoną powierzchnią interfejsu API do natywnych zestawów SDK, które cię interesują, wywołując z platformy .NET. Natywne projekty biblioteki/struktury "otoki" są tworzone w programie Android Studio przy użyciu języka Java/Kotlin i/lub Xcode przy użyciu języka 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

Międzyoperacyjna biblioteka natywna to bardzo skuteczne podejście do integracji z bibliotekami natywnymi, chociaż może nie zawsze być najlepszym rozwiązaniem dla projektu. 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. Jednak międzyoperacyjna biblioteka natywna oferuje alternatywę, która jest często łatwiejsza do zrozumienia, zaimplementowania i konserwacji.

Kluczową zaletą międzyoperacyjności biblioteki natywnej jest jej skuteczność dzięki prostym powierzchniom interfejsu API. Gdy otoki obejmują tylko typy pierwotne obsługiwane przez platformę .NET, istniejące narzędzia powiązania mogą generować niezawodne definicje z minimalną interwencją ręczną, która jest często wymagana w przypadku tradycyjnych powiązań. Dzięki temu proces jest prosty, zwłaszcza że implementacja interfejsu API otoki zwykle jest zgodna z dokumentacją zestawu SDK i często umożliwia bezpośrednie kopiowanie 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 zmiany powodujące niezgodność wystąpią na powierzchniach interfejsu API lub zestawach SDK, powierzchnia interfejsu API otoki i użycie aplikacji platformy .NET będą bardziej stabilne, co wymaga mniejszej liczby korekt w porównaniu z tradycyjnymi powiązaniami.

Podsumowując, międzyoperacyjna biblioteka natywna zapewnia kilka korzyści:

• Upraszcza poniższą dokumentację zestawu SDK przy użyciu języków natywnych i narzędzi
• Wymaga mniejszej interwencji ręcznej w celu utworzenia powiązań roboczych
• 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. Aplikacja Maui.NativeLibraryInterop ułatwia rozpoczęcie procesu przez utworzenie i dostosowanie przykładów dla własnych potrzeb 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
• Tworzenie natywnego projektu powiązania szczupłego i jego zależności
• Przenoszenie wymaganych artefaktów natywnych do oczekiwanego katalogu roboczego
• Generowanie definicji interfejsu API dla projektu biblioteki powiązań

Proces kompilacji powiązania został rozszerzony w celu uzyskania i skompilowania natywnych zależności zestawu SDK przez dodanie CommunityToolkit.Maui.NativeLibraryInterop.BuildTasks pakietu NuGet do projektu powiązania:

<ItemGroup>
    <PackageReference Include="CommunityToolkit.Maui.NativeLibraryInterop.BuildTasks" Version="0.0.1-pre1" />
</ItemGroup>

Projekty powiązań systemu Android spowodują @(NLIGradleProjectReference) dodanie elementu wskazującego folder główny zawierający natywny projekt narzędzia gradle otoki:

<ItemGroup>
    <NLIGradleProjectReference Include="../native" >
        <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>
        -->
    </NLIGradleProjectReference>
</ItemGroup>

Projekty powiązań systemu iOS dodają @(NLIXcodeProjectReference) element wskazujący na natywny projekt Xcode otoki:

<ItemGroup>
    <NLIXcodeProjectReference Include="../native/NewBinding/NewBinding.xcodeproj">
        <SchemeName>NewBinding</SchemeName>
        <SharpieNamespace>NewBinding</SharpieNamespace>
        <SharpieBind>true</SharpieBind>
        <!-- Metadata applicable to @(NativeReference) will be used if set, otherwise the following defaults will be used:
        <Kind>Framework</Kind>
        <SmartLink>true</SmartLink>
        -->
    </NLIXcodeProjectReference>
</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 to ułatwić, narzędzie Objective-Sharpie można uruchamiać automatycznie w wynikowej strukturze natywnej w celu utworzenia pliku definicji interfejsu API (ApiDefinition.cs) obok niego. Może to służyć jako przydatne odwołanie podczas tworzenia i obsługi pliku ApiDefintion.cs używanego przez projekt powiązania systemu iOS.

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