Porque é que o andróide gagueja/animação gagueja?

A questão subjacente é os diferentes modelos de animação no Android e iOS. iOS usa CoreAnimation, uma API criada pela equipe do iPhone para o iPhone original que foi portada de volta para o OSX desktop. O CoreAnimation é uma estratégia gráfica de modo retido. O Microsoft WP7 também usa o modo retido. Google's Android usa o que é conhecido como modo imediato gráficos.

Todos os GUIs geralmente funcionam da mesma maneira. Há um tópico principal com um loop que processa mensagens de uma fila. As mensagens podem variar de "move view to this location" ou "user has performed a touch at location". A questão é que é uma fila, então cada mensagem geralmente é processada uma de cada vez e em um primeiro a chegar primeiro a ordem.

Para a maioria dos kits de ferramentas de IU, incluindo aqueles encontrados no iOS e Android, o acesso e modificação de objetos deve ser feito no thread principal. Apesar de algumas vezes ser chamado de thread UI, ele é normalmente também o thread principal e frequentemente é responsável não apenas por pintar, mudar cores, mover objetos mas também por carregar arquivos, decodificar imagens, lidar com respostas de rede etc.

No Android, se você quiser animar um objeto e fazê-lo mover um objeto de local1 para local2, a API de animação mostra as localizações intermediárias (tweening) e então enfileira no thread principal as operações de movimentação apropriadas nos horários apropriados usando um timer. Isso funciona bem, exceto que a thread principal é normalmente usada para muitas outras coisas -- pintar, abrir arquivos, responder às entradas do usuário, etc. Um timer enfileirado pode frequentemente ser atrasado. Programas bem escritos sempre tentarão fazer o maior número possível de operações em background (não principal) threads no entanto você pode't sempre evitar o uso da thread principal. Operações que requerem que você opere em um objeto UI sempre têm que ser feitas na rosca principal. Além disso, muitas APIs irão canalizar operações de volta para a thread principal como uma forma de segurança de threads. Normalmente é quase impossível manter todas as operações na rosca principal até 1/60 de segundo para permitir que as animações sejam processadas suavemente. Mesmo que o Google consiga fazer com que seu código faça exatamente isso, isso não significa't significa que os autores de aplicativos de terceiros serão capazes de.

Em operações iOS em objetos UI também devem ser feitas no thread principal, com exceção das operações de animação feitas via CoreAnimation. CoreAnimation roda em um thread de fundo e é capaz de manipular, mover, recolorir e remodelar diretamente objetos UI em um thread de fundo (CoreAnimation). Composição, renderização também é realizada neste thread. Ele faz isso através de uma combinação de hardware e software, proporcionando animações muito suaves e rápidas. A partir do thread principal você pode basicamente emitir uma chamada para CallAnimation e dizer a ele para mover o objeto1 do local1 para o local2. Esta animação continuará a ser executada mesmo que o thread principal esteja bloqueado executando outra operação. É por isso que as animações quase nunca gaguejam no iOS.

Pense no modelo iOS desta forma: O tópico principal gerencia os dados da aplicação e o estado da aplicação UI (estado da aplicação UI inclui coisas como as strings a serem exibidas em uma ListView, etc) mas emite pedidos de alteração do estado físico da UI para um tópico CoreAnimação separado e dedicado de alta prioridade (estados físicos incluem coisas como cor, posição e forma). Todas as alterações de estado físico podem ser animadas e o CoreAnimation também irá executar o tweening para você (como as APIs de animação do Android). As alterações de estado físico não animadas serão emitidas directamente pela CoreAnimation e o fio principal (não o fio CoreAnimation) será bloqueado até que estas sejam executadas. As alterações do estado físico animado que são emitidas pelo fio principal serão executadas de forma assíncrona pelo fio CoreAnimation. Como o estado físico da IU e somente o estado físico da IU é gerenciado pelo thread CoreAnimation, o thread principal pode ser bloqueado ou ocupado, mas o thread CoreAnimation continuará não somente a renderizar com precisão o último estado conhecido da IU (conforme emitido pelo thread principal), mas também continuará a renderizar qualquer alteração de estado físico da IU animada pendente ou incompleta, conforme solicitado pelo thread principal.

No Windows Vista, a Microsoft introduziu a composição da área de trabalho em que o sistema operacional mantinha um buffer de pixels separado para cada janela. Isto significava que mesmo que uma aplicação pendurada, o último estado da janela (como ela parecia) ainda é renderizado em vez de ser apenas desenhado como branco (o SO gerenciava parcialmente o estado dos pixels na janela). CoreAnimation vai além disso e descarrega grande parte do trabalho de UI tradicionalmente gerenciado pelo tópico principal incluindo o gerenciamento do estado não apenas dos pixels (como o Vista), mas de nível superior
conceitos como widgets, localização de widgets, cores de widgets, etc.

iOS e Android usam arquiteturas de software completamente diferentes para executar animações. A Apple provavelmente coloca mais foco na criação de algo como CoreAnimation porque a Apple é muito mais OCD sobre design e experiência do usuário do que a maioria das empresas de software. I'tenho certeza que Steve teria algumas palavras com os arquitetos do iOS se a rolagem gaguejasse ao ler um e-mail porque uma imagem no e-mail precisava ser carregada. Os humanos são't computadores. Muitas vezes a percepção do desempenho é mais importante do que o desempenho real cronometrado. Um e-mail que leva mais 50ms para carregar won't é tão notável como uma tela sensível ao toque que não't responde e se move instantaneamente quando um usuário desliza o dedo sobre ele.

Não há nada de muito errado com o modelo de animação Android. It'é a forma como muitos toolkits funcionam, incluindo o Flash, que era definitivamente muito pesado em termos de animação. Eu diria que o modelo iOS torna a experiência geral do usuário mais agradável e descarrega mais uma preocupação para o desenvolvedor de volta para o sistema operacional. I'tenho a certeza que o Google continuará a reconhecer a importância da animação em dispositivos com ecrã táctil e continuará a acelerar (ou rearquitecturar) o Android nos próximos lançamentos.

Um iPhone de 5 anos de idade de 1ª geração irá realizar animações mais suaves e mais fiáveis do que o mais recente telemóvel quad core Samsung Android. It's é um problema de design de software e não algo em que se possa atirar mais núcleos (não menos importante porque o fio principal só funcionará em um núcleo!). Don't acredite que as pessoas quando desculpam a gagueira e o atraso como "oh apenas o coletor de lixo do Android Java". Coletores de lixo modernos compactados e geracionais geralmente são't a causa do tipo de gagueira que você vê no Android.

Por enquanto, você nunca verá algo tão simples como uma roda de carregamento de gagueira no iOS. Espero que isto explique porque :-)