A porta é diferente para o H5
Abra a mesma função como página H5 dentro de um WebView e como mini-programa, e as permissões se comportam diferente. A página H5 vive num motor de navegador limitado pelo modelo de segurança web padrão: navigator.geolocation devolve uma posição grosseira ou falha em WebViews Android antigos, getUserMedia para a câmera é cerceado ou desativado, e os pagamentos pulam para um caixa externo. A versão mini-programa invoca a mesma intenção por uma ponte nativa e simplesmente funciona.
Não é um defeito de código. É o contêiner. O H5 negocia a capacidade pela camada de permissões do navegador; o mini-programa detém uma lista branca de capacidade em nível de plataforma que o runtime mapeia direto para módulos nativos.
O que é de fato uma ponte nativa
O runtime expõe capacidades do dispositivo e da plataforma por uma única superfície de API revisada — a conhecida família wx.* — em vez de deixar cada página web renegociar o acesso com o navegador. Atrás dessa superfície, a ponte roteia a chamada para a camada nativa: pagamento, localização precisa, câmera e escaneio, Bluetooth e NFC, sistema de arquivos e biometria. Cada capacidade é declarada antecipadamente, revista pela plataforma e concedida como permissão persistente e granular, não como um aviso de navegador por sessão.
A ponte também explica por que um mini-programa pode rivalizar em sensação com um app nativo. O trabalho de computação pesada — processamento de imagens, reconhecimento de QR, OCR, inferência de modelos — pode ser empurrado para a camada nativa e o resultado volta pelo mesmo canal. Os plugins nativos existem justamente para romper os limites do WebView e alcançar o poder do hardware na altura do nativo.
Onde a brecha aparece
| Capacidade | H5 em WebView | Runtime de mini-programa (ponte nativa) |
|---|---|---|
| Pagamentos | Caixa externa ou redirecionamento, fluxo partido | Pagamento nativo em contexto numa chamada |
| Localização | navigator.geolocation, grosseira, costuma falhar | getLocation precisa, revista pela plataforma |
| Câmera e escaneio | getUserMedia cerceado, frequentemente bloqueado | chooseImage e scanCode nativos |
| Bluetooth e NFC | Indisponível ou muito limitado | Módulos de ponte nativa |
| Identidade | Saltos OAuth e toques manuais | login mais número de telefone num toque |
| Biometria | Nada na web | Autenticação nativa por hardware |
O padrão se repete em toda plataforma que lança um runtime de mini-programa: a ponte é o que transforma o web dá para fazer mais ou menos no programa simplesmente faz.
Por que uma superfície vale mais que negociar por página
Uma única superfície de API revisada significa que um desenvolvedor escreve wx.requestPayment uma vez e funciona em todos os dispositivos e apps anfitriãs, em vez de manter um labirinto de degradações do navegador, assinaturas JS-SDK e listas brancas de domínio. Também significa que a plataforma pode aplicar política no limite: as capacidades são concedidas por revisão, não por quem serve o documento, que é exatamente o modelo de confiança que um super-app precisa.
Como a Cross Mini App aplica
A Cross Mini App dá aos programas uma ponte nativa que expõe pagamento, localização, câmera, conectividade e identidade por uma superfície consistente estilo wx.*, validada contra a política antes de executar. Seu código chama uma capacidade; o runtime a mapeia para o módulo nativo correto no dispositivo onde roda. Você obtém poder nativo sem escrever código nativo, e o usuário obtém um fluxo que não cai pelas fendas.
Esta é a diferença entre pedir emprestadas as chaves do navegador e segurar as suas: uma espera a porta abrir; a outra a gira.
Fontes
- CSDN Q&A — Por que o H5 em WebView falha em câmera e localização enquanto o mini-programa sucede
- PHP.cn — Diferenças centrais entre mini-programas e H5 em ambiente, desempenho e permissões de API
- DuNiao Tech — Desenvolvimento de plugin nativo: chamar capacidades nativas iOS e Android de mini-programas
- CSDN Blog — H5 vs mini-programa, de princípios a seleção: o limite de permissões de API
