네이티브 라이브러리 Interop

개요

네이티브 라이브러리 Interop(이전의 "슬림 바인딩" 접근 방식이라고 함)은 Android용 .NET, iOS용 .NET 및 Mac용 .NET Catalyst 앱을 포함하여 .NET MAUI 앱에서 네이티브 SDK에 액세스하는 패턴을 나타냅니다. 이 아이디어는 .NET에서 호출하려는 네이티브 SDK에 대한 간소화된 API 표면을 사용하여 사용자 고유의 추상화 또는 얇은 "래퍼"를 만드는 것입니다. 네이티브 "래퍼" 라이브러리/프레임워크 프로젝트는 Objective-C/Swift를 사용하여 Java/Kotlin 및/또는 Xcode를 사용하여 Android Studio에서 만들어집니다. 이 방법은 SDK의 API 표면의 작은 조각만 필요한 경우에 특히 유용합니다. 하지만 더 큰 API 표면 사용에도 모두 동일하게 작동합니다.

네이티브 라이브러리 Interop을 사용하는 시기 및 이유 이해

네이티브 라이브러리 Interop은 네이티브 라이브러리와 통합하는 매우 효과적인 방법이지만 항상 프로젝트에 가장 적합한 것은 아닙니다. 일반적으로 바인딩을 이미 유지 관리 중이며 계속 사용하는 것이 편한 경우 접근 방식을 변경할 필요가 없습니다. 라이브러리의 API를 광범위하게 사용해야 하는 프로젝트 또는 .NET MAUI 개발자를 지원하는 공급업체의 경우 기존 바인딩이 여전히 더 적합할 수 있습니다. 그러나 네이티브 라이브러리 Interop은 종종 더 쉽게 이해하고 구현하고 유지 관리하는 대안을 제공합니다.

네이티브 라이브러리 Interop의 주요 이점은 간단한 API 표면의 효과입니다. 래퍼에 .NET에서 지원하는 기본 형식만 포함된 경우 기존 바인딩 도구는 최소한의 수동 개입으로 신뢰할 수 있는 정의를 생성할 수 있으며, 이는 종종 기존 바인딩에 필요합니다. 따라서 특히 래퍼 API 구현은 일반적으로 SDK 설명서를 따르며 공급업체 설명서에서 직접 복사할 수 있기 때문에 프로세스가 간단해집니다.

초기 설정은 더 복잡할 수 있지만 기본 SDK에 대한 업데이트를 관리하려면 일반적으로 더 적은 노력이 필요합니다. 업데이트에는 단순히 버전을 조정하고 프로젝트를 다시 빌드하는 작업이 포함되는 경우가 많습니다. API 표면 또는 SDK에서 호환성이 손상되는 변경이 발생하더라도 래퍼 API 표면 및 .NET 애플리케이션의 사용량은 안정적으로 유지될 가능성이 높으므로 기존 바인딩에 비해 조정이 더 적습니다.

요약하면 네이티브 라이브러리 Interop은 다음과 같은 몇 가지 이점을 제공합니다.

• 네이티브 언어 및 도구를 사용하여 다음 SDK 설명서를 간소화합니다.
• 작업 바인딩을 만들려면 수동 작업이 덜 필요합니다.
• 유지 관리를 더 쉽게 하고 필요한 업데이트 빈도를 줄입니다.
• 기본 SDK의 변경 내용으로부터 앱 격리를 향상시킵니다.

종속성 체인(특히 Android)을 해결하려면 기존 바인딩과 비슷한 노력이 필요할 수 있지만, 간소화된 구현 및 유지 관리 이점을 통해 Native Library Interop는 많은 프로젝트에서 매력적인 선택입니다.

Maui.NativeLibraryInterop 이해

네이티브 라이브러리 Interop을 통해 만든 바인딩을 만들고 유지 관리하는 경우 주목할 만한 과제는 네이티브 프로젝트, 기본 종속성, 빌드 출력 및 .NET 바인딩 라이브러리 프로젝트를 수동으로 병합하는 것입니다. 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 정의를 자동으로 생성합니다.

iOS 바인딩 라이브러리 프로젝트에는 명시적으로 정의된 API가 포함되어야 합니다. 이를 돕기 위해, 생성된 네이티브 프레임워크에서 Objective-Sharpie을 실행하여 API 정의 파일(ApiDefinition.cs)를 생성해야 합니다. 이는 iOS 바인딩 프로젝트에서 사용하는 ApiDefinition.cs 파일을 만들고 유지 관리할 때 유용한 참조로 사용됩니다.

필수 네이티브 종속성은 바인딩 어셈블리에 포함됩니다. .NET 프로젝트가 네이티브 프로젝트에 대한 참조를 추가하면 네이티브 종속성이 앱에 자동으로 포함됩니다.