Eu li que sistemas operacionais como Android e iOS são de alguma forma otimizados para melhorar a vida útil da bateria.
Meu entendimento é que uma CPU executa um certo número de operações em um determinado período de tempo, então eu acho que você pode acelerar os aplicativos reduzindo o número de operações necessárias, mas como a CPU ainda fará x operações em y tempo, isso não deve afetar o poder?
Além disso, se um processo ocupa mais RAM, consome mais energia?
As CPUs comuns usadas em smartphones, laptops e até computadores de mesa têm uma taxa de clock variável. Quando o planejador detecta que possui tempo ocioso, ele pode reduzir a taxa de clock e aumentá-la novamente se houver mais processos competindo pelo tempo da CPU.
As CPUs otimizadas para dispositivos alimentados por bateria tendem a ser compostas por muitos componentes funcionais, cada um com seu próprio relógio (exemplo: ARM Cortex A8 ). Quando um componente está ocioso, o sistema operacional pode desligá-lo (ou reduzir o relógio), o que economiza energia. Por exemplo, em muitas CPUs multicore (como as de dispositivos móveis de última geração), cada núcleo pode ser ativado ou desativado separadamente. O ARM é particularmente bom nesse jogo, que é uma das razões pelas quais a maioria dos smartphones possui CPUs ARM.
A variação da freqüência ou o desligamento do relógio dos componentes eletrônicos é conhecido como gerenciamento de energia . Tende a ser uma parte complexa da escrita e otimização de um sistema operacional para um dispositivo alimentado por bateria, com muitas dependências do modelo de hardware exato.
O que vale para a CPU também vale para periféricos. A tela retroiluminada é um grande consumidor de energia em um smartphone, por exemplo, seguido pelo rádio. O sistema operacional da CPU pode desempenhar um papel no gerenciamento de energia de periféricos; os chips secundários também executam seu próprio firmware, que também executa o gerenciamento de energia.
Os aplicativos têm o seu papel de manter o consumo de energia baixo: eles devem permitir que o sistema operacional faça seu trabalho. A pior coisa que um aplicativo pode fazer é pesquisar - executando um loop como while (not_ready()) {}. Mesmo introduzir um pequeno atraso como em while (not_ready()) {usleep(100);}não ajuda, pois não permite tempo suficiente para o processador entrar no modo de baixo consumo de energia ou, se o fizer, cada ativação infrutífera significa desperdício de energia. Portanto, as APIs do sistema operacional devem ser projetadas para que os aplicativos nunca precisem pesquisar, mas podem se inscrever em algum tipo de mecanismo de evento e permanecer inativos até serem notificados de um evento relevante. Os aplicativos, por sua vez, precisam aproveitar esses mecanismos, para que o design de toda a pilha de software tenha impacto no consumo de energia.
Você pode obter algumas informações sobre o que é responsável pelo consumo de energia do seu PC com o utilitário Powertop da Intel . Os smartphones geralmente têm uma maneira de ver quanto aplicativos de energia estão consumindo também. Contabilizar o consumo de energia por aplicação com precisão é difícil: se um componente acorda para duas aplicações, o tempo de ativação pode ser contabilizado de uma maneira arbitrária ou para nenhuma delas; o consumo de energia dos periféricos também nem sempre é facilmente rastreado para o aplicativo responsável.
Um chip de RAM não sabe quais de seus bits armazenam dados de um processo ativo; portanto, não pode ser desativado dessa maneira. O consumo de energia de um processo não está relacionado à quantidade de memória que ele usa (exceto na medida em que a RAM acessa consumir energia, mas reutilizar a mesma memória ou usar diferentes áreas de RAM não faz diferença em relação ao consumo de energia).
Em termos de energia do processador, a principal coisa que o sistema operacional pode fazer é fornecer APIs que desencorajam os aplicativos de realizar pesquisas. (E também elimine todas as pesquisas dentro do kernel e dos drivers de dispositivo, se houver). Em seguida, o processador pode ser colocado em um estado de suspensão de baixa energia sempre que não houver nada a fazer.
Para todos os dispositivos, é necessário que os aplicativos do usuário entrem no modo de espera após uma solicitação e depois sejam acordados novamente apenas quando o resultado estiver pronto.
Obviamente, loops de polling apertados são um desastre (porque mantêm o processador totalmente ativo e executam saltos e saltos inúteis.) alguma condição, reiniciando o temporizador e voltando a dormir.
Sei menos sobre essa parte, mas acho que também pode haver maneiras criativas de usar controladores DMA (acesso direto à memória) para lidar com longas sequências de interrupções repetidas sem ativar o próprio núcleo do processador.
A principal função do sistema operacional é fornecer um ambiente de tempo de execução o mais independente possível do hardware. Ele sabe quem está usando qual hardware, quando e como alguém está usando hardware. Isso permite que o sistema operacional reduza o consumo de energia do hardware quando não for usado.
Os hardwares modernos oferecem muitas maneiras de reduzir o consumo de energia, como
se um processo ocupa mais RAM, consome mais energia?
Na verdade não. No entanto, se o seu sistema possui 1 GB de DRAM, mas você usa apenas 512 MB, com alguns controladores de memória, é possível parar de atualizar parte da DRAM, reduzindo assim o consumo de energia. O LPDDR suporta a atualização automática de área parcial para fazer o mesmo durante a atualização automática (enquanto o processador está parado, o que ocorre na maioria das vezes em dispositivos móveis).
Como você pode ver, existem muitas maneiras de reduzir o consumo de energia nas arquiteturas modernas, mas isso exige que o sistema operacional o faça. Alguns recursos, como o PASR, são muito complicados de usar, isso exige muito trabalho no sistema operacional para adaptar o gerenciamento de memória, implementar procedimentos de suspensão / retomada, ...
Como você sem dúvida sabe, o sistema operacional mantém uma variedade de listas. Duas dessas listas são a lista pronta e a lista do cronômetro. A lista de pronto identifica quais tarefas / threads estão prontas para execução. A lista do cronômetro identifica as tarefas / threads que estão em um estado bloqueado com um tempo limite.
Imagine que o sistema operacional tenha uma lista pronta vazia. Ou seja, ficou sem tarefas prontas para execução (está no estado ocioso). Alguns processadores (como o x86) têm uma instrução de parada que o sistema operacional pode chamar para fazer com que o processador pare até que seja despertado por uma interrupção externa (como uma interrupção de tick). Durante esse período, consome menos energia. Essa técnica pode ser melhorada ainda mais, espreitando a lista de cronômetros. Se você estiver ocioso e souber que, assim que uma tarefa puder ser ativada a partir de um tique de timer, esteja a 100 tiques, a taxa de tique-taque poderá ser temporariamente modificada para, digamos, 100 vezes mais lenta. Dessa forma, o processador pode gastar ainda menos energia por um longo período de tempo, porque não precisará atender até 100 interrupções de tick.
Quando a interrupção externa chegar, a taxa de ticks terá que ser recalculada. Se a interrupção externa tiver preparado uma tarefa, a taxa de tick voltará ao normal. Caso contrário, o número de ticks para dormir deve ser recalculado junto com a nova taxa de ticks (lenta).
Espero que isto ajude.
fonte
Para adicionar às outras respostas:
Sua pergunta considera o iOS e o Android como sistemas operacionais, mas o "Sistema operacional" é apenas parte deles.
O Android e o iOS são estruturas e incluem muitas partes que não são consideradas parte do sistema operacional real, mas são ativas na redução do consumo de energia.
Por exemplo, o design do Android permite que os desenvolvedores de aplicativos salvem seu estado quando ocultos, para que os processos possam ser encerrados quando não estiverem ativamente em uso, reduzindo assim a quantidade de encadeamentos prontos e permitindo o desligamento do núcleo e reduções da taxa de clock.
Existem recursos no "SO" que definem brilho adaptativo, estado de suspensão de wi-fi, threads de limpeza, pool de agendamento, indicadores de LED, comportamento de espera de celular e outros aspectos que afetam drasticamente o consumo de energia.
Além disso, algumas plataformas móveis têm trabalhado duro para otimizar sua taxa de uso de CPU / GPU, uma vez que a GPU é mais adaptada aos gráficos e é uma adição relativamente nova ao cenário móvel, mais e mais partes relacionadas ao gráfico do sistema operacional estão migrando para a GPU, que limpa o trabalho da CPU e permite o uso de otimizações de energia da CPU (e em muitos casos, também acelera o sistema como um todo).
fonte