Interoperabilidade de bibliotecas nativas

Visão geral

Native Library Interop (anteriormente referida como a abordagem "Slim Binding"), refere-se a um padrão para acessar SDKs nativos em aplicativos .NET MAUI, incluindo .NET para Android, .NET para iOS e .NET para aplicativos Catalyst Mac. A ideia é criar sua própria abstração ou "wrapper" fino com uma superfície de API simplificada para os SDKs nativos que você está interessado em chamar do .NET. Os projetos nativos de biblioteca/framework "wrapper" são criados no Android Studio usando Java/Kotlin e/ou Xcode usando Objective-C/Swift. Essa abordagem é especialmente benéfica quando você precisa apenas de uma pequena fatia da superfície da API do SDK, embora também funcione bem para uso maior da superfície da API mesmo assim.

Entendendo quando e por que usar a Interoperabilidade de Biblioteca Nativa

A interoperabilidade de bibliotecas nativas é uma abordagem muito eficaz para a integração com bibliotecas nativas, embora nem sempre seja a melhor opção para o seu projeto. Geralmente, se você já está mantendo vinculações e se sente confortável em continuar a fazê-lo, não há necessidade de mudar as abordagens. Para projetos que exigem o uso extensivo da API de uma biblioteca ou para fornecedores que suportam desenvolvedores .NET MAUI, as associações tradicionais ainda podem ser mais adequadas. A interoperabilidade de bibliotecas nativas, no entanto, oferece uma alternativa que muitas vezes é mais fácil de entender, implementar e manter.

Um dos principais benefícios do Native Library Interop é sua eficácia com superfícies de API simples. Quando os wrappers envolvem apenas tipos primitivos suportados pelo .NET, as ferramentas de vinculação existentes podem gerar definições confiáveis com intervenção manual mínima, que geralmente é necessária para associações tradicionais. Isso torna o processo simples, especialmente porque a implementação da API do wrapper normalmente segue a documentação do SDK e geralmente permite a cópia direta da documentação do fornecedor.

Embora a configuração inicial possa ser mais complexa, o gerenciamento de atualizações para SDKs subjacentes geralmente requer menos esforço. As atualizações geralmente envolvem simplesmente ajustar a versão e reconstruir o projeto. Mesmo que ocorram alterações significativas nas superfícies da API ou SDKs, é mais provável que a API intermediária e o uso da aplicação .NET permaneçam estáveis, exigindo menos ajustes em comparação com as associações tradicionais.

Em resumo, a Interoperabilidade de Biblioteca Nativa oferece vários benefícios:

• Simplifica seguir a documentação do SDK utilizando idiomas e ferramentas nativas.
• Requer menos intervenção manual para criar ligações funcionais.
• Facilita a manutenção e reduz a frequência das atualizações necessárias
• Melhora o isolamento do aplicativo contra alterações em SDKs subjacentes

Embora a resolução de cadeias de dependência (particularmente no Android) possa exigir um esforço semelhante ao das ligações tradicionais, as vantagens simplificadas de implementação e manutenção tornam a Interoperabilidade de Biblioteca Nativa uma escolha atraente para muitos projetos.

Entendendo Maui.NativeLibraryInterop

Um desafio notável na criação e manutenção de ligações por meio da Interoperabilidade de Biblioteca Nativa é consolidar manualmente os projetos nativos, as suas dependências nativas, os resultados da compilação, e o projeto de biblioteca de ligação .NET. Maui.NativeLibraryInterop ajuda você a iniciar o processo criando e personalizando os exemplos para as necessidades do seu próprio aplicativo.

Parte disso inclui orquestrar partes do processo de compilação por meio de invocações do MSBuild. Isto pode incluir:

• Resolvendo ou baixando dependências nativas do SDK
• Construindo o projeto de vinculação slim nativo e suas dependências
• Movendo os artefatos nativos necessários para o diretório de trabalho esperado
• Gerando a definição de API para o projeto de biblioteca de vinculação

Os projetos de vinculação do Android adicionarão um item @(AndroidGradleProject) que aponta para um arquivo build.gradle que será usado para construir o projeto 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>

Os projetos de ligação do iOS adicionarão um item @(XcodeProject) que aponta para o projeto Xcode do wrapper nativo.

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

Os projetos de vinculação do Android geram a definição da API automaticamente, levando em conta quaisquer modificações manuais opcionais, como as implementadas por meio do arquivo de transformação Metadata.xml.

Um projeto de biblioteca de vinculação do iOS deve incluir uma API explicitamente definida. Para ajudar com isso, Objective-Sharpie deve ser executado na estrutura nativa resultante para produzir um arquivo de definição de API (ApiDefinition.cs) junto com ele. Isso serve como uma referência útil ao criar e manter o arquivo de ApiDefinition.cs usado pelo projeto de vinculação do iOS.

As dependências nativas necessárias são incorporadas ao assembly de ligação. Quando um projeto .NET adiciona uma referência ao projeto nativo, as dependências nativas são incluídas no aplicativo automaticamente.