É curioso ver que, ano após ano, continuam a persistir muitos dos mitos dos "antigamentes". Desde o trauma das baterias de NiCd cujos efeitos de memória as pessoas tentam atribuir às de LiIon e mais recentes, às questões de matar tarefas nos sistemas operativos Android e iOS.
Já por várias vezes cá referi que não se deve interferir com o funcionamento do sistema, sendo - na grande maioria dos casos - preferível confiar no sistema para fazer a melhor gestão dos seus recursos; e hoje, vou aproveitar a boleia deste post sobre os enganos do multitasking no iOS do iPhone e iPad, para abordar este caso.
Há pessoas que recorrentemente acedem à barra do "multitasking" do iPhone, e "matam" todas as Apps que lá permanecem... como se tivesse alguma lógica tentarmos andar a interferir com a gestão de memória num sistema operativo moderno. Há até quem recomende que se faça isso, para "libertar memória/poupar bateria/acelerar o iPhone".
Mas na verdade... a lista de Apps que ali é apresentada é apenas a das últimas Apps utilizadas; e não de Apps que estão a ser executadas em "background".
Na grande maioria dos casos, o iOS continua a executar apenas uma App de cada vez e de forma exclusiva; e quando regressam ao menu principal, a App é suspensa ou terminada, dependendo da memória livre disponível. Em ambos os casos, a App em questão passa a usar "zero recursos". (No caso de ainda permanecer em memória - mesmo não estando a ser executada - permite apenas que caso voltem a arrancar a App, esta regresse imediatamente ao estado em que estava anteriormente.)
Caso uma nova App necessite de memória, o iOS instantaneamente irá libertando memória destas Apps "suspensas", que nenhum impacto têm na velocidade de funcionamento do CPU ou no consumo da bateria...
Mas... na verdade existem as modalidades de multitasking, que permitem que algumas Apps continuem a executar tarefas mesmo depois de as abandonarmos: para permitir coisas como, continuar a ouvir um stream de rádio online mesmo após sairmos da App; ser guiado até ao destino com uma App de navegação GPS; e outras coisas do género.
E são elas:
Tarefas em Background
Uma App pode pedir uma extensão do tempo em que está a funcionar, para que quando alguém clique no botão de home a App possa continuar a fazer um download ou upload de algo que previsivelmente demore apenas mais algum tempo. (Mesmo neste caso, passado algum tempo, o iOS irá suspender o seu funcionamento, para evitar Apps abusivas.) Por norma, cada App tem direito a 5 seg de execução quando se sai da mesma, e com este modo, pode esticar esse período até 10 minutos aproximadamente.
... Claro que este modo não seria de grande uso para quem estivesse a ser guiado por uma App de navegação GPS numa viagem de algumas horas... e por isso mesmo temos:
Tarefas em Background sem Limite de Tempo
Para permitir que certos tipos de Apps possam funcionar sem as limitações de tempo referidas anteriormente, mas ainda assim tendo controlo sobre Apps que corram continuamente (e que no caso de serem mal programadas, seriam um potencial motivo de dores de cabeça - como as que são bem conhecidas dos utilizadores dos Windows Mobile "antiguinhos" e também dos Android (Apps que muitas vezes dão má fama aos próprios sistemas, que na verdade não têm culpa disso). Mas a Apple quis evitar essa situação, e por isso limitou este multitasking real a:
- Apps que tocam áudio em modo background - para permitir Apps de streaming de música, etc.
- Apps que acedam à localização GPS em background - para apps de navegação GPS, etc.
- Apps que acedem a chamadas VOIP - para que possam receber chamadas em apps como o Skype.
- Apps da Newsstand a fazer download de conteúdos - revistas e jornais
- Apps que recebam actualizações de acessórios externos via background
Ao limitar o multitasking a estes casos, o iOS faz com que o caso de Apps mal feitas, que pudessem consumir demasiados recursos seja drasticamente reduzido. Embora comecem a surgir cada vez mais Apps a dar "a volta" a estas limitações, usando - por exemplo - o argumento de que precisam de aceder à localização GPS em background, para assim poderem ir executando outras funções (como o programa de contabilização de dados My Data Manager, e outros.)
Seja como for, a necessidade de andar a "terminar" Apps suspensas em memórias continua a ser algo que não é recomendado... e que na prática não tem qualquer efeito real (com a tal excepção de uma App com bugs que permaneça suspensa em memória num estado "maluco", e que só volta a arrancar a partir do estado original... Mas aí, a culpa continua a ser da App e não do iOS.)
Actualização: eis um vídeo que mostra tudo isto em funcionamento (obrigado ao Tiago pelo link):
iOS Multitasking from Fraser Speirs on Vimeo.
Esta é sem dúvida uma informação muito útil. Infelizmente esse mito ainda persiste, o de apagar todas as apps que estão na barra de multitask, apesar de isso não trazer benefício nenhum. Vou ver se mostro este post a algumas pessoas que o fazem :D
ResponderEliminarViva
ResponderEliminar"...a lista de Apps que ali é apresentada é apenas a das últimas Apps utilizadas; e não de Apps que estão a ser executadas em "background"."
Não é bem assim...
E o pessoal que tem JB e usa o SBSettings, vê bem que a RAM desaparece quando se tem App's na barra multitask...
(e por vezes já nem sequer lá estão - à vista- e a memória está "perdida" em algum lado...)
O que a notícia apontou está correcto, em vez das pessoas deixarem "quieto" o sistema gerir a RAM, põem-se a mexer e ainda é pior.
ResponderEliminarMas de facto pela minha experiência o António também tem razão: a lista que aparece contém como que uns "serviços" (ou algo assim) das últimas apps usadas para um load mais rápido (ou seja, não é a app inteira) que ocupa RAM. No final, não é 100% "apenas uma lista" nem 100% a "aplicação na RAM". Não é infrequente no iPad 1 / iPod (256Mb RAM) algum pequeno lag por esse efeito (onde acabando com essa lista permite ao sistema voltar a ficar 100% fluído). Digamos que a Apple está num excelente caminho, só que nos iOS de 256Mb RAM só funciona a 99.99% :)
O que eu me tenho apercebido é que os últimos Android e o iOS já conseguem lidar muitíssimo bem com a RAM/background e, tal como o Carlos diz, é preciso libertar a mente de andar sempre à procura de App Killers.
E eu que tinha a mania dos Task Killers e "forçar" a paragem das apps... Já o desinstalei! Mais uma vez, o AadM está de parabéns parece que estou em constante formação (eheh), obrigado ^^
ResponderEliminarO que o @Antonio Luis Coelho disse é a maior das verdades, e está mais do que provado que assim o é. Eu como não dispenso nos meus iDevices o "JB", sei bem a diferença que é a susposta "hibernação ou registo das ultimas apps abertas" e limpar as mesmas fazendo um freeze na memória. A diferença muitas vezes é abismal no desempenho de certas aplicações.
ResponderEliminar@Anónio e @RedHawk
ResponderEliminarSim, é como disse, as Apps são mantidas suspensas na memória enquanto a memória não é necessária para outras funções.
Isso faz-me lembrar a velha questão da memória "livre" vs "utilizada" nos OS dos computadores de secretária.
Afinal, é melhor ter 99% da memória livre sem nada, ou ter permanentemente 100% da memória em uso, com caches e outras coisas do género (e que a qualquer momento podem ser descartadas para disponibilizar memória para ser utilizada por programas que dela necessitem?)
Quanto a isso de limpar Apps para melhorar o processo... é questão de tentares encontrar uma sequência que garantidamente te faça isso acontecer, para ver se é repetível em iOS sem JB... Era interessante comparar a ver se realmente se notam diferenças, e se é algo repetível e mensurável... ou só o "efeito placebo". :)
Uma pergunta, isto também ocorre para o Android?
ResponderEliminarClaro que não, no android tudo funciona de forma simuntânea dependendo da potência do smartphone, pode ter até sido inteligente a teoria que a apple tem de dedicar toda potência do aparelho exclusivamente ao app que está em funcionamento, porém acho isso besteira, porque você não tem multitarefas real, e isso pode se tornar não-produtivo, entendeu?!
Eliminar"é questão de tentares encontrar uma sequência que garantidamente te faça isso acontecer, para ver se é repetível em iOS sem JB... Era interessante comparar a ver se realmente se notam diferenças, e se é algo repetível e mensurável... ou só o "efeito placebo". :)"
ResponderEliminarTenho um iPod touch sem JB e uma app que me indica o estado da memória, e apagar as apps da barra de multitask aumenta o espaço livre da memória, e, no caso de estarmos com menos de 20% de bateria (aquele conhecido risquinho vermelho), a bateria aumenta, ficando com um risco branco (mais de 20%). Como o tempo estimado de bateria é calculado com a actual utilização do CPU, significa que estavamos a usar mais CPU do que o que passamos a usar depois de fecharmos as apps.
Por isso, não me venham dizer que fechar as apps não melhora o desempenho.
@José
ResponderEliminarDesculpa lá se sou um pouco céptico quanto a isso.
Ter a memória "cheia" ou "vazia" não tem qualquer impacto na bateria, e não por lá terem N apps suspensas que a autonomia será afectada.
(E refiro apenas o bug que eu próprio senti na pele, do meu iPhone que também passava dos 100 aos 10% em poucas horas... mas depois ficava mais de 8h ligado com a bateria a dizer que já não aguentava... Estimativas são apenas isso.)
Como disse, tenho curiosidade em saber se haverá dados concretos sobre o tal impacto das Apps suspensas - mas à partida, tecnicamente, não existem motivos para que exista impacto adverso.
Uma memória RAM consome exactamente o mesmo quer esteja toda a "0", ou a "1", ou qualquer combinação pelo meio. E a gestão que o CPU tem que fazer de blocos cheios/vazios/alocar/libertar, tem impacto negligenciável.
(Isto, na teoria de funcionamento... faltará efectivamente determinar que se concretiza na prática!)
@Rúben
Sim, no Android a gestão é feita de forma semelhante, só que as Apps podem efectivamente estar a correr em background sem as restrições que têm no iOS.
"Nem sempre, nem nunca". Acho-a uma frase mais incisa do que a a habitual "Não há regra sem excepção".
ResponderEliminarResumindo, "nem sempre" é preciso andar a apagar do switcher a fiada de apps que por lá anda (então andar a apagá-las uma a uma é um trabalho inglório e inútil), mas "algumas vezes é preciso", como até está no post - para apps que continuam efectivamente a trabalhar em backgroud e que se se quer que parem de funcionar de forma expedita. É o caso dos programas de navegação e rádios.
Preciso do programa de navegação para encontrar o acesso a uma via rápida/auto-estrada que conheço bem e quando lá chego tenho que ouvira a TomTom/Catarina até casa ?!
De maneiras que comigo para calar o TomTom, tendo em conta que vou a conduzir é
- botão Home e clicar em cima do badge que é criado sobre o símbolo da app pelo tweak do Cydia RunnigIndicator
- Duplo Home (ou um gesto do Activator) para fazer aparecer o switcher e clicar no símbolo do tweak do Cydia KillBackgroud. Este desactiva e apaga do switcher todas as app.
Se tiverem outra solução mais prática para calar a "Catarina", digam.
Eu era um dos nabos que fazia tal coisa.. Muito esclarecedor!
ResponderEliminarEste comentário foi removido pelo autor.
ResponderEliminarBoa, sempre pensei que as aplicações quando estão no (nao sei o nome, duplo click no home), estivessem a correr em background... volta e meia vou fechar as apps que la se encontram. (mas o que é certo é que a app RAM DOCTOR, quando tenho apps nesse duplo home, indica-me que tenho menos memoria disponivel e quando as fecho, fica mais disponivel);
ResponderEliminarObrigado Carlos.
@antonio free RAM is Wasted RAM!
ResponderEliminar@ruben http://mobileorchard.com/android-app-development-activity-life-cycle/
@ruben e ainda http://android-developers.blogspot.com/2010/04/multitasking-android-way.html
ResponderEliminarNum SO moderno, ter muita memória livre disponível é ineficiente. Em uso normal não faz sentido ter mais de 20% de memória livre. Bem sei que isto vai um bocado contra o senso comum, mas é como diz o Carlos Martins, o mapeamento de memória gasta o mesmo, quer esteja cheio de zeros, quer esteja cheio de dados. A única diferença que há é a nível de CPU, mas essa é perfeitamente desprezível e as vantagens ultrapassam largamente os inconvenientes. Ter uma app inactiva na memória implica uma de 2 coisas: Ou a app está totalmente congelada e portanto não gasta recursos nenhuns; ou a app está em stand-by com uma ou mais APIs activas, e neste caso então o CPU gasta 3 ou 4 ciclos por segundo para "checkar" o seu estado. Mesmo que tenhamos, por absurdo, 100 apps em background com APIs activas, são 400 ciclos por segundo. Se a memória de um Ipad ou dispositivo similar trabalhar a uns muito conservadores 266mhz, isto significa 1,5 milésimos de segundo "perdidos", ou 0,15% de tempo, o que é imperceptível.
ResponderEliminarApesar do princípio ser o mesmo, há 2 diferenças de base entre iOS e Android. No iOS o multitasking é selectivo, isto é, admite que apenas um conjunto limitado de APIs possam estar activas em background. No Android, a gestão do multitasking é mais semelhante a um PC normal, ou seja, pode não haver qualquer controlo sobre o que fica activo em fundo. Isto significa que o Android é potencialmente menos eficiente, porque se a programação não for de qualidade, vão ficar APIs activas excusadamente, o que consomoe recursos desnecessariamente. A outra diferença tem que ver com os "task killers" automáticos. Esta função no iOS fica a cargo do programador, que é obrigado a controlar isto de forma directa. Assim, o programador tem que ter o cuidado de, quanto está a programar, saber onde estão as variáveis, os endereçamentos à memória, etc, e criar instruções para os matar caso não sejam necessários. No Android isto é automaticamente controlado pelo sistema através dos chamados Garbage Collectors (GC). Os GCs simplificam muito a tarefa de programar, reduzindo o tempo de desenvolvimento de aplicações, mas têm o inconveniente de, sendo sistemas automatizados, cometer mais erros, pelo que é normal que um Android acumule bastante mais lixo na memória RAM e em cache que um iOS, ao fim de algum tempo de uso.
Vejam aqui o que acontece na prática: http://www.iclarified.com/entry/index.php?enid=19187
ResponderEliminar