ネイティブ ライブラリ インターロップ

概要

Native Library Interop (旧称 "Slim Binding") は、.NET MAUI アプリ (.NET for Android、.NET for iOS、.NET for Mac Catalyst アプリなど) でネイティブ SDK にアクセスするためのパターンを指します。 そのアイデアは、.NET から呼び出したいネイティブ SDK に対する簡略化された API サーフェスを持つ独自の抽象化または薄い "ラッパー" を作成することです。 このネイティブ "ラッパー" ライブラリ/フレームワーク プロジェクトは、Android Studio 内に Java/Kotlin を使用して、または Xcode 内に Objective-C/Swift を使用して作成されます。 このアプローチはその SDK の API サーフェスのごく一部しか必要としない場合に特に適していますが、より大きな API サーフェスを使用する場合でも同様に上手く機能します。

概念の概要: NativeLibraryInterop

Native Library Interop を使用するタイミングと理由の理解

Native Library Interop は、ネイティブ ライブラリとの統合を行うための非常に効果的なアプローチですが、必ずしもあなたのプロジェクトにとって最適なものとは限りません。 一般的に、すでにバインディングを保守していて、今後もそれを問題なく続けられるのであれば、やり方を変える必要はありません。 ライブラリの API の広範な使用を必要とするプロジェクトや、.NET MAUI 開発者をサポートするベンダーにとっては、従来のバインディングの方が依然として適している場合があります。 ただし、Native Library Interop は多くの場合、理解、実装、保守がより簡単な代替手段を提供します。

Native Library Interop の主な利点は、単純な API サーフェスでの効率性です。 ラッパーに含まれるのが .NET がサポートするプリミティブ型だけである場合、既存のバインド ツールは、従来のバインディングでしばしば必要となる手動作業を最小限に抑えながら信頼性の高い定義を生成することができます。 これによってプロセスは単純になります。ラッパー API の実装は通常、SDK ドキュメントに従い、多くの場合ベンダー ドキュメントからの直接コピーが可能になるからです。

初期セットアップはより複雑になるかもしれませんが、基盤 SDK への更新の管理に必要となる手間は一般的に少なくなります。 多くの場合、更新作業はバージョンの調整とプロジェクトのリビルドだけで済みます。 API サーフェスまたは SDK で破壊的変更が発生した場合でも、ラッパー API サーフェスと .NET アプリケーションの使用方法は安定したままとなる可能性が高く、従来のバインディングと比較して必要になる調整は少なくなります。

要約すると、Native Library Interop には以下に示すいくつかの利点があります。

  • ネイティブ言語とツールで SDK ドキュメントに従うことを簡略化する
  • 機能するバインディングを作成するために必要となる手動作業を減らす
  • メンテナンスを容易にし、必要な更新の頻度を減らす
  • 基盤 SDK の変更からのアプリの分離度合を高める

(特に Android 上での) 依存関係チェーンの解決には従来のバインディングと同様の作業が必要になる場合もありますが、合理化された実装とメンテナンスの利点により、Native Library Interop は多くのプロジェクトにとって魅力的な選択肢となります。

Maui.NativeLibraryInterop について理解する

Native Library Interop を介して作成されるバインディングを作成して保守する上での重要な課題は、ネイティブ プロジェクト、それらのネイティブ依存関係、ビルド出力、.NET Binding ライブラリ プロジェクトを手動で結合することです。 Maui.NativeLibraryInterop は、ユーザーが独自のアプリのニーズに合わせてサンプルをビルドしてカスタマイズすることでプロセスをすぐに開始できるようにします。

これには、MSBuild 呼び出しを通したビルド プロセスの一部の調整も含まれます。 これには次のものが含まれます:

  • ネイティブ SDK の依存関係の解決またはダウンロード
  • ネイティブ スリム バインディング プロジェクトとその依存関係のビルド
  • 必要なネイティブ アーティファクトの所定の作業ディレクトリへの移動
  • バインディング ライブラリ プロジェクトの API 定義の生成

Android バインド プロジェクトでは、gradle プロジェクトのビルドに使用される build.gradle ファイルを指す @(AndroidGradleProject) 項目が追加されます。

<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>

iOS バインディング プロジェクトでは、以下のようにネイティブ ラッパー Xcode プロジェクトを指す @(XcodeProject) 項目を追加します。

<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>

Android バインディング プロジェクトは、Metadata.xml 変換ファイルを介して実装されたものなど、オプションの手動変更をすべて考慮に入れて、API 定義を自動的に生成します。

概念の概要: Android 向け NativeLibraryInterop

iOS バインディング ライブラリ プロジェクトには、明示的に定義された API を含める必要があります。 これを支援するには、 Objective-Sharpie を結果のネイティブ フレームワークで実行して、 API 定義ファイル (ApiDefinition.cs) を生成する必要があります。 これは、iOS バインド プロジェクトで使用されるApiDefinition.cs ファイルを作成および保守する際に役立つ参照として役立ちます。

概念: iOS 用 NativeLibraryInterop

必要なネイティブ依存関係は、バインディング アセンブリに埋め込まれます。 .NET プロジェクトがネイティブ プロジェクトへの参照を追加する際に、ネイティブ依存関係はアプリ内に自動的に含められます。

  • Last updated on