Flutter: Suporte à integração com C / C ++ na estrutura de plug-in

@jason-simmons sabe muito sobre o Gradle. Assim que tivermos um .so, posso definitivamente ajudar a carregá-lo.

Descobri que em buildSrc há outra propriedade para definir a versão de compilação do gradle. Depois de atualizar para 2.2.2, progredi e consegui verificar se o .so carrega e pode ser chamado de Java.

Presumivelmente, também precisaríamos adicionar uma API C para enviar HostMessages do código C / C ++ para o Dart.

Sim por favor. Tenho a suspeita de que o retorno de chamada C-> Java pode não ser barato.

alguma atualização disso? Considerando o Flutter para construir um aplicativo de plataforma cruzada que chama o código C ++ compilado em uma biblioteca compartilhada, e este é o único ponto importante de parada.

Isso é possível hoje (e @jtrunick fez isso em seu aplicativo de remessa), mas você tem que passar pelo Java ou Obj-C primeiro.

ou seja, você pode usar https://flutter.io/platform-channels/ para falar do Dart para o Obj-C / Java e, em seguida, da chamada Obj-C / Java para o seu código C ++. Este bug cobre a adição de suporte mais direto para isso e, potencialmente, evitando a passagem Obj-C / Java.

Como o Dart VM é implementado em C ++, não deveria haver uma maneira mais fácil (embora menos segura) de chamar as bibliotecas compartilhadas C diretamente (digamos, via dlopen)? Quanta mudança seria necessária para suporte básico (inseguro / experimental)?

É algo assim: https://www.dartlang.org/articles/dart-vm/native-extensions disponível no Android ou iOS?

Ouvimos este requisito de alguns aplicativos do Google:

• Um desses aplicativos escreveu suas próprias bibliotecas C ++ para operar a câmera e reduzir a latência. Essas bibliotecas são específicas da plataforma e otimizadas para funcionar o mais rápido possível. Invocar essas bibliotecas com a latência mais baixa possível é fundamental para esses aplicativos. Forçá-los a passar por PlatformChannel + JNI não vai conseguir isso no Android.

• Existem equipes móveis avançadas que escrevem componentes de lógica de negócios em C ++ para poder compartilhá-los entre suas implementações Android e iOS. Flutter, que oferece suporte à integração direta com essas bibliotecas, consolidaria ainda mais sua posição de ser a melhor estrutura de plataforma cruzada que existe.

Eu não acho que isso seja um _deve ter_. No entanto, esta é uma área em que o Flutter pode se diferenciar ainda mais de outras soluções de plataforma cruzada.

Um desses aplicativos escreveu suas próprias bibliotecas C ++ para operar a câmera e reduzir a latência. [...] Forçá-los a passar por PlatformChannel + JNI não vai conseguir isso no Android.

Qual foi a solução deles no Android para ir de C ++ para Java e vice-versa?

Se for realmente necessário, podemos permitir extensões nativas DART nas plataformas móveis. No momento, não expomos os símbolos em dart_api.h . Teremos de decidir sobre o seguinte antes de podermos mudar o interruptor:

• Descubra como tornar o compilador AOT ciente do código Dart cujo único ponto de entrada é de um método que pode não estar na biblioteca dinâmica do mecanismo Flutter principal. Caso contrário, a passagem de tremor da árvore pode eliminar o código.
• Fornece orientação sobre como construir e empacotar extensões nativas (Gradle e Xcode para Android e iOS, respectivamente).
• Fornece algumas garantias de estabilidade de ABI para as rotinas em dart_api.h . Embora seja praticamente estável, acredito que ainda está evoluindo para dar conta dos vários modos.

Até o momento, o mecanismo de canais de plataformas parece ter sido adequado para os casos de uso mais simples.

Qual foi a solução deles no Android para ir de C ++ para Java e vice-versa?

Não examinei profundamente seu caso de uso. Parece que eles escreveram todos os bits que precisam de comunicação de latência muito baixa em C ++. Vou perguntar se eles usam algum JNI para casos de uso de desempenho crítico (meu pressentimento é não).

Realmente depende do que podemos fazer do lado do Flutter. Se pudermos fornecer uma interoperabilidade significativamente mais rápida do que JNI, seria uma grande vitória para essas equipes. Eles podem reduzir sua base de código C ++ e passar mais para o lado do aplicativo. Se nosso desempenho de interoperabilidade for comparável ao JNI, não vejo uma grande vitória aqui. Eles provavelmente poderiam continuar o que estão fazendo agora e usar PlatformChannel.

Trata-se de dar a essas equipes um motivo extra para mudar para o Flutter. Eu não ouvi falar que isso seja um bloqueador, então priorize de acordo.

Se entendi o que você está dizendo corretamente, você está dizendo que as soluções atuais devem ter toda a lógica (câmera + IU) em C ++ com lógica mínima em Java, e o desejo é mover a parte da IU dessa lógica para Dart, sem perder a interface de usuário de baixa latência <-> interatividade da câmera.

Você pode falar sobre como é a situação de threading deles? Eles têm apenas um tópico para câmera + IU?

@chinmaygarde pode nos deixar mais perto de resolver isso com seu trabalho atual na API de incorporação.

+1

Algum progresso com este problema?

Já usamos djinni para compartilhar lógicas entre diferentes plataformas. Seria ótimo se pudéssemos ter interoperabilidade entre Dart e C ++, ao invés de ter que ir e voltar através de Java / Objc-C.

Se o Dart puder se integrar com C / C ++, acho uma ótima ideia para dispositivos móveis reutilizar uma tonelada de biblioteca nativa e não precisar vincular a uma plataforma específica usando JNI ou Objective C ++.

Você já pensou em https://github.com/mono/CppSharp? Eles já têm a análise e AST em vigor para c ++, bem como suporte para vários idiomas de destino. Talvez você pudesse criar um gerador de DART para CppSharp?

Integrar um banco de dados baseado em C ++ como o Realm diretamente em C ++ proporcionaria desempenho significativo e aumento de produtividade do desenvolvedor :-) Subir / descer através do JNI seria um desperdício.

Estou considerando o Flutter para um aplicativo de RA que faz visão computacional (provavelmente usando OpenCV), e uma interoperabilidade Dart-C ++ eficiente e direta seria um grande ponto positivo. Imagino que muitas outras pessoas que fazem aplicativos desafiadores em termos de computação podem compartilhar essa necessidade.

Alguém pode confirmar se a interoperabilidade C ++ ainda não está disponível? Isso pode ser feito usando pacotes?

@tofutim A canais de plataforma e, em seguida, usar Obj-C / Java para interagir com seu código C ++. Não é ótimo, mas é tudo o que temos no momento.

Alguém pode confirmar se a interoperabilidade C ++ ainda não está disponível? Isso pode ser feito usando pacotes?

Para interoperar com bibliotecas de plataforma, o mecanismo de canais de plataforma ainda é a recomendação atual.

Um mecanismo de maior desempenho descrito no documento de extensões nativas pode ser adicionado trivialmente. No entanto, não tenho conhecimento de quaisquer garantias de estabilidade de ABI para os símbolos expostos de dart_api.h . Se @ a-siva e @eseidelGoogle puderem confirmar que tais garantias existem, posso começar a expor esses símbolos o mais rápido possível. Opcionalmente, podemos criar um subconjunto do Tonic como wrappers convenientes em torno da API C para facilitar o uso do C ++.

Meu entendimento é que esse bug é sobre fornecer um C-API e ganchos de ferramentas para tornar mais fácil ter um plug-in totalmente C / C ++ (sem necessidade de shimming Obj-C / Java, mas ainda assíncrono através de platform_channels).

Não acho que devemos considerar métodos síncronos como extensões nativas neste momento. (Mas honestamente eu adio isso para

@eseidel

Não acho que devemos considerar métodos síncronos como extensões nativas neste momento

por que é que?

A abordagem atual para chamar C código é Dart -> Java -> C
Cruzamos o
primeira vez: dart a Java por meio de canais de plataforma (por baixo do capô, chamada JNI usada, certo?)
segunda vez: Java -> C via JNI

Como exemplo, do ponto de vista das necessidades do meu projeto, ter acesso a dart_api.h mesmo sem garantia de estabilidade (como um recurso experimental por exemplo) já seria suficiente. Minha principal preocupação é mover grandes blobs de dados binários (imagens) do lado do Dart para o lado C e vice-versa, sem empacotar e, idealmente, copiar. Unity / Mono consegue isso .

Do dart-sdk issue 31960 , entendo que a implementação atual de isolados pode não permitir a passagem de dados sem cópia (embora em teoria deva ser possível detectar que o buffer criado no isolado A não é mais usado após ser passado para o isolado B e, portanto, sua propriedade pode ser transferida, sem copiar .. qualquer plano nessa frente?), mas se pelo menos dentro de um isolado não houver empacotamento de / para C , seria bom.

O Marshalling pode ser evitado com flatbuffers que parece estar chegando em breve: https://github.com/google/flatbuffers/pull/4676
Ou com mensagens protobuf usando um campo apenas de bytes únicos.

Claro, isso envolve grandes quantidades de cópia de bytes, portanto, não é ótimo para todos os casos de uso.

Estou ouvindo pelo menos três desejos diferentes apresentados aqui:

1. Gostaria de uma maneira de escrever facilmente um plugin para Flutter usando apenas código C / C ++ sem ter que adicionar um monte de cola Java / Obj-C (esse era meu entendimento original desse bug e algo que definitivamente acho que poderíamos / deveríamos fazer) .
2. Gostaria de uma maneira de mover grande volume de dados para dentro / fora do DART rapidamente / com baixa latência / etc. (Presumivelmente de uma variedade de linguagens, incluindo C ++. Este parece um caso muito válido! Eu recomendo fortemente o preenchimento de um bug separado incluindo um exemplo.)
3. Gostaria de uma maneira de estender o Dart com chamadas / objetos síncronos? (por exemplo, extensões nativas ou outros métodos? Isso também é totalmente viável. Existem possíveis dificuldades em torno da estabilidade da API e acho que gostaríamos de saber mais sobre o caso de uso específico antes de agirmos.)

Meu feedback da leitura acima é que devemos considerar a divisão de alguns bugs adicionais. Definitivamente, precisamos investir um pouco em torno da interoperabilidade C ++, mas é difícil determinar, a partir dessa longa discussão, quais casos de uso exatos devemos abordar e em que ordem?

As partes interessadas estariam dispostas / capazes de registrar novos bugs com seus casos de uso desejados e vinculá-los de volta aqui? Fico feliz em deixar este assunto em aberto para rastrear o interesse geral neste espaço problemático.

Com relação ao desempenho e 2. acima: Embora eu tenha certeza de que o desempenho de platform_channels do Flutter poderia ser melhorado (e que provavelmente precisaremos de outros métodos de plug-in / interoperação para cobrir todos os casos de uso), queremos alguns métodos concretos casos de uso (talvez eles existam e eu não os tenha visto?) em que o desempenho de platform_channels do Flutter é um gargalo antes de agirmos. Minha experiência com a otimização do desempenho de sistemas mostra que meus instintos costumam estar errados. Mesmo que coisas como JNI ou platform_channels pareçam gargalos potenciais, não saberemos de fato até medirmos.

Obrigado novamente a todos por sua ajuda e feedback!

Gostaria de uma maneira de escrever facilmente um plugin para Flutter usando apenas código C / C ++ sem ter que adicionar um monte de cola Java / Obj-C (esse era meu entendimento original desse bug e algo que definitivamente acho que poderíamos / deveríamos fazer) .

isso também daria melhor integração sqlite para flutter + existem toneladas de bibliotecas C / Rust para crypto, ssh e outras coisas. Seria legal poder usar isso facilmente.

@eseidel

Estou ouvindo pelo menos três desejos diferentes apresentados

Meu voto para 1.)

Com base na leitura da documentação do Flutter, deve ser bastante "simples" estender os canais da plataforma para oferecer suporte a C.
A única coisa nova provavelmente seria uma maneira de carregar _objetos compartilhados dinâmicos_ no processo atual.

Eu imagino que o uso de _Android-C_ se pareça com:

#include <ndk-version.h>
#include "methodchannel.h"
#include "methodchannels.h"

MethodChannel* flutter_channels;

__attribute__((constructor))
void
on_library_load() {
    flutter_channels = NULL;
}

__attribute__((destructor))
void
on_library_unload() {
    while (MethodChannel* channel = MethodChannels_pop(flutter_channels)) {
        MethodChannel_delete(channel);
    }
}

#define str(a) #a

void
{{pluginClass}}_on_method_call(MethodCall* call, Result* result) {
    if (strcmp("getPlatformVersion", call.method) == 0) {
        Result_success(result, "Android " str(__NDK_BUILD__));
    } else {
        Result_not_implemented();
    }
}

void
{{pluginClass}}_register_with(Registrar* registrar) {
    MethodChannel* channel = MethodChannel_new(Registrar_messenger(registrar), "{{projectName}}");
    flutter_channels = MethodChannels_push(flutter_channels, channel);
    MethodChannel_set_call_handler({{pluginClass}}_on_method_call)
}

Conceitualmente, pelo menos para _Android-C_, você teria que decidir como lidar com a combinação de Java e C.

@eseidelGoogle
Atualmente, expomos o código golang por meio dos wrappers Java e Swift e a latência é um problema apreciável que estamos enfrentando.
porque ?

• Precisamos compartilhar a lógica de negócios entre muitas plataformas.
• Para funcionalidade de vídeo e imagem, como compartilhamento de tela.
• Para DB.

Se você for capaz de adicionar suporte a golang no nível direto, isso faria uma grande diferença!
Compilar o código golang para dispositivos móveis também é muito fácil sem nenhuma mágica LDFLags, então eu acho que seria popular. Eu sei de alguns outros programadores golang que também estão usando os canais de método.
No que diz respeito à serialização, atualmente usamos Protobufs e flatbuffers.

Exemplo:
https://github.com/dnfield/flatbuffers/blob/master/samples/sample_binary.go

Em fúcsia, isso é feito com FIDL e tem ligações com c, ferrugem e golang.
É incrível de usar e tenho gostado de experimentar ferrugem e golang em uma placa embutida.

Deve ser possível expor o material fidl por meio de iOS e java também.
Isso daria um bom avanço entre fúcsia e vibração em celulares e desktops.
Só uma ideia com a qual estou brincando

@eseidelGoogle
Hiixe me disse que o FIDL não pode ser feito no nível Flutter porque o FIDL depende do código do kernel do zircão em fúcsia. Portanto, a única maneira de replicar a funcionalidade do estilo FIDL IPC no Flutter seria gravar uma versão FIDL no mecanismo do Flutter. Mas então eu estava brincando com ele e percebi que é bastante semelhante ao Flatbuffers. Então, por que não usar FlatBuffers para a camada de serialização entre o Flutter e o cpp ou golang ou camada de ferrugem no Flutter. ?

Apenas +1 sobre isso, temos um aplicativo flutter usando uma biblioteca chamada Superpowered. Superpowered é escrito em C ++, então usamos coisas do tipo java e JNI para interagir com ele, que por sua vez usamos canais de plataforma para conversar com o código Java. Certamente seria bom se pudéssemos ignorar o intermediário.

Além disso, impede que bibliotecas móveis populares como o Realm façam versões flutuantes porque seu núcleo é escrito em C / C ++ e eles também não querem lidar com um intermediário java / objc / swift.

Por essas razões, além da estabilidade geral, acho que esse problema é uma das mudanças mais necessárias na vibração no momento. (Mais especificamente, # 1 na lista do @eseidelGoogle .)

Se você quiser ouvir um argumento para contornar Java / JNI em extensões de plataforma (ou seja, não apenas ocultar / automatizar a camada de cola Java para o desenvolvedor), Superpowered tem muito a dizer sobre esse assunto: https://www.youtube. com / watch? v = LzIuir3r6Co

@pnico Você pode explicar como isso está argumentando que Java / JNI deve ser bipassed? Parece dizer pouco mais do que seu código de processamento de áudio deveria ser escrito em C ++. (O que não significa que você não pode chamá-lo através do JNI ou por qualquer outro meio)

@ csga5000 você está totalmente certo, isso não fazia sentido: D JNI provavelmente não afetará o desempenho de verdade, a menos que você esteja tentando fazer coisas mais esotéricas. Eu acho que realmente se resume a conveniência / facilidade de manutenção, e eu acho que talvez a capacidade de mover mais código específico de aplicativo de Java / C ++ para o Dart

Acho que @pnico está dizendo que PODE chamá-lo por meio do JINI, mas que o JINI adiciona muita latência.
Portanto, o desempenho é o problema.
sim não ??

Este pode fazer uma grande diferença principalmente para trabalhos relacionados à criptografia.

Também suponho que para o Android Things, embora não tenha visto ou feito experimentos
e benchmarks para gpio sensível ao tempo em nem c nem dardo por mais de a
ano.

No sábado, 9 de junho de 2018, 10:52 Eddy WM, [email protected] escreveu:

Este pode fazer uma grande diferença principalmente para trabalhos relacionados à criptografia.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/flutter/flutter/issues/7053#issuecomment-395927258 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AFHMcSI2JDHbgv3iYrStDN5mlzkQ8XEkks5t6xxMgaJpZM4K-PLw
.

Algum progresso desde então?

Até que esse problema seja resolvido, há uma recomendação para um exemplo de plug-in de flutter que mostra como integrar ac / c ++ lib? Djinni é um bom caminho a percorrer?

Até que seja resolvido, a única maneira de integrar c / c ++ escrevendo código android e ios nativo e, em seguida, fazer a interface com o código dart usando canais de plataforma

Implementei plug-ins que usam canais de plataforma (para arquivos jar e CocoaPods). Estou procurando um plugin de exemplo que mostra como integrar ao mesmo c / c ++ lib (para android e ios). Alguma recomendação?

@ mmcc007 É como você faz em java ou swift.

Java: https://www.google.com/search?client=opera&q=android+java+use+C%2B%2B&sourceid=opera&ie=UTF-8&oe=UTF-8

Swift: https://www.google.com/search?client=opera&q=swift+use+C%2B%2B&sourceid=opera&ie=UTF-8&oe=UTF-8

Você pode ver como o superpowered recomenda que você faça isso se realmente quiser um exemplo (é apenas um que eu conheço): https://github.com/superpoweredSDK/Low-Latency-Android-iOS-Linux-Windows-tvOS-macOS- Plataforma-Áudio-Interativa
Veja as pastas de exemplos. Por exemplo, em https://github.com/superpoweredSDK/Low-Latency-Android-iOS-Linux-Windows-tvOS-macOS-Interactive-Audio-Platform/tree/master/Examples_Android/SuperpoweredRecorder/app/src/main existe java / com / superpowered / recorder / MainActivity.java que faz referência ao código em cpp / RecorderExample.cpp

@ csga5000 Parece que seria razoavelmente direto .. na primeira análise. Ainda assim, seria bom olhar através de um plugin de flutter funcional. Obrigado.

1 para isso. Qualquer exemplo funcional de um aplicativo flutter usando c ++ seria bem recebido

Há um projeto que faz isso para Golang e acho que a mesma abordagem
pode ser usado para c ++ também.

O programa golang usa jsonrpc.
Então, tudo que você precisa fazer é confrontar seu próprio código golang com jsonrpc.

Então tudo é muito fácil.

Acho que os canais de plataforma SOMENTE suportam JSON como serialização agnóstica
formato?

Na quarta-feira, 18 de julho de 2018, 16:50 Jefferson Bledsoe, [email protected]
escreveu:

1 para isso. Qualquer exemplo funcional de um aplicativo flutter usando c ++ seria
bem recebido

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/flutter/flutter/issues/7053#issuecomment-405958345 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ATuCwkPbb9vLdoaEwM-bLhYPZxtyQ5Vjks5uH0sqgaJpZM4K-PLw
.

Olá, alguma novidade?

Só quero saber se alguém neste tópico conseguiu integrar a biblioteca Superpowered diretamente em um aplicativo flutter?

Sim @ habilidades-up que fizemos isso. Só não em um projeto de código aberto, então não posso mostrar. Mas se você ver minhas dicas antes, é assim que você faz. Você pode precisar construir seu aplicativo flutter para cada arquitetura de CPU, embora

Eu entendo que você fez via JNI / Java e não diretamente do DART. Eu queria saber se é possível evitar código específico de plataforma completamente.

Você pode precisar construir seu aplicativo flutter para cada arquitetura de CPU, embora

Você quer dizer um aplicativo separado para cada arquitetura ou apenas especificando todas as arquiteturas suportadas?

A propósito, já temos um aplicativo funcional escrito nativamente em Java. No entanto, agora que temos que criar um aplicativo iOS também, eu queria saber se criar um em flutter (em vez de gastar esforços em Swift / XCode) faria mais sentido do ponto de vista de manutenção futura, com o benefício de uma única base de código.

Nós vamos. O Realm está esperando que vocês forneçam uma maneira: https://github.com/realm/realm-object-server/issues/55

lukaspili: Acho que todo mundo ainda está esperando: flutter / flutter # 7053
bmunkholm: @lukaspili Sim, é um pré-requisito com certeza.

Pelo que vale a pena, estou esperando por isso também. Não é possível substituir os aplicativos XF por flutter idem até que vocês tenham o encanamento adequado. Como está atualmente, os golpes de Xamarin saem da água neste departamento.

Atrasado para esta festa, mas um grande +1 para este tópico.

Eu desenvolvo aplicativos de desktop, minha visão como uma linha de código (para desktop):

Flutter - Dart + C++ > Qt ? partyTime() : makeDoWithElectronOrQt()

Se o Flutter puder oferecer suporte de primeira classe para C ++, acho que sua abordagem geral pode ser uma vencedora absoluta para o desenvolvimento de aplicativos de plataforma cruzada, não apenas um "primeiro móvel", mas um primeiro no mundo. Qt é caro para pequenos desenvolvedores, é teimoso e não adota o C ++ moderno e nada realmente compete, o Flutter poderia comer pelo menos um pouco de sua torta de IU?

PS: Eu não sou anti-Dart, é outro novo C # / Go / Rust / etc. linguagem concorrente que pode ser superprodutiva para uma nova plataforma, mas o mundo dos aplicativos de desktop de alto desempenho (meu interesse aqui) é firmemente C ++, com amplo sistema operacional e suporte de biblioteca, uma linguagem que está avançando a uma taxa de nós (não é C), e acho que Flutter merece!

Eu não acho que o flutter suportará C ++ em nenhum momento no futuro próximo, e certamente não é possível agora. E eu prefiro tremendamente o Dart - escrever aplicativos em C ++ mesmo com flutter exigiria muito mais esforço. E eu não acho que C ++ se traduza diretamente para suporte a desktop, eles ainda teriam que escrever um pouco de código, e a VM dart deveria funcionar para desktop de qualquer maneira. Acho que o desempenho é insignificante para a maioria dos aplicativos.

Acho que, no final das contas, o Google quer oferecer suporte à interoperabilidade para que você possa escrever aplicativos flutter para qualquer e todas as plataformas usando qualquer linguagem suportada ou até mesmo uma combinação dessas linguagens. Mas eu não esperaria isso até quando ou depois do lançamento de Fuchsia. Por enquanto, seu objetivo é facilitar a escrita de código uma vez. O Dart corresponde a esse objetivo, pois é fácil de usar / aprender, eficiente e, de qualquer maneira, um dos idiomas do Google. Eu realmente não vejo quase nenhuma vantagem prática para o usuário médio em ter suporte de C ++ de primeira classe. O desempenho é insignificante em um aplicativo móvel e usar canais de plataforma com C ++ seria conveniente para o propósito de interagir com bibliotecas C ++ existentes. Pelo lado positivo, você pode ter certeza de que eles eventualmente pretendem usar a vibração para suportar a área de trabalho (bem, pelo menos a capivara da Fúcsia, mas duvido que parem por aí).

Este tópico é sobre o suporte à integração direta com C ++ de dart / flutter, que esperançosamente pode acontecer em um futuro próximo.

Eu não acho que o flutter irá suportar C ++
Eu realmente não vejo quase nenhuma vantagem prática para o usuário médio em ter suporte C ++ de primeira classe.

Não se trata de quão incrível Flutter / Dart é vs C ++, é mais sobre o ponto / facilidade de integrações que você precisa para se encaixar no ecossistema atual. Existe uma longa lista de bibliotecas como objetos compartilhados (OpenCV, para citar uma) que são o padrão da indústria, você não pode esperar que as pessoas as reescrevam no Dart?

O desempenho é insignificante em um aplicativo móvel e usar canais de plataforma com C ++ seria conveniente para o propósito de interagir com bibliotecas C ++ existentes.

Muito pelo contrário, usar canais é subótimo neste contexto, pense em casos de uso em que você precisa trabalhar com um grande objeto binário na memória (imagens), você precisaria:
1- Copie esses binários de / para a memória C ++
2- Trabalhar com JNI para fazer interface com a biblioteca (e lidar com ponteiros alocados dinamicamente para esses binários)
sem mencionar a sobrecarga de serializar / desserializar valores / parâmetros de custo que você incorre ao usar os canais.

Uma boa estrutura é um equilíbrio entre os novos recursos / paradigmas que apresenta e a facilidade de integração com o ecossistema / legado atual, do qual não podemos negar que o C ++ faz parte.

@nhachicha @ csga5000 não discordava da importância de integrar C ++ diretamente; ele estava respondendo a um comentário anterior perguntando se o Flutter poderia ser usado diretamente do C ++ , como em, sem a necessidade de nenhum código Dart.

O desempenho é insignificante em um aplicativo móvel e usar canais de plataforma com C ++ seria conveniente para o propósito de interagir com bibliotecas C ++ existentes.
@nhachicha Eu não poderia concordar mais.

A verdade é para aplicativos que não precisam de desempenho dentário (que são muitos), então por que não trocar o difícil de dominar C ++ por algo mais produtivo, na verdade, por que parar apenas no Dart, por que não encaixar em qualquer um desses super populares, ( muitas linguagens mais populares / estabelecidas do que Dart):

• Tempo de execução C # /. Net Core
• Tempo de execução Javascript / Typescript V8 (você quase teria um navegador nesse ponto, mas e daí)
• Ferrugem (também rápido!)
• GoLang
• Pitão
• [Insira o seu favorito aqui] ...

E por mais que eu pessoalmente ame e use algumas dessas linguagens todos os dias, C e C ++ estão no centro do Linux, portanto, Android, iOS e plataformas de desktop como Windows, MacOS e outros desktops. Metade das linguagens acima (incluindo Dart) são escritas em C ++. As tecnologias de ponta sempre exigem desempenho nativo ajustado, como AI (Tensorflow é C ++, Caffe C ++, Pytorch é C em Python, etc.), bibliotecas de realidade aumentada, motores de jogo AAA e qualquer coisa que precise chegar perto de uma GPU (CUDA , chamado de C / C ++).

Pelo mesmo motivo que o motor de renderização Flutter é escrito em C ++ (nativo, alto desempenho, bateria / memória / cpu eficiente), acho que seria ótimo desbloquear o melhor desempenho possível, quando necessário, sem chegar perto de um tempo de execução gerenciado e simplesmente suportando C ++. Isso separaria o Flutter de outros frameworks como Xamarin e Nativescript, que honestamente oferecem uma experiência de desenvolvimento semelhante (tendo usado ambos), apenas com linguagens diferentes. Por que não tornar o flutter especial em vez de apenas "o Dart"?

_Como uma observação lateral, estou totalmente à vontade para escrever tudo em C / C ++, desde a validação de formulário até pixel shaders, mas não estou fingindo que é a opinião de muitas pessoas olhando para este repo - e isso porque acho C ++ a linguagem altamente produtiva - no entanto, uma escolha totalmente pessoal._

Este é um dos principais motivos pelos quais precisamos da integração com C ++

https://github.com/realm/realm-object-server/issues/55

Existem duas maneiras simples de fazer a integração C / C ++:

• Fornece implementação de canal de método em C ++
• Fornece suporte de extensão nativa Dart VM

Infelizmente, ambos têm grandes desvantagens que nos impedem de persegui-los:

• Os canais de método são abstração de alta sobrecarga - enquanto a integração C / C ++ é solicitada quando as interações de baixa sobrecarga são desejáveis. O que significa que os canais de método não resolveriam realmente o problema.
• As extensões nativas do Dart VM exigem que as pessoas usem a API C do Dart VM - pode não ser desejável introduzir muitas dependências externas nisso, especialmente considerando o fato de que a API não envelheceu bem e requer algumas refatorações sérias.

Parece que uma alternativa mais desejável é a introdução de dart:ffi - um componente central do Dart VM que permitiria vincular diretamente ao código nativo, permitindo que as pessoas escrevessem algo como:

import 'dart:ffi' as ffi;

// Bind foo to symbol _foo from library libxyz.so with signature
// int32_t (int32_t, double, char*).
@ffi.import("libxyz.so", name: '_foo',
            signature: ffi.Signature(ffi.Int32, [ffi.Int32, ffi.Double, ffi.PChar]))
extern int foo(int foo, double x, String foo);

Há muito tempo que tínhamos certo interesse em implementar um FFI como esse - eu esperava que experimentássemos isso em algum momento no futuro próximo, mas não me comprometeria com nenhum cronograma concreto.

@ kirbyfan64 é exatamente certo, @nailgilaziev, @bytesoftly eu não estou tentando dizer C ++ não é necessária a integração, eu estava apenas dizendo que eu não acho que há muito motivo / demanda para fazer INPLACE vibração suporte C ++ de dardo - mas Não estou dizendo que a integração não seja necessária. O que @mraleph está dizendo parece inteligente para mim.

@mraleph O Dartino tinha uma implementação semelhante para FFI . Quão difícil é ressuscitar?

@listepo partes dele. A implementação de FFI do Dartino foi muito dinâmica - isso não é algo que queremos para o Dart 2, que é consideravelmente mais estático do que o Dart 1.

Atrasado no jogo, mas aqui está outro caso de uso: Gostaríamos de incluir arquivos c e métodos no dart para fins criptográficos.

O que esperamos é o seguinte:
1) Código idêntico para iOS e Android, ou seja, sem passar pelas camadas ObjC ou JNI.
2) Esperançosamente, uma implementação mais eficiente do que passar, por exemplo, pelo JNI duas vezes.
3) Possibilidade de reutilizar o código do modelo DART em um aplicativo da Web de acompanhamento, por exemplo, no AngularDart, ou aplicativos de desktop de acompanhamento usando este projeto: https://github.com/google/flutter-desktop-embedding

Acredito que o que desejamos está mais próximo do ponto 2 @eseidelGoogle mencionado acima. Quanto ao suporte síncrono, considero "bom ter", uma vez que funções assíncronas não podem ser usadas em um construtor, onde se pode querer realizar, por exemplo, um cálculo de hash rápido. Mas para se acostumar com o modo assíncrono do Darts, o suporte síncrono parece menos importante do que a possibilidade geral de atingir os pontos 1) -3) acima.

Usando FFI conforme sugerido por @mraleph , isso permitiria 1) -3) como em meu comentário anterior, ou significaria que códigos diferentes são necessários em plataformas diferentes (Android, iOS, ...)?

@CryptUser se o seu código C / C ++ for o mesmo em todas as plataformas, o código Dart para chamá-lo via FFI também será o mesmo em todas as plataformas.

@mraleph Parece ótimo! Considerando que a edição original tem mais de 200 polegares para cima, há alguma chance de aumentar a prioridade sobre isso?

@mraleph existe um problema em aberto para a FFI no Dart em algum lugar?

@dnfield Eu preenchi um agora há pouco https://github.com/dart-lang/sdk/issues/34452

Eu adoraria ser capaz de escrever código C / C ++ / Rust e usá-lo em ffi

Exemplo:

Eu testo vibração no tablet Android (Android 4.4).
vibração correr rapidamente.
Mas quando tento ler 1000 linhas com sqflite que usam o canal da plataforma, é ridículo lento.
o motivo: não consigo usar o leitor de cursor sqlite.

mas se eu pudesse usar diretamente a biblioteca sqlite, a mesma consulta seria instantânea. (testado com xamarin e projeto android nativo).

Estamos discutindo agora a melhor maneira de abordar isso. Conforme observado acima em https://github.com/flutter/flutter/issues/7053#issuecomment-377711814, esse problema tem muitas partes e provavelmente precisa ser dividido. :)

Mas encontramos alguns engenheiros interessados ​​em explorar um FFI (conforme observado em https://github.com/flutter/flutter/issues/7053#issuecomment-415161464). Nosso foco agora é fazer com que o 1.0 seja lançado, mas uma vez que isso seja feito, isso estará no topo da lista. Obrigado novamente por todos os seus comentários contínuos. Atualizaremos esse problema quando tivermos mais progresso para compartilhar.

Também sou usuário Matlab / Simulink. Posso gerar código c / cpp específico de cpu altamente otimizado. Quero integrar meu algoritmo à vibração. Eu tenho muitos algoritmos de processamento de imagem. Preciso de um gerador de ligação para códigos nativos. Do contrário, esquecerei todas as minhas experiências com os dardos e começarei a aprender xamarin ou algo que me sirva.

Podemos acelerar o progresso?

É uma dor enorme interoperar entre Dart e C.

Apressar o processo provavelmente não resultará em um produto de boa qualidade. Estará pronto quando estiver pronto. :-)

Apressar o processo provavelmente não resultará em um produto de boa qualidade. Estará pronto quando estiver pronto. :-)

Bem, o que tentei dizer é que podemos querer aumentar a prioridade para que possamos colocar mais recursos e esforços para resolver isso. Você sabe que há 1386 questões em aberto no momento visando a "Meta", que será "consertada nos próximos anos".

Depois de ler o tópico mais uma vez, percebi que @eseidelGoogle disse que isso terá maior prioridade depois que o Flutter 1.0 estiver pronto. Acho que atendeu bem à minha preocupação.

"Meta" pode ser o balde errado. :) @mraleph tem alguém explorando https://github.com/dart-lang/sdk/issues/34452 enquanto conversamos. Isso é parte de uma solução, pelo menos.

Aqui está o documento de visão para o FFI que estamos prototipando no lado do Dart.

Por favor, dê uma olhada e diga-nos o que você pensa.

Não posso falar muito sobre a parte FFI porque nunca usei algo assim,
mas estou me perguntando como será a integração do pub.

Como seriam tratados os pacotes de publicação que fazem uso da FFI?
Como o consumo de pacotes que usam FFI seria tratado?

@zoechi , não discutimos a integração de pub ainda.

Eles devem ser capazes de funcionar de forma semelhante aos plug-ins Flutter atuais - incluem fontes e / ou binários apropriados para a plataforma / arquitetura que podem ser compilados / vinculados ao aplicativo de consumo.

Do ponto de vista de um pub, não deve ser um grande problema - exceto que pode haver arquivos binários maiores incluídos no pacote.

Seria necessário algum trabalho em torno das ferramentas do Flutter para integrá-los aos projetos do Flutter - eles não funcionariam exatamente da mesma forma que os plug-ins Android / iOS funcionam hoje.

A integração pub deve ser movida para uma questão dart-lang / pub para mantê-la mais focada?

Eu li 'visão doc' e finalmente vejo formas através da névoa.

Nesse ínterim, eu estava pensando em algo muito diferente.

Ou seja, de (re) usar Flatbuffers para fazer algo como NativeChannels. No momento da execução (AOT), isso se resumiria à passagem de ponteiro, enquanto que no momento do desenvolvimento, isso me permitiria aproveitar as ferramentas existentes para o lado "nativo" escrito não apenas em C / C ++, mas também escrito em Go ou Rust.

A abordagem de transmissão de mensagens também está mais alinhada com as arquiteturas baseadas em fluxo atuais (Bloc, Rx). Isso elimina qualquer preocupação com o gerenciamento de memória também, pois o compilador pode gerar buffers de anel adequados quando apropriado ou presumir 'liberações de callee' simples onde um callee precisa reter os dados por mais tempo.

Mas, para ser honesto, aplaudirei qualquer forma de ffi se for perfeitamente integrado ao ecossistema Flutter (Fuchsia) e deixe-me usar o código nativo otimizado por CPU de dentro do aplicativo Dart.

@ohir o que você imaginou seria outra solução para alguns dos problemas apresentados bug. Este bug evoluiu para um "catch-all" de propósito geral para qualquer coisa relacionada ao C ++. : / Suspeito (como observei em comentários anteriores) que precisamos dividir esse bug em outros menores. O trabalho da FFI pode não ser a única solução que construímos neste espaço.

@eseidelGoogle algum progresso nisso? agora temos um projeto que precisa implementar tarefas pesadas de processamento de vídeo que podem ser feitas via ffmpeg, uma vez que o pacote dart atual não pode fornecer uma solução viável, estamos esperando ansiosamente que flutter chame ffmpeg lib diretamente.

Para aqueles aplicativos baseados em interface de usuário página a página, agora eu acho que é uma boa escolha do que virar para o trabalho de codificação dupla no Android e iOS, se estivéssemos 5 anos atrás com um equipamento tão adorável, toda a indústria de aplicativos poderia ser alterado. No entanto, as vantagens do flutter agora não são tão empolgantes para as empresas que estão migrando para ele, porque elas já tinham se saído bem com o método antigo, mas para algumas tarefas não relacionadas à IU, o dart está muito aquém do requisito principal.

não significa que o dardo não seja bom nem viável para essas tarefas um dia, mas na visão de uma empresa de TI normal que pode ser incluída no ecossistema flutuante, o que eles precisam é reduzir o custo usando uma cruz método de codificação de plataforma somente se os recursos mais interessantes pudessem ser alcançados, como processamento de dados do lado do cliente, vídeo / áudio, equipe de AR, etc., desde que algum algoritmo já feito via c / c ++. é realmente difícil para eles reimplementá-lo ou reinventá-lo usando a linguagem do dardo.

e a solução principal é apresentar a maneira direta e eficiente para flutter se comunicar com c ++, eu até acho que isso é a primeira prioridade de uma "plataforma cruzada", dardo para a equipe de interface do usuário é perfeito, alguma lógica de dados normal também pode ser feito em dardo, mas é muito melhor para flutter se fundir no longo, mas ainda ativo e eficiente eco-sistema c ++ em vez de reconstruir um novo e sagrado!

o sonho de uma experiência real de codificação de "plataforma cruzada" é a equipe de IU do dart com c ++ por trás do capô, nenhum código java, nenhum código oc. wahaha, mal posso esperar para ver isso acontecer!

@smellbee Você não pode usar a linha de comando ffmpeg?

@smellbee , acho que não sou a pessoa certa para responder a isso. @eseidelGoogle alguma notícia sobre isso?

@smellbee Você não pode usar a linha de comando ffmpeg?

é um trabalho do lado do cliente, usando ffmpeg lib para renderizar quadros de vídeo para produzir fluxo de retorno instantâneo, é possível usar linha de comando?

@smellbee , acho que não sou a pessoa certa para responder a isso. @eseidelGoogle alguma notícia sobre isso?

desculpe por isso, digitei "es" e ele foi concluído automaticamente, não percebi ... espero que @eseidelGoogle possa ver

O trabalho está em andamento no lado do Dart - esperamos ter algo pronto no primeiro trimestre de 2019.

É um grande recurso e gostaríamos de acertar: como queremos que funcione bem em diferentes modos de execução para o Dart, por favor, tenha paciência conosco enquanto resolvemos os detalhes.

Você pode seguir dart-lang / sdk # 34452 que rastreia o trabalho do lado do Dart.

O Dart FFI permitirá chamar funções C do Dart.
Mas e os recursos do C ++ - classes, contêineres std, ponteiros inteligentes, exceções?
Podemos esperar a possibilidade de exportar classes C ++ para o Dart com um mínimo de clichê?

Outro recurso bastante importante é o suporte assíncrono - a capacidade de executar código C ++ em um thread separado e retornar Future / Stream de métodos.

@ t-artikov Não há planos atuais para suportar diretamente a interoperabilidade C ++. Isso é muito complicado. A única coisa que pode interoperar ergonomicamente com C ++ é C ++.

Se estiver interessado em interoperabilidade de alto nível com C ++, você precisará construir sua própria camada de interoperabilidade que expõe sua API C ++ por meio de API semelhante a C.

Outro recurso bastante importante é o suporte assíncrono - a capacidade de executar código C ++ em um thread separado e retornar Future / Stream de métodos.

Acho que isso pode ser construído como um pacote. Devemos apenas garantir que fornecemos primitivas corretas para que isso possa ser construído.

O Dart FFI permitirá chamar funções C do Dart.
Mas e os recursos do C ++ - classes, contêineres std, ponteiros inteligentes, exceções?
Podemos esperar a possibilidade de exportar classes C ++ para o Dart com um mínimo de clichê?

Contanto que haja uma maneira de C ++ chamar o dardo ， Eu acho que essas coisas são possíveis ， C ++ cuida do que o C ++ se preocupa ， e se comunica com o dardo sendo chamado ou chamando, sem necessidade de expor qualquer manipulação de baixo nível para dardo que irá destruir a facilidade de uso do dardo.

Outro recurso bastante importante é o suporte assíncrono - a capacidade de executar código C ++ em um thread separado e retornar Future / Stream de métodos.

E o dart já tem seu mecanismo assíncrono, então, se um thread é orientado para C ++ ou não, não faz diferença, contanto que a parte C ++ possa chamar o dart sempre que necessário, e um "Isolate" pode fazer o trabalho.

Isso é o que eu penso @mraleph , corrija-me se eu estiver errado;)

@mraleph
Na verdade, existem exemplos de excelente interoperabilidade do C ++ com outras linguagens.
https://github.com/boostorg/python
https://github.com/ThePhD/sol2
https://github.com/dropbox/djinni
Espero que o Dart / Flutter forneça um mecanismo semelhante fora da caixa.

Se estiver interessado em interoperabilidade de alto nível com C ++, você precisará construir sua própria camada de interoperabilidade que expõe sua API C ++ por meio de API semelhante a C.

Para deixar claro como essa abordagem é aplicável, você poderia demonstrá-la usando as seguintes classes С ++ como exemplo:

struct MyObject
{
    std::string name;
    std::vector<int> data;
};

class MyService
{
    // Can throw std::exception
    std::shared_ptr<MyObject> createObject(std::string name, std::vector<int> data);
};

Para que possa ser usado a partir do Dart

var service = MyService();
var object = service.createObject("foo", [1, 2, 3]);
assert(object.name == "foo");
assert(object.data[0] == 1);

@ t-artikov tanto boostorg::python quanto sol2 ilustram muito bem meu ponto de vista. Observe que se trata de bibliotecas C ++ para interoperar com outras linguagens, não o contrário. O Dart FFI é uma forma centrada em Dart de chamar APIs C, não uma forma centralizada em C ++ de chamar Dart.

Para deixar claro como essa abordagem é aplicável, você poderia demonstrá-la usando as seguintes classes С ++ como exemplo:

Você teria que escrever (ou gerar por alguma ferramenta) algo assim.

// To be compiled together with your code.
typedef std::shared_ptr<MyObject>* MyObjectPtr;

MyService* MyService_create() {
  return new MyService();
}

void MyService_destroy(MyService* ptr) {
  delete ptr;
}

MyObjectPtr MyService_createObject(MyService* ptr, const char* name, int* data, size_t size) {
  try {
    return new std::shared_ptr<MyObject>(createObject());
  } catch (...) {
    return nullptr;
  }
}

const char* MyObject_getName(MyObjectPtr obj) {
  return (*obj)->name.c_str();
}

int* MyObject_data(MyObjectPtr obj) {
  return (*obj)->data.data();
} 

void MyObject_destroy(MyObjectPtr obj) {
  delete obj;
}

// To be included on the Dart side.
@ffi.External()
external Pointer<Void> MyService_create();
@ffi.External()
external void MyService_destroy(Pointer<Void> ptr);
@ffi.External<Pointer<Void> Function(Pointer<Void>, Pointer<Void>, Pointer<Void>, Int32)>()
external Pointer<Void> MyService_createObject(Pointer<Void> service, String name, Int32List data, int size);
@ffi.External()
external String MyObject_getName(Pointer<Void> obj);
@ffi.External()
external Pointer<Int32> MyObject_data(Pointer<Void> obj);
@ffi.External()
external void MyObject_destroy(Pointer<Void> ptr);

class MyService {
  final Pointer<Void> _impl;
  MyService() : _impl = ffi.anchor(MyService_create(), MyService_destroy);

  MyObject create(String name, List<int> values) {
    final Int32List data = Int32List.fromList(values);
    return MyObject._(MyService_createObject(_impl, name, data, data.length));
  }

  static _destroy(Pointer<Void> ptr) {
    return MyService_destroy(ptr);
  }
}

class MyObject {
  final Pointer<Void> _impl;

  MyObject._(Pointer<Void> impl) : _impl = anchor(impl, MyObject.destroy);

  String get name => MyObject_getName(_impl);
  Int32List data => MyObject_data(_impl).as<Int32List>();

  static void destroy(Pointer<Void> ptr) { MyObject_destroy(ptr); }
}

Observe que se trata de bibliotecas C ++ para interoperar com outras linguagens, não o contrário.

Você está enganado, eles permitem expor classes C ++ a outras linguagens.
https://www.boost.org/doc/libs/1_68_0/libs/python/doc/html/tutorial/tutorial/exposing.html

Obrigado pelo seu exemplo Dart FFI.
Existem algumas falhas: a exceção C ++ deve ser passada para o lado do Dart; e o MyObject.data não funcionará desta forma (ele obtém apenas o ponteiro, mas não o tamanho dos dados).
Mas a ideia é clara.

Em minha opinião, esse código é muito prolixo para ser escrito manualmente.
Estou ansioso para ver se este processo será automatizado para as novas ligações do Dart FFI Flutter Engine.

A vinculação em tempo de execução para interoperabilidade C ++ é quase impossível (como você lida com genéricos, herança múltipla, sobrecargas de operador, nomes mutilados, etc ...). Houve muitas tentativas difíceis (BridJ, CppSharp, etc) e, no meu entendimento, as pessoas consideram a interoperabilidade C como a opção mais viável.

É improvável que haja uma solução muito genérica que os desenvolvedores oficiais de interoperabilidade possam alcançar para C ++. Kotlin / Native não oferece isso. iether nativo de scala. .NET também (a interoperabilidade Microsoft C ++ é sempre estranha ou estática). JNI oferece suporte à interoperabilidade C ++ apenas quando a compilação estática está envolvida. Algo como python boost glue precisa ser escrito manualmente. Qualquer grupo de terceiros pode desenvolver coisas como JNAerator (ou seja, VOCÊ pode fazer isso, não há necessidade de esperar que as equipes do Dart / Flutter consigam isso).

Seguindo essa conversa sem uma resposta real, acho que vou me ater ao Qt, que é Cross-Plattform e tem suporte total para C ++. Eu estava pensando em dar uma chance ao Flutter para meu próximo projeto, mas agora não vou, muito obrigado!

Poderia ter sido melhor se flutter tivesse sido escrito em C ++, com o qual a interoperabilidade com qualquer outra linguagem seria facilmente possível. Existe alguma tentativa de reescrever flutter em C ++?

Acho que a discussão está ficando desnecessariamente esticada agora.

Nós sabemos o que está (ou não) no roteiro de desenvolvimento de flutter.
Assim, podemos decidir usá-lo (ou não) para casos de uso específicos.

Não vejo nenhuma utilidade em tentar mudar a agenda de desenvolvimento, ou
exigindo implementação arquitetônica específica, além deste ponto.

Obrigado,
Gaurav

Na segunda-feira, 25 de fevereiro de 2019, às 22h51 bhauj, [email protected] escreveu:

Poderia ter sido melhor se flutter tivesse sido escrito em C ++, com
que interoperar com qualquer outro idioma teria sido facilmente possível. É
alguma tentativa de reescrever flutter em C ++?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/flutter/flutter/issues/7053#issuecomment-467098455 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AZ86acDpZgNeyezx40uxe_c5E2xZHWxaks5vRBumgaJpZM4K-PLw
.

Na verdade Flutter é como eu sei escrito em C ++ mas para programação em Flutter só pode ser feito com o interpretador Language Dart que roda em uma VM. Mas você ainda não tem nenhuma chance de passar do Dart para a parte C ++ do Flutter ...

Então, quem quer que leia isso e tenha o caso de uso comum em Appdevelopment de bom Cross-Platform Development, Flutter não permitirá o uso direto de C ++ se você precisar, então use outro Cross-Platform Framework como Qt C ++.

Para mim, C ++ é essencial para Cross-Plattform-Development porque é o menor denominador comum em quase todas as tecnologias.

@aqmappdesigners

intérprete Language Dart que é executado em uma VM

Isso não é preciso.

O Flutter usa o Dart VM no modo de depuração, o que também possibilita o hot-reload.
Em versões de lançamento, o Dart é compilado em código binário como C ++.

@zoechi Obrigado, eu não sabia disso. Isso soa bem para o desempenho

Isso soa bem para o desempenho

e é um requisito para a App Store da Apple.

O protótipo dart:ffi progrediu até o ponto em que estamos decidindo sobre as decisões de API. (Algumas decisões de design são discutidas aqui .)

Para tomar decisões de design informadas, gostaríamos de mais exemplos sobre quais APIs C você gostaria de vincular. Até agora, este problema menciona SQLite, Realm, OpenCV, Superpowered e ffmpeg. Quaisquer outras APIs que devemos considerar?

@dcharkes Não sei se ajuda, mas o Telegram no Android faz networking em C ++ via JNI:
https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/jni/TgNetWrapper.cpp
Ele também lida com a reprodução de GIF com ffmpeg, gravando diretamente em bitmaps Android:
https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/jni/gifvideo.cpp

Pode ser interessante ter uma maneira de analisar telefones e endereços por meio de libphonenumber e libpostal para formulários de registro. Também glfw + flutter-embedder e talvez um dia veremos um aplicativo de desktop inteiramente escrito em dardo.

1 para SQLite e Realm. Observe também o Couchbase , eles têm um núcleo C ++ comum com um C SDK.

As apis C ++ do Firebase seriam interessantes? https://firebase.google.com/docs/reference/cpp/

Não olhei muito para isso, mas estava pensando que poderia substituir os plug-ins iOS e Android por um único plug-in que se comunica diretamente com C ++.

Algumas bibliotecas de criptografia devem receber um pouco de amor como o anel da ferrugem - https://github.com/briansmith/ring

+1 para OpenCV, Realm, SqlCipher (https://github.com/sqlcipher/sqlcipher)

bibliotecas de criptografia. Particularmente libsodium ou tink.

https://github.com/google/tink

https://libsodium.gitbook.io/doc/

Já existe uma biblioteca de flutter-sodium, que se comunica por meio de canais de plataforma para invólucros libsodium em cada plataforma e depois para nativos.

Bibliotecas de mapeamento personalizado, como mapbox-gl https://github.com/mapbox/mapbox-gl-native

O tratamento de SMTP / IMAP (para bate-papo por e-mail) para Flutter via https://github.com/deltachat/deltachat-core é algo que eu adoraria usar diretamente.

Se me permite a ousadia de parafrasear, os casos de uso comuns são os seguintes:

1. Acesso de hardware de áudio / vídeo de baixa latência (como Superpowered)
2. Processamento de a / v assistido por hardware (como ffmpeg)
3. Acesso de soquete baseado em TCP, para XMPP / outros protocolos orientados a rede
   (para bate-papo, notificações push)
4. Upgrades de nível de processo (acesso root) / spawning threads em
   maneira compatível com plataforma cruzada (para aplicativos de sistema, multitarefa, emuladores)

Pode haver mais casos de uso, mas esses são os principais que vêm ao meu
mente.

Obrigado a todos por fornecerem exemplos! Isso é muito útil.

@ skills-up note que estamos muito mais interessados ​​em exemplos concretos do que em classificações abstratas. Isso porque queremos avaliar a ergonomia da FFI em exemplos concretos.

Estranhamente, uma das linguagens que oferece a melhor interface de / para C ++ é o Rust, por meio de seu poderoso sistema de macro + build, apesar de ter uma abordagem completamente diferente para OO.

Eu diria OpenSSL, já que precisamos assinar digitalmente solicitações de sabão e arquivos xml (XMLDSig, Xades l) usando certificados de cliente.
O próprio Dart tem BoringSSL, mas apenas parte dele é exposta através do Dart. Então, a próxima melhor coisa é chamar libs openssl nativas do flutter

Espero não estar enviando spam, mas também gostaria de ter uma integração melhor com o tensorflow lite, sem passar pelo JNI, isso seria ótimo para operações de vídeo

Não olhei muito para isso, mas estava pensando que poderia ser capaz de substituir os plug-ins iOS e Android> por um único plug-in que se comunica diretamente com C ++.

Além de suportar C ++, será incrível se houver um plugin que pode se comunicar diretamente com o Go. No momento, estamos falando com os canais da plataforma Go through gomobile e flutter, que retarda a capacidade de resposta da IU. Ter suporte nativo de Go e C ++ no Flutter também nos ajudará a manter uma base de código uniforme (lógica de negócios / algoritmo) para várias plataformas.

+1 para acesso à biblioteca nativa.

Eu gostaria de acessar Vulkan / MoltenVK sem ter que criar canais de plataforma para Android / iOS e manter dois plug-ins (que seriam enormes também). Isso permitiria construir aplicativos 3D e renderizar em um widget de textura, enquanto desenvolvia apenas no Dart. Os canais da plataforma parecem apenas uma solução alternativa. Prefiro acessar bibliotecas nativas sem ter que escrever um wrapper para cada plataforma e mantê-las sempre que houver uma nova versão para essa biblioteca.
Acho que esse recurso atrairia muito mais desenvolvedores.

Sim, plz acesso direto à biblioteca nativa do flutter.
Eu gostaria de usar alguma biblioteca c ++ no flutter.

Sim, plz acesso direto à biblioteca nativa do flutter.
Eu gostaria de usar alguma biblioteca c ++ no flutter.

Estamos agora em um ponto em que gostaríamos de oferecer uma prévia para obter algum feedback.

Para obter detalhes, consulte a atualização no bug de rastreamento do Dart .

@ mit-mit Isso ajudará com este problema: posso chamar ou usar a biblioteca Python com flutter ?

Atrasado para a festa, mas +1 para SQLCipher @dcharkes @mraleph

@ doc-rj, estamos agora no estágio em que você deve ser capaz de experimentar vincular SQLCipher e nos fornecer feedback sobre sua experiência. Veja este comentário .

Eu gostaria de enfatizar que não estamos realmente com o objetivo de fornecer quaisquer associações de biblioteca específicas - porque as solicitações são extremamente diversas, mas nosso objetivo é tornar possível que todos e qualquer pessoa se associem a qualquer biblioteca com uma API C.

Acho que a necessidade disso aumenta agora que a multiplataforma foi anunciada.

Isso faz parte de algum roteiro?

@felemedeiros o trabalho está em andamento - se você tem uma biblioteca que deseja vincular usando FFI, sugiro fortemente que comece a trabalhar nas ligações para nos fornecer feedback. Veja este comentário para mais informações.

Não olhei muito para isso, mas estava pensando que poderia ser capaz de substituir os plug-ins iOS e Android> por um único plug-in que se comunica diretamente com C ++.

Além de suportar C ++, será incrível se houver um plugin que pode se comunicar diretamente com o Go. No momento, estamos falando com os canais da plataforma Go through gomobile e flutter, que retarda a capacidade de resposta da IU. Ter suporte nativo de Go e C ++ no Flutter também nos ajudará a manter uma base de código uniforme (lógica de negócios / algoritmo) para várias plataformas.

Escrevi um artigo sobre como estamos atualmente chamando a API da biblioteca Go do Flutter. Pode ser útil para alguém interessado. https://medium.com/@archan.paul/using -go-library-in-flutter-a04e3496aa05

Como posso adicionar código c ++ no aplicativo Flutter?

Como posso adicionar código c ++ no aplicativo Flutter?

Eu acho que agora a única opção é usar C ++ -> JNI (para Android) -> PlatformChannel até que tenhamos uma maneira mais elegante de fazer o mesmo !!

Criei um projeto chamado ezored (http://ezored.com). Seria bom se eu pudesse passar objetos complexos para Flutter sem precisar converter para outra coisa, uma vez que já está em java e objc. Qualquer um pode usar o ezored para gerar o SDK (ou fazer o download pré-construído) para testar a integração do Flutter entre o nativo e o Dart. Ele tem solicitações, análise, crud usando banco de dados e muitas outras coisas no SDK de demonstração já implementado.

Eu procuro em grupos de flutter, mas não tenho como passar os objetos e a lista de objetos para o Flutter direto.

Obrigado em qualquer ajuda.

Algum novo progresso? Parece que se passaram mais de 2,5 anos ...

@fzyzcjy , estamos trabalhando nisso. Lançamos uma prévia. Consulte https://github.com/dart-lang/sdk/issues/34452#issuecomment -482136759 para saber como se envolver.

Desde esta prévia, adicionamos suporte para Intel 32, Arm 64 e Arm 32. Essas plataformas ainda não foram lançadas na stable ou dev, elas só estão disponíveis no branch master do Dart sdk. O progresso está sendo monitorado aqui .

@dcharkes Fico feliz em ouvir isso! Obrigado pelo seu excelente trabalho!

Algum progresso?

Para atualizações de status e informações adicionais, consulte https://github.com/dart-lang/sdk/issues/34452. O principal comentário ali contém a atualização mais recente.

Ao usar o flutter para criar um aplicativo da web, será possível usar ffi com a biblioteca ac?

Ao usar o flutter para criar um aplicativo da web, será possível usar ffi com a biblioteca ac?

Isso não é provável. Teoricamente, a longo prazo, ele poderia ser suportado usando WebAssembly, mas isso não é algo em que estamos trabalhando atualmente.

@ com-com realmente？

Ao usar o flutter para criar um aplicativo da web, será possível usar ffi com a biblioteca ac?

Isso não é provável. Teoricamente, a longo prazo, ele poderia ser suportado usando WebAssembly, mas isso não é algo em que estamos trabalhando atualmente.

Por que exigiria WebAssembly? Se você pode pedir às pessoas que reconstruam para WebAssembly no futuro, você pode pedir que reconstruam para ASM.js agora.

@ nic-hartley É uma boa ideia, mas o desafio não é como compilar o código nativo, é criar a ponte entre o Dart (compilado como JS) e o código nativo, seja qual for a forma que ele assuma.

O FFI nativo é de nível muito baixo por motivos de desempenho e não pode ser facilmente traduzido para asm.js ou WebAssembly.

Para esclarecer, quero dizer que nossa implementação é de nível muito baixo - certamente é um recurso interessante, mas exigiria um trabalho considerável para ser entregue.

vibração é apenas um brinquedo até que suporte c ++

Eu vim aqui para repetir os mesmos pontos de outros, que até que o Flutter possa interoperar facilmente com C ++ (sem biblioteca de ponte e sem penalidade de desempenho), ele nunca será adotado por aplicativos de grande escala com investimentos em bibliotecas nativas existentes ou aplicativos onde o desempenho é a prioridade mais alta.

Notarei que até mesmo o React Native usa uma ponte atualmente, então parece que o Flutter está realmente à frente da curva em termos de tentar implementar um FFI.

A integração com C ++ é trivial no iOS com AppKit. Isso é o que devemos comparar, não React Native.

UWP e C ++ também são triviais.

No entanto, eu sou, em geral, da festa de "apoiar o esforço da FFI do DART" ...

Xamarin pode ser uma comparação mais apropriada do que UWP, mas as visualizações de plataforma cruzada do Xamarin não eram tão personalizáveis ​​quanto as do Flutter e frequentemente exigiam muito código nativo para ter uma aparência decente.

Isso não é verdade. Ao contrário do Flutter, o Xamarin tem vínculos de plataforma com a API nativa (ou seja, Xamarin.iOS e Xamarin.Android) e é fácil para os desenvolvedores de aplicativos escreverem implementações específicas da plataforma em sua própria linguagem (C # /. NET). Esse problema é sobre o recurso de linguagem e não deve ser misturado com o design da API do widget de IU.

Há muitos usos de API nativa, mas nenhuma invocação de código nativo, onde Flutter estaria no mesmo barco (embora Xamarin não exija a escrita de Java ou ObjC lá, sem nenhum hack de reflexão no código do aplicativo). Para código nativo, mesmo no próprio Xamarin.Android (um dos back-ends da plataforma de back-end), o uso de código nativo é muito pequeno e os desenvolvedores de aplicativos não escrevem código nativo.

E, ao contrário do React Native ou do Xamarin, o Flutter deve fornecer sua estrutura completa, portanto, é totalmente justo compararmos a estrutura inteira do Flutter com coisas como o AppKit.

é estranho que ninguém sequer mencione o framework Qt que está muito à frente de todo o resto em relação à integração com C ++

QT é C ++. E tem uma licença desfavorável para começar.

Na segunda-feira, 12 de agosto de 2019, 06:41 Vladyslav Stelmakhovskyi, <
notificaçõ[email protected]> escreveu:

é estranho que ninguém sequer mencione o framework Qt que está muito à frente
tudo o mais relacionado à integração C ++

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/flutter/flutter/issues/7053?email_source=notifications&email_token=AGDYMWXHTJUBUW64LEOO27TQEDSWNA5CNFSM4CXY6LYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4BRVYA#issuecomment-520297184 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AGDYMWTNMTM7QUOY2BEIPM3QEDSWNANCNFSM4CXY6LYA
.

Qt é C ++ e QML (mecanismo JS)
Qual licença? LGPL? GPL? o que está errado com isso?

Em primeiro lugar, IANAL, mas pelo que entendi a maior parte do Qt é LGPL (o IDE, etc. são GPL), o que significa que ele tem uma linguagem que, embora não proíba expressamente links estáticos, torna difícil fazê-lo sem deixar de aderir à licença do seu aplicativo é de código fechado.

Tecnicamente, se você usar apenas LGPL e fornecer seus arquivos de objeto (e provavelmente instruções) para que os usuários possam se vincular novamente a uma versão diferente da biblioteca, você está atendendo aos requisitos da LGPL. Mas tenho certeza que a Qt Company não anuncia esse fato, então a concepção comum é que você não pode implantar bibliotecas estáticas, o que significa que você não pode ter seu aplicativo lançado na app store sem pagar suas taxas de licenciamento exorbitantes. E posso estar errado sobre fornecer arquivos de objeto, esse é apenas o meu entendimento sobre isso, e não sei se alguma empresa está fazendo isso.

O Android é mais fácil porque permite bibliotecas carregadas dinamicamente que são permitidas de forma mais explícita pela LGPL, mas, honestamente, a vinculação estática provavelmente seria preferível lá também para manter o tamanho do aplicativo baixo, o que significa enfrentar o mesmo problema.

Olá, @cpboyd , acho que estou vendo isso da direção oposta. Já temos aplicativos construídos em estruturas de interface do usuário específicas da plataforma, onde cada plataforma nos permite utilizar nossa vasta coleção de bibliotecas C ++ existentes. Eu entendo que o Flutter é multiplataforma, o que é ótimo, mas a menos que eu possa realmente usá-lo (com meu código existente), é melhor ficar apenas com a interface do usuário não multiplataforma. O único ponto crítico surge quando um futuro sistema operacional (por exemplo, Fuchsia) requer o uso de Flutter & Dart, mas não permite esse caso de uso. Nesse caso, é provável que seja ignorado por qualquer pessoa com grandes bases de código existentes.

Acho que não tenho certeza se o Flutter / Dart está sendo projetado com aplicativos "web" (ou seja, onde os back-ends estão na web) em mente, ou se está sendo dada séria consideração às necessidades dos desenvolvedores de aplicativos de desktop profissionais. Em última análise, decisões como essa podem afetar o número e a qualidade de muitos aplicativos em uma loja de aplicativos. Se eu puder escrever um aplicativo profissional de alta qualidade para iOS usando UIKit, utilizando milhões de linhas de código existente, mas não posso (com custo de desempenho quase zero) se estou desenvolvendo para Fuchsia / Flutter / Dart, então isso seria ser um sistema operacional e uma plataforma para a qual eu não desenvolveria.

O objetivo das minhas postagens não é comparar o Flutter com outras bibliotecas multiplataforma ou não, é destacar casos de uso que são importantes para um subconjunto de desenvolvedores.

O Dart FFI é interessante, a partir da leitura _muito_ breve do exemplo sqllite , ele se parece com C # com PInvoke, mas infelizmente não é adequado para C ++, já que quase todo tipo com o qual você lida precisaria de empacotamento ou você teria que escrever algum sistema de interface sem tipo totalmente genérico para envolver o C ++. Nenhum deles é particularmente atraente quando você o compara com a facilidade da seguinte classe Obj-C:

#include <mylib/mytype.h>
<strong i="11">@implementation</strong> MyView
{
    MyLib::MyType *_pMyType;
}
<strong i="12">@end</strong>

Ou UWP com C ++ / WinRT:

#include <mylib/mytype.h>
class MyUserControl : public UserControl
{
    MyLib::MyType *_pMyType;
};

Obrigado :-)

@Hixie @MarkIngramUK Nenhum deles é multiplataforma, que foi o que quis dizer .
O AppKit é apenas para Apple, enquanto UWP é apenas para Windows.
Talvez se o Flutter tivesse usado Swift ou C # em vez de Dart, já teríamos o mesmo nível de suporte, mas esse é um argumento totalmente diferente.
Xamarin pode ser uma comparação mais apropriada do que UWP, mas as visualizações de plataforma cruzada do Xamarin não eram tão personalizáveis ​​quanto as do Flutter e frequentemente exigiam muito código nativo para ter uma aparência decente.
Minha sugestão ainda permanece: se você deseja usar Flutter com C ++, você deve participar da visualização FFI da equipe do Dart e ajudar a melhorar o suporte para todos nós 😃

Esse problema é sobre o recurso de linguagem e não deve ser misturado com o design da API do widget de IU.

@atsushieno Claro, e é por isso que essa discussão seria mais produtiva no fórum Dart FFI ... Flutter é a estrutura. Dart é a linguagem.

Nenhum deles é particularmente atraente quando você o compara com a facilidade da seguinte classe Obj-C:

@MarkIngramUK Tenho certeza de que esse é exatamente o tipo de feedback que a equipe do Dart adoraria ver em https://groups.google.com/forum/#!forum/dart -ffi

Eu tenho um projeto chamado ezored (https://ezored.com) que é um projeto de bootstrap C ++ para SDKs e aplicativos em C ++. Estamos usando em projetos mobile (Android e iOS). Estou esperando o FFI terminar para criar um projeto que usará o SDK padrão no flutter.

Não temos problemas com C ++ e o tempo de desenvolvimento de novos recursos é reduzido, já que o SDK possui o mesmo código em todas as plataformas, como você pode ver na implementação padrão (projeto poco, openssl, sqlite, código de plataforma específico integrado com código de ponte, etc.).

Na minha opinião, esta é a melhor maneira:

• iOS e Android com back-end C ++ (ezored)
• Flutter e C ++ como back-end

Sinta-se à vontade para adicionar um ponto de partida ao projeto :)

O Kotlin Multiplatform pode ser uma solução alternativa, não o pensamento perfeito. Ainda preciso esperar https://github.com/dart-lang/sdk/issues/34452

Unity3d parece estar de alguma forma portando flutter para seu motor que é baseado em C # VM [1] - naquele mundo falar entre C # e C ++ é decente. Talvez valha a pena dar uma olhada em seu repo como eles resolveram alguns problemas. Eles afirmam: "UIWidgets é derivado principalmente de Flutter". Eu também daria uma olhada no acampamento nativo reage e sua nova abordagem com TurboModules - sua solução pode ter vantagem sobre a abordagem de flutter, uma vez que será
1) síncrono e assíncrono e
2) não haverá nenhum empacotamento e
3) suportará não apenas C, mas C ++

Estou liderando a torcida em ambos os campos.

[1] https://github.com/UnityTech/UIWidgets

A partir do Dart 2.5, este ( dart:ffi ) está agora em visualização:
https://medium.com/dartlang/announcing-dart-2-5-super-charged-development-328822024970

Boas notícias!

Mmm ... Será o suficiente usar Oboé com Flutter? ..

https://github.com/google/oboe

@ rg4real Sim! Mas, você precisará escrever alguns wrappers C, já que a interface do Oboe está em C ++.

Você pode ver https://github.com/flutter/flutter/wiki/Binding-to-native-code-via-FFI para obter instruções sobre como começar.

Você pode reutilizar meu oboe-c.so que escrevi para minhas ligações C #, se funcionar https://github.com/atsushieno/oboe-sharp/tree/master/native

@ sjindel-google, essas são algumas notícias incríveis!

Portanto, preciso criar uma ponte entre o código C ++ e C criando classes e funções. E então posso usar essas classes e chamar essa função de um código Dart. Eu acho isso certo.

@atsushieno , obrigado. Eu estou dando uma olhada Não tenho certeza de como fazer pontes no meu caso (falta de experiência). Mas você conseguiu atingir seu objetivo geral de tocar de forma precisa com o oboé? Foi bom assim?

@ rg4real Eu estava fazendo isso apenas para API mais simples (em comparação com OpenSLES) do que áudio de baixa latência. Se eu realmente levasse a latência a sério, não usaria o Xamarin.Android. Se você está falando sobre Oboé (ou AAudio por trás dele), então eu uso no Fluidsynth e funciona bem. No entanto, não tenho certeza de "quão bom" o AAudio é comparado ao OpenSLES.

Existe algum guia sobre como a memória é gerenciada?

Se o código C ++ cria uma memória usando new / malloc e retorna para o código dardo, como liberar essa memória.

código c ++
void foo (char ** out) {
* out = novo char [25];
}

Como excluir a memória atribuída a | out | variável do código do dardo?

Se você estiver no Dart 2.5, há um .free() em Pointer . Se você estiver no branch dev / master, este método mudou package:ffi https://github.com/dart-lang/ffi/blob/master/lib/src/allocation.dart#L70.

De acordo com o comentário - "Só pode ser usado contra ponteiros alocados de maneira equivalente a [alocar]." - free () pode ser usado apenas se a memória for alocada usando o método allocate ().

por exemplo
ffi.Pointerptr = ffi.Pointer.distribuir();
ptr.free ();

Isso se encarrega de liberar memória que é alocada no lado C ++ usando o código new ou malloc do dardo?

Desde que a memória tenha sido alocada por meio de malloc , seja via Dart ou C ++, ela pode ser liberada com free .

No Dart 2.6, usamos DynamicLibrary.lookupFunction("free") para definir free no Dart, então será exatamente o mesmo free que na parte C ++ do programa. (A menos que você esteja vinculando várias versões de free ao seu binário.)

Encerrando este problema, pois este recurso agora está disponível (em beta) em todos os canais Flutter. Continuamos melhorando o problema. Para quaisquer problemas detalhados, por favor, arquive-os em https://github.com/dart-lang/sdk/issues/new.

fazer classes c ++ para compatibilidade c é uma bagunça. por favor, faça a capacidade de chamar diretamente classes c ++

+1 Podemos ter suporte C ++?

@KaungZawHtet e @fzyzcjy - considere abrir uma nova edição (provavelmente em dart-lang em vez de flutter) para isso.

Vou bloquear esse problema - há muitas pessoas inscritas nele, mas seu objetivo original está claramente resolvido.

Sim, para novos problemas, registre-os usando este link: https://github.com/dart-lang/sdk/issues/new?labels=library-ffi , area-vm