Compartilhar via

Gravando aplicativos de mídia em segundo plano que economiza energia (HTML)

  • Artigo

[ Este artigo destina-se aos desenvolvedores do Windows 8.x e do Windows Phone 8.x que escrevem aplicativos do Windows Runtime. Se você estiver desenvolvendo para o Windows 10, consulte documentação mais recente ]

Introdução

Uma novidade do Windows 8 é o modelo de energia AOAC (sempre ligado, sempre conectado). Esse modelo permite que os aplicativos consumam muito pouca energia mesmo ainda estando conectados e responsivos. Esse novo estado de baixo consumo de energia é chamado de CS (modo de espera conectada). Uma das finalidades desse estado é permitir a reprodução de áudio em baixo consumo de energia para que os aplicativos de mídia em segundo plano possam ser executados por muitas horas com uma única carga de bateria.

Para cumprir as finalidades de energia do modo de espera conectada, a conexão de rede precisa entrar em estado de baixo consumo de energia. Isso significa que um aplicativo de áudio em segundo plano não pode acessar a rede a todo momento. As fontes do Microsoft Media Foundation ainda podem executar conteúdo em rede, por exemplo através de uma marca de áudio HTML5, tanto de locais de arquivo de rede quanto de mídia em streaming se você usar fontes de caixa de entrada. Mas se um aplicativo precisar se comunicar com a rede por quaisquer outros motivos, por exemplo para verificações de licença, metadados ou estatísticas do usuário, você precisará executar outras tarefas.

Esses requisitos se aplicam somente a aplicativos que reproduzem áudio em segundo plano. Para saber mais sobre como reproduzir áudio em segundo plano, veja Como reproduzir áudio em segundo plano.

Como acessar a rede

Há três maneiras de um aplicativo de áudio em segundo plano acessar a rede:

  1. Background transfer API. Esta é a melhor opção. Basta fazer suas chamadas de rede adicionais através da API de transferência de segundo plano como upload ou download de arquivo. Todo o trabalho de ativar e desativar a rede será executado por você. Para saber mais, veja Windows.Networking.BackgroundTransfer

  2. Wrap an existing MF bytestream. A API de transferência de segundo plano foi projetada para transferência de arquivos e pode ser extremamente pesada para comunicações de rede pequenas e rápidas. Quando uma fonte ou um fluxo de bytes do Media Foundation é instanciado, o Windows assume uma referência de rede a seu favor. Isso se aplica a fontes do Media Foundation personalizadas e a fluxos de bytes também. Uma fonte ou um fluxo de bytes completamente personalizado é bastante complexo; para simplificar o problema, você pode empacotar fluxos de bytes de caixa de entrada. Após a inicialização, o aplicativo poderá usar a rede conforme necessário usando qualquer API de rede. Ao concluir a rede, o wrapper iniciará o uso do fluxo de bytes de caixa de entrada. O fluxo de bytes de caixa de entrada por sua vez desliga a rede quando é concluído.

    Para obter um exemplo de fonte personalizada, veja exemplo de comunicações em tempo real.

    Para obter um exemplo de como se comunicar entre um aplicativo e uma fonte, veja o exemplo de fonte de fluxo de mídia.

  3. Fully custom Media Foundation source or bytestream. Esta é semelhante à opção 2, mas em vez de usar quaisquer componentes de caixa de entrada, o desenvolvedor escreve por completo a fonte ou fluxo de bytes do Media Foundation. Nesse caso, é de sua responsabilidade notificar ao Media Foundation quando terminou o trabalho com a rede emitindo alterações de características. A figura mostra um exemplo de fluxo.

A seguir está um exemplo de uma lista de reprodução de duas músicas que usa a opção 2 ou 3.

Exemplo de fluxo de uma lista de reprodução de duas músicas que usa a opção 2 ou 3.

Se nenhuma dessas soluções funcionar para seu aplicativo, contate pelo email lpa_questions@microsoft.com. Dê detalhes do seu cenário de uso exato e por que as opções anteriores não podem funcionar para você.

Outras considerações

Além de verificar se o seu aplicativo acessa a rede adequadamente, há algumas outras considerações em relação a um aplicativo de áudio de baixo consumo de energia. Como o aplicativo pode ser executado quando a maior parte do sistema está suspensa, você precisa ter em mente as necessidades de energia ao desenvolver o aplicativo. Usando notificações de alterações de visibilidade (isso ocorrerá quando o aplicativo estiver em segundo plano e quando o dispositivo entrar em modo de espera conectada) como dica, coloque o aplicativo em seu próprio modo de baixo consumo de energia.

  • Não execute nenhuma atualização de interface do usuário. Se o aplicativo não estiver visível, tudo o que for relacionado a elementos gráficos ou interface do usuário utilizará energia desnecessariamente.
  • Reduza o trabalho onde for possível. Isso está extremamente vinculado às atualizações de interface do usuário. Se alguma tarefa não for necessária a não ser quando um usuário está presente, não fará sentido executá-la quando o aplicativo não estiver visível.
  • Comunicações de rede em lote. Quanto mais o aplicativo puder ser usado sem exigir tempo de uso significativo da CPU ou da rede, melhor será.
  • Quando em modo de espera conectada, as operações poderão levar mais tempo. O aplicativo ficará acelerado quando em modo de espera conectada e terá somente pouco tempo para ser executado na CPU.
  • Para ajudar a garantir o melhor uso de recursos de áudio, você deverá limitar o número de marcas de áudio usadas em seu aplicativo a somente uma ou duas simultaneamente (isso inclui marcas que podem ser inicializadas porém não ser executadas ativamente).