Coordenador de Atividades API e terminologia

Para entender a API do Coordenador de Atividades, é importante se familiarizar com os termos usados pela API.

A API do Coordenador de Atividades coordena a execução de tarefas transferíveis, chamadas atividades, em um sistema. Os desenvolvedores podem usar a API para obter notificações de quando iniciar ou parar uma atividade com base em um estado do sistema desejado. Esse estado é definido por uma política, que descreve as condições ideais dos recursos do sistema durante a execução de uma atividade. Os desenvolvedores assinam essas políticas para que as notificações sejam enviadas a um retorno de chamada fornecido, que eles usam para coordenar a execução de suas atividades.

Observação

Essas notificações são para coordenar tarefas de baixa prioridade ou que consomem muitos recursos e que podem ser adiadas para um momento posterior. Se houver uma tarefa de alta prioridade que precise acontecer independentemente das condições do sistema, ela não deve depender dessa API.

Terminologia específica da API

Recurso

Um recurso é um componente físico ou atributo do sistema que é consumido ou afetado por uma atividade. Exemplos simples são recursos tradicionais do sistema, como CPU, disco do sistema e GPU. Recursos menos tradicionais incluem coisas como energia e ociosidade do usuário.

Condição

Uma condição é uma descrição qualitativa do estado desejado de um recurso como bom, médio ou não definido. Em um nível básico, uma boa condição significa que é um bom momento para usar um recurso. Um determinado par recurso-condição pode ser avaliado usando uma variedade de dimensões.

Os desenvolvedores devem escolher quais condições usar para recursos individuais, para que eles atendam às necessidades de sua carga de trabalho. Isso permite que a API coordene melhor o trabalho entre seus consumidores.

Transferível

Tarefas transferíveis são aquelas tarefas que não afetam imediatamente a experiência do usuário de um aplicativo, embora a falta de execução por um período prolongado ainda possa afetar a experiência geral. Em geral, essas tarefas não precisam ser executadas imediatamente e podem adiar sua execução para um momento em que o sistema esteja em um estado desejável. Esses são momentos em que a execução da tarefa não interfere na experiência do usuário ou no desempenho do sistema. Tais tarefas podem incluir:

  • Reindexando um catálogo de mídia
  • Treinamento ou atualização de um modelo de recomendação
  • Instalando atualizações de plug-in

Atividade

Uma atividade é uma unidade de trabalho transferível, conforme definido pelo desenvolvedor. As atividades consomem inerentemente recursos do sistema para serem executadas, o que pode resultar em impacto na experiência do usuário. Os desenvolvedores devem entender como sua atividade consome esses recursos para que possam usar adequadamente a API. Em seguida, eles podem adiar a execução da atividade para um momento mais ideal usando a API, em vez de executar imediatamente esse trabalho em momentos que podem afetar significativamente a experiência do usuário.

Política

As políticas definem o que significa um tempo ideal para execução, descrevendo as condições desejadas de vários recursos necessários para serem executados ou afetados pela atividade do desenvolvedor. Uma política é formada por vários pares de recursos e condições, definindo condições individuais de recursos.

Uma política pode especificar condições para recursos como Energia, Memória e CPU, mas também excluir recursos como GPU com base em sua relevância. Uma política é considerada aberta quando todas as condições de recurso são atendidas e fechadas de outra forma. As políticas não descrevem quanto de um determinado recurso se espera que uma atividade consuma. A API usa configurações de política para tomar decisões de coordenação entre os consumidores da API.

Ao configurar uma política, é recomendável que o desenvolvedor comece com a melhor (boa) condição para cada recurso para que a API possa ajudá-lo a ser executado nos melhores momentos, quando a execução tem menos probabilidade de afetar a experiência do usuário ou o desempenho do sistema. As condições podem ser reduzidas (por exemplo, de boas para médias) depois se a atividade não for notificada para ser executada com frequência suficiente ou por tempo suficiente para atender às necessidades do desenvolvedor.

Assinatura

As assinaturas são o mecanismo de coordenação das atividades. Os desenvolvedores assinam uma política com um retorno de chamada, que a API chama com notificações de coordenação. Essas notificações informam ao desenvolvedor quando ele deve iniciar/retomar ou parar/pausar sua atividade. As notificações são baseadas nas condições de recursos da política assinada, conforme configurado no momento da assinatura, e nas decisões de coordenação tomadas pela API.

Modelo de política

Um membro do enum ACTIVITY_COORDINATOR_POLICY_TEMPLATE. Eles podem ser usados ao criar uma política para pré-configurá-la com condições razoáveis projetadas para atender às necessidades comuns da maioria das atividades e minimizar o impacto para o usuário.

Downgrade

Você pode fazer downgrade de uma política ou recurso alterando de melhores para menores condições para torná-lo mais permissivo e aumentar a probabilidade de as condições da política serem satisfeitas. Por exemplo, você pode fazer downgrade de uma boa condição para CPU alterando-a para uma condição média. Uma condição média tem requisitos menos restritivos e, portanto, é mais provável que seja atendida. No nível da política, isso aumenta a probabilidade de que a política seja aberta (todas as condições de recursos são satisfeitas) com mais frequência e por períodos de tempo mais longos, tendo em mente que esses podem ser momentos em que há maior probabilidade de causar impacto no usuário ou degradar o desempenho do sistema.

Ações disponíveis

A API permite que o desenvolvedor execute as seguintes ações:

  • Configurar uma política.
  • Subscrever / cancelar a subscrição de notificações para políticas.

A API fornece a flexibilidade de personalizar políticas para melhor se adequar ao cenário do desenvolvedor, começando com uma configuração de política vazia ou uma das configurações de modelo que atendem às necessidades da maioria dos aplicativos. No caso mais simples:

  • Aloque uma política usando um ID de política de modelo dentro ACTIVITY_COORDINATOR_POLICY_TEMPLATE.

Para um cenário de desenvolvedor mais personalizado,

  • Alocar uma política de modelo (potencialmente vazia).
  • Defina as condições desejadas para os recursos relevantes.

Visão geral da API do Coordenador de Atividades

Escolhendo a política correta do Coordenador de Atividades

Exemplo de projeto de Coordenador de Atividades