Limites Mobile Browser Cache: Android, iOS, webOS e

28 de junho, 2010 às 8:45 pm por Ryan Grove | Em Desenvolvimento , Desempenho | 19 Comments

Atualização (12 de julho de 2010): Embora os resultados descritos neste artigo são precisos para páginas HTML, novos testes revelaram limites de cache muito diferente para os recursos CSS e JS. Os resultados atualizados são descritos em Limites Mobile Browser Cache, Revisited .

No início de 2008, Wayne Shea e Tenni Theurer escreveu um post no Blog YUI Cacheabilidade iPhone em que eles compartilharam os resultados das pesquisas em várias características e limitações de cache Mobile Safari no iPhone OS 1.x. Entre outras coisas, eles descobriram que os componentes individuais maiores do que 25KB não foram armazenados em cache, e que havia um tamanho máximo de cache total entre 475Kb e 500KB.

Muita coisa mudou desde então. Nós vimos dois novos grandes lançamentos e muitos lançamentos menores do iPhone OS (iOS agora), e vários outros dispositivos móveis com browsers altamente capaz apareceram para desafiar o iPhone. Stoyan Stefanov encontrado, no final de 2009, que limita o iPhone de cache havia mudado (infelizmente, para pior). Mas onde é que as coisas estão agora? E quanto aos navegadores não-iOS?

Fundo

Navegadores têm dois tipos de caches que estamos preocupados com para efeitos destes testes:

  • O cache do componente, ou cache de objetos, armazena arquivos individuais. HTML, CSS, JavaScript, imagens e todos vão para o cache componente. Sempre que precisa de um destes componentes, o primeiro navegador verifica o cache antes de fazer uma solicitação de rede.
  • O cache de página, também conhecido como o back / cache de encaminhamento, lojas de uma página inteira e todos os seus componentes, bem como seu estado atual. Quando você usa o botão de trás ou para frente, o navegador irá carregar a página do cache da página, se possível.

O cache do aplicativo HTML5 é outro tipo de cache que é amplamente suportado pelos navegadores móveis. Fabricantes de navegadores já fazem um bom trabalho de documentar os limites de cache do aplicativo, então eu não incluí-lo em meus testes. Mais informações sobre o cache do aplicativo mais tarde.

Dispositivos Testado

Eu testei o seguinte mobile browser / plataforma de combinações:

  • Android 2.1 (Nexus One)
  • Mobile Safari no iOS 3.1.3 (1-gen iPhone)
  • Mobile Safari no iOS 3.2 (IPAD)
  • Mobile Safari no iOS 4.0 (iPhone 3G)
  • Mobile Safari no iOS 4.0 (iPhone 4)
  • 1.4.1 webOS (Palm Pre Plus)

Nota: Com exceção do Mobile Safari no iOS 4.0, eu testei apenas um dispositivo em cada categoria. Se existem variações entre os dispositivos individuais ou diferenças com base no software instalado além do OS, meus testes não detectar essas variações. Estes dispositivos foram testados em particular, porque eles são os que eu tive acesso, não porque eu considero-os a ser mais importante do que outros dispositivos.

Metodologia

Testes de cache é tedioso, mas relativamente simples.

Eu escrevi uma pequena app Sinatra ( fork-lo no GitHub! ) que gera uma resposta que consiste em um número solicitado de bytes pseudo alfanuméricos e espaços em branco. As respostas podem ser servidos tanto gzipped ou descompactado. A seguir far-futuro cabeçalhos de resposta de expiração são enviados para garantir que todas as respostas são consideradas cacheable: 

 Cache-Control: max-age = 315360000
 Expires: Fri, 01 de maio de 2020 03:47:24 GMT

Sobre a minha rede local, então eu realizadas manualmente os seguintes passos em cada dispositivo para testar o cache componente:

  1. Carregar o cache de páginas de índice de teste.
  2. Toque em um link para um componente de um determinado tamanho, variando de 5 KB para 20 MB, e esperar por ele para concluir o carregamento.
  3. Toque no botão de volta.
  4. Toque no mesmo link novamente. Observe se os caracteres aleatórios são os mesmos, e se o console do servidor imprime uma entrada de log para um pedido, para determinar se o componente foi armazenada em cache no passo 2.
  5. Repetir e ajustar os tamanhos componente necessário para determinar o tamanho do componente máxima que será armazenada em cache.

Para testar o cache de página, realizei basicamente os mesmos passos só que em vez de tocar no link novamente no passo 4, eu bati botão de avanço do navegador, fazendo com que usam o cache de página em vez de o cache componente.

Suporte para ETag e Last-Modified foi determinada por ajustes o servidor para enviar o apropriado ETag ou Last-Modified cabeçalhos de resposta (em testes separados) e omitir os cabeçalhos far-futuro de validade. Eu, então, inspecionados os cabeçalhos de solicitação recebida pelo servidor para verificar se o browser enviou o esperado If-None-Match ou If-Modified-Since cabeçalhos no passo 4.

Resultados

Eu testei com gzip tanto ativado e desativado, mas eu achei que gzip não teve efeito sobre cacheability em qualquer dispositivo. O tamanho do componente descompactado é o que interessa em todos os casos, independentemente de haver ou não esse componente é servido gzipped. Como tal, todos os tamanhos de componentes aqui mencionados são tamanhos descompactado.

A tabela abaixo ilustra os meus resultados globais.

Tabela: características de cache do navegador móvel
Browser / OS / Dispositivo Limite de um componente Limite de componentes totais Página Limite de tamanho do cache Suporta Last-Modified Suporta ETag Sobrevive Power Cycle
Android 2.1 (Nexus One) ~ 2MB (~ 2.048 mil b) ~ 2MB (~ 2.048 mil b) ∞ 2 Sim Sim Sim
Mobile Safari, iOS 3.1.3 (1-gen iPhone) 0b 1 0b 1 ∞ 2 Não Não Não
Mobile Safari, iOS 3.2 (IPAD) 25.6KB (26.214 b) ~ 281.6KB (~ 288.354 b) 25.6KB (26.214 b) Sim Sim Não
Mobile Safari, iOS 4.0 (iPhone 3G) 51.199KB (52428 b) ~ 1.05MB (~ 1.100.988 b) ∞ 2 Sim Sim Não
Mobile Safari, iOS 4.0 (iPhone 4) 102.399KB (104857 b) ~ 1.9MB (~ 1.992.283 b) ∞ 2 Sim Sim Não
1.4.1 webOS (Palm Pre Plus) 3 ~ 1MB (~ 1.048.576) ? ~ 1MB (~ 1.048.576) Não Não Sim

Notas:

1 Mobile Safari no iOS 3.1.3 não aparece para armazenar em cache todos os componentes, independentemente do tamanho, exceto para o cache de página. Não está claro se isso é intencional ou um bug.

A página 2 caches no Android 2.1, iOS 3.1.3, e iOS 4.0 (mas não iOS 3.2) parece ser limitada apenas pela memória RAM disponível quando se trata de tamanho de página individual. Eu não tentar determinar exatamente quantas páginas separadas poderiam coexistir no cache de página de uma vez.

Resultados dos testes 3 ​​webOS eram inconsistentes e em vários pontos do cache pareceu parar de funcionar completamente até que o telefone era o poder-ciclo. Eu não considero esses resultados conclusivos, ou mesmo confiável, mas eles são listados aqui por uma questão de comparação.

Andróide

O browser do Android exibiu o comportamento melhor de cache de todos os dispositivos testados. Embora pareça impor nenhum limite no tamanho dos componentes individuais, o tamanho do cache total parece ser limitado a cerca de 2MB, o que significa que os componentes individuais são efetivamente limitado a 2MB também.

O cache de página apareceu para impor nenhum limite no tamanho das páginas individuais, felizmente cada byte caching eu joguei com ele até a memória RAM disponível estava exausto e o navegador falhou.

Fiquei agradavelmente surpreso ao descobrir que o cache do Android componente sobreviveu reinicia do browser e os ciclos de energia, uma façanha nenhum dos dispositivos iOS foi capaz de igualar.

Ressalva possível: Uma revisão de fonte do Android WebKit árvore me leva a crer que limita seu cache pode adaptar com base na quantidade de memória RAM e / ou memória flash disponíveis no dispositivo em particular em que ele está correndo. Se for verdade, esses números só podem ser aplicáveis ​​ao Nexus One. De fato, se o tamanho do cache se adapta com base na memória não utilizada ao invés de memória total, estes números devem ser aplicáveis ​​apenas ao meu Nexus One.

Eu poderia estar enganado, mas as diferenças nos resultados do teste iOS 4.0 no iPhone 3G e iPhone 4 suportam esta teoria. (Android e Mobile Safari são dois navegadores baseados no WebKit, assim eles podem ter esse comportamento em comum.) Se você estiver familiarizado com a fonte WebKit e pode lançar mais luz sobre isso, por favor entrar em contato comigo.

iOS

Os resultados variaram amplamente entre os três mais recentes versões do iOS. Surpreendentemente, Mobile Safari no iOS 3.1.3 não cache de componentes de qualquer tamanho, apesar de ter um tamanho de cache aparentemente ilimitado de páginas. Isto é preocupante pois significa iOS 3.1.3 os usuários provavelmente recebendo uma experiência de navegação abaixo do ideal, especialmente se eles não estão usando wifi. O tamanho do cache ilimitado página faz pouco bom aqui, uma vez que só entra em jogo para trás / navegações para a frente. Este comportamento é uma mudança significativa do que os outros observados nas versões anteriores iOS e eu não posso imaginar qualquer boa razão para isso, então eu suspeito que este pode ser um bug.

Mobile Safari no iOS 3.2 (que é disponível apenas no iPad) não apresentam esse bug. Seu limite componente 25.6KB e ~ limite de cache 281.6KB total são melhor que nada, mas eles ainda parecem insignificantes em comparação com os outros dispositivos testados. Exclusivamente entre os dispositivos iOS, o iPad parece limitar o tamanho das páginas no cache de página para 25.6KB, o mesmo que o seu limite de tamanho do componente.

Mobile Safari no iOS 4.0 exibiu limites diferentes sobre o iPhone 3G e no iPhone 4, o que implica que os limites se adaptar com base em RAM disponível (o iPhone 3G tem 256MB, enquanto o iPhone 4 tem 512 MB; ambos os dispositivos testados tinham 32GB de memória flash) . No iPhone 3G, iOS 4.0 tem um limite de tamanho 51.199KB componente e um ~ 1.05MB tamanho total do cache componente.

No iPhone 4, o limite de tamanho do componente era quase exatamente dois vezes o limite sobre o iPhone 3G, em 102.399KB. O tamanho total do cache componente foi de aproximadamente 1.9MB. Talvez porque iOS 3.2 e iOS 4.0 foram desenvolvidos separadamente, mas ramificado a partir de um ancestral comum, o iOS 4.0 tamanho do cache de página parece ser limitada apenas pela memória RAM disponível em ambos os dispositivos testados, assim como iOS 3.1.3.

Nenhum dos dispositivos iOS preservado o conteúdo do cache do navegador através dos reinícios forçado ou ciclos de alimentação do dispositivo, embora tenham preservar o cache quando apenas comutação aplicações sem realmente matar o browser.

webOS

Os resultados do meu teste no webOS foram tão inconsistentes que eu tenho pouca confiança neles. Eu incluí o que poucos dados que consegui reunir puramente por uma questão de integridade. Por favor, levá-la com um grão de sal bolada.

Tão perto quanto eu era capaz de determinar, webOS poderia ter um limite de tamanho de componente individual de cerca de 1MB, com um limite de tamanho de página correspondente no cache página. Eu era incapaz de persuadir If-None-Match ou If-Modified-Since cabeçalhos de solicitação de webOS, o que implica que ele não suporta ETag e Last-Modified .

Em alguns testes, verificou-se que o tamanho máximo que compõem o webOS foi maior do que 1MB, mas este foi inconsistente. Tanto quanto eu posso dizer, webOS parece ter um bug desagradável onde, após um certo ponto, possivelmente, quando o tamanho máximo de cache total é atingido-o cache apenas completamente parar de funcionar por completo até que o telefone é o poder-ciclo. Em alguns casos, até mesmo de bicicleta poder não resolver o quebra cache, então eu finalmente desisti de tentar estabelecer a causa exata do problema e os limites exactos do cache webOS.

Recomendações

Com base nesses resultados, ofereço as seguintes recomendações para qualquer desenvolvimento de aplicações web para os dispositivos testados:

  • Use far-futuro cabeçalhos de expiração de cache. Isso impedirá que o browser de ter que enviar um pedido GET condicional e irá melhorar a capacidade de cache no webOS, que não suporta ETag ou Last-Modified .
  • Pelo menos até iOS 4.0 chega ao iPad, tente limitar o tamanho dos componentes individuais para 25.6KB ou menos, não comprimido. E exortar os seus usuários para atualizar para o iPhone iOS 4.0 o mais rapidamente possível.
  • Se o seu site deve suportar iOS 3.1.3 os usuários (que é provável), se requer componentes maiores do que 25.6KB, ou se o tamanho total de todos os seus componentes é maior do que 281.6KB, considere usar o cache do aplicativo HTML5, localStorage , ou armazenamento de dados para armazenar os seus componentes. Pós Alex Kessinger Blog recentes YUI, uma introdução ao uso YUI 3 em aplicações offline , pode ser de interesse para YUI 3 desenvolvedores considerando esta abordagem.
  • Fazer seus próprios testes. Não presuma que estes resultados se aplicam a qualquer versão futura de qualquer um dos navegadores testados ou dispositivos. Usar estes resultados como um ponto de partida, mas verificar-los você mesmo antes de tomar decisões importantes baseadas em suposições sobre as limitações de cache móvel. As mudanças navegador móvel do mundo em um ritmo relâmpago, por isso esta pesquisa terá uma vida útil muito curta.

Eu fiz o meu código de teste disponível no GitHub e eu encorajo você a usá-la, garfo-la, e compartilhar o que você aprende.

Chamada de Documentação

Os fabricantes de browsers, por favor considere documentar e publicar os limites do seu navegador cache. No mundo desktop, onde esses limites são geralmente tão alto a ponto de ser um não-problema, a documentação não foi necessário. No mundo móvel, os limites de cache do navegador são informações vitais que os desenvolvedores web devem ter para criar sites de alto desempenho com recursos interessantes.

Os limites de novos recursos como localStorage e cache do aplicativo normalmente são bem documentados. Por favor, estenda este nível de documentação para o cache componente também.

Encontrar conversas: bloglines | technorati

Compartilhar e ampliar: Bookmark with del.icio.us | digg it! | reddit!

19 Comentários

  1. Grande coisa, obrigado por fazer isso, Ryan!

    Enquanto espera para os vendedores de ouvir a sua chamada para docs, seria legal ter essas verificações adicionado ao browserscope.org. Voluntários? :)

    Comentário por Stoyan - 28 de junho de 2010 #

  2. Obrigado por publicar estes resultados! Corri um estudo similar no meu próprio recentemente e também ficou impressionado pela forma como lida com Android componentes armazenados em cache, que sobreviveu mesmo depois de o telefone foi desligado e ligado novamente.

    Eu também encontrei no meu estudo, que é crucial fazer a distinção entre o cache de memória e "disco" cache, o último dos quais sobrevive um navegador completo ou reiniciar um ciclo de energia. Cache de memória reside na memória enquanto o usuário está navegando de página em página, e eu achei que o tamanho do componente para este caso de uso é muito maior (eu testei até 2mb tamanho do componente). Com cache-control, o termo futuro distante, ea remoção de Etags, navegação de página para página, nem Safari móvel Android, nem faria uma viagem de volta para o servidor. Depois de alguns minutos no entanto, ambos os navegadores faria uma viagem de volta para verificar o status de o maior componente (neste caso 2mb), eo servidor iria enviar de volta um 304, indicando que o arquivo foi ainda residem na memória do cliente. Ao longo de vários minutos, o browser continua a fazer isso para cada componente, em ordem decrescente de acordo com o tamanho do componente.

    Eu fiz a pesquisa para um papel TechPulse mas vou ver se consigo organizar melhor minhas descobertas e publicá-los.

    Um último pensamento: poderia ser interessante ver um estudo de um 1,6 Android 1.5, como infelizmente estes representam a maioria dos usuários Android. Esses usuários representam pouco mais de 50% dos usuários de Android de acordo com estatísticas oficiais atualizadas na documentação do Android (desculpe mas não posso fornecer o link agora). Pelo que eu entendo isso representa usuários muito mais em relação aos usuários do webOS, então um extensivo estudo de apenas Android 1.5/1.6 provavelmente seria mais relevante.

    Finalmente, desculpas como meu laptop está na oficina e eu estou escrevendo isso no meu iPhone. Eu provavelmente merece uma medalha ou algo assim!

    Comentário por David Calhoun - 28 de junho de 2010 #

  3. Doh, eu esqueci de mencionar que eu não acho que é um acidente que o iPhone é tão terrível com o cache (cache tradicional, em oposição às técnicas mais recentes de cache). Eu acho que eles fizeram isso propositadamente à força empurrar o envelope, assim como eles fizeram com que não suporta Flash. É basicamente forçar os desenvolvedores a aprender como usar o manifesto de cache e armazenamento local, assim como a remoção do Flash obrigou os desenvolvedores a aprender como usar CSS3 novas transformações e animações.

    Comentário por David Calhoun - 28 de junho de 2010 #

  4. Há um pequeno erro de digitação em "ambos os dispositivos testados tinham 32MB de memória flash", deve ler 32GB.

    Agradecimentos para os resultados atualizados, isso é realmente útil!

    Comentário por Nicolas - 28 de junho de 2010 #

  5. @ Stoyan: Grande idéia!

    @ David: Interessante. Eu não permitia muito tempo para passar entre os meus pedidos, então eu não notei os pedidos de validação que você descreve. Eu adoraria ver o resto das suas descobertas.

    @ Nicolas: catch Boa. Eu atualizei o post com a correção. Muito obrigado!

    Comentário por Ryan Grove - 28 de junho de 2010 #

  6. Posso confirmar a falta de um cache no webOS. Essa coisa não vai mesmo cache de uma página simples (como este) de forma confiável. : (

    Comentário por Richard - 28 de junho de 2010 #

  7. Bom trabalho Ryan

    Comentário por Philip Tellis - 28 de junho de 2010 #

  8. Artigo ótimo! Graças Ryan.

    Mas eu dei-lhe uma tentativa para o meu "3G/3GS em 3.1.3", eles pareciam corretamente cache de recursos.

    Você quis dizer "iPhone primeiro-gen", como o iPhone 2G, não é?

    Eu acho que mesmo em 3.1.3 OS, 3G/3GS comportar de maneira diferente do que 2G (primeira geração).

    Espero que isso possa ajudar.

    Comentário por Duane - 29 de junho de 2010 #

  9. Então Android tem o melhor navegador e até mesmo Flash. FU iPaid!

    Graças Ryan, o trabalho agradável e muito útil.

    Comentário por Felix Nagel - 29 de junho, 2010 #

  10. Grande trabalho, mas acho que este não é um bom teste. Os usuários raramente clicar em uma URL específica IMG ou stylesheet - em vez disso, eles navegam em páginas. Para ser mais relevante do teste deve olhar como o cache se comporta durante workflows web típico. Semelhante ao David, eu corri testes no Safari móvel que mostrou grandes recursos (> 1MB) foram armazenados em cache como eu navegar em páginas diferentes. Este é um cenário de usuário mais típico. Assim, parece equivocado dizer iPhone 3 caches apenas 52K, por exemplo. No mínimo, precisamos de uma outra coluna. É ótimo que o código está até no Github, mas seria melhor se você tivesse uma versão hospedada do teste que as pessoas pudessem experimentar. Bom trabalho - mas eu não acho que isso esclarece o que os usuários reais estão experimentando. Ping-me diretamente e podemos escopo um projeto teste mais completo.

    Comentário por Steve Souders - 29 de junho de 2010 #

  11. @ Steve: Eu adoraria ouvir mais sobre suas descobertas e suas idéias para melhorar a metodologia de testes. Enviei um e-mail.

    Comentário por Ryan Grove - 29 de junho de 2010 #

  12. "O cache de página apareceu para impor nenhum limite no tamanho das páginas individuais, felizmente cada byte caching eu joguei com ele até a memória RAM disponível estava exausto e o navegador falhou."

    É este o comportamento bater desejável? Será que os navegadores em iOS e WebOS acidente também? Só de pensar os limites de cache mais mesquinho pode ser projetado para limitar bater, eu não lembro de alguma vez ter queda safari móvel em mim.

    @ Felix, como é que esses resultados significam que o Android tem o "melhor navegador"? Há muito mais para "melhor" do que apenas o comportamento do cache.

    Comentário por Dai - 30 de junho de 2010 #

  13. @ Dai: Um acidente nunca é desejável, mas neste caso que levou componentes de 5MB ou maior para causar problemas. Mobile Safari no iPhone primeira geração tendem a ter problemas em torno de 5MB, e no 3GS em torno de 10MB, mas eu não era capaz de fazer ele bater no iPhone 4 mesmo com 20MB. Android no Nexus One tendem a começar a ter problemas em torno de 10MB. webOS apareceu para limitar o tamanho do cache de página e não queda como os outros, mas como eu escrevi no artigo, que tinha problemas de seu próprio.

    Uma vez que os testes também envolvido exibindo os dados baixados, isso teria contribuído para o uso de memória. Eu não esperaria o mesmo comportamento com os recursos que não são exibidos, ou que são simplesmente transferidos para o sistema de arquivos.

    Comentário por Ryan Grove - 30 de junho de 2010 #

  14. Em relação iOS eo iPhone, iPad e iPod Touch: Use iCab.

    O navegador tem iCab DO CACHE melhor navegador MOBILE em qualquer plataforma móvel. Ele irá armazenar páginas web inteira para que nada precisa ser re-baixado. Você pode selecionar quais sites armazenam páginas inteiras. Possui abas e outros recursos para torná-lo semelhante a um browser de desktop.

    iCab.

    Essa é a resposta a uma experiência muito gratificante web browsing.

    Comentário por James Katt - 01 de julho de 2010 #

  15. Oi! Obrigado por uma revisão. Uma vez que existem muitos outros navegadores no Android Market, além um estoque um, eu acho que faz sentido para testar outros navegadores amplamente utilizado como Dolphin [HD], por exemplo. Recentemente notei que Dolphin incluir uma opção de cache coisas para o cartão SD ...

    Comentário por Vladimir Kelman - 02 de julho de 2010 #

  16. Louvo o seu esforço e trabalho, mas também Ryan echo comentários de Steve. Ansioso para que vocês produzem.

    Nota certeza se você está ciente: O algoritmo do navegador do Android cache de disco não é realmente no repo webkit (a rede para o navegador é tratado pela camada de Java não o webkit C / C + + layer). Olhe para CacheManager.java em http://bit.ly/azhsGH . O algoritmo é mais ou menos que a cada 5 solicitações de rede se o cache de disco é maior que 6mb fica cortado. Você também pode ver o CACHE_MAX_SIZE constante que limita o tamanho dos componentes do disco em cache de 2MB, como sua pesquisa encontrado. Eu não ficaria surpreso se o acidente que você experimentou pode estar relacionado com o limite de 6MB de acabamento. (Estranhamente Eu sei disso porque uma vez eu tive que corrigir um bug cache na fonte de OS para um cliente.)

    Enfim, como eu tenho certeza que você está ciente, o que isto significa é que na prática é que pode ser difícil de reverter a engenharia dos limites de cache precisa (por exemplo, para o Android, seus resultados poderão diferir dependendo se você fosse o pedido da rede quinta ou não - quem sabe o que o algoritmo é iphone), apesar de decifrar algumas orientações utilizável como você fez aqui e pediu para publicar os fabricantes ainda é útil.

    Comentário por Ishan Anand - 02 de julho de 2010 #

  17. @ Ishan: Obrigado pela detalhes extra Android! Isso é muito útil. Steve e eu estamos atualmente trabalhando em alguns novos testes e espero ser capaz de lançar mais luz sobre isso em breve.

    Comentário por Ryan Grove - 2 de julho de 2010 #

  18. Também estou curioso para saber se o UIWebView pode-se incluir em um aplicativo iOS tem os mesmos limites como o Mobile Safari. Uma pergunta stackoverflow indica manifestar Html5 cache em um UIWebView não funciona.

    Comentário por Kevin Hakanson - 6 de julho de 2010 #

  19. Obrigado por publicar estes resultados! É basicamente forçar os desenvolvedores a aprender como usar o manifesto de cache e armazenamento local, assim como a remoção do Flash obrigou os desenvolvedores a aprender como usar CSS3 novas transformações e animações.

    Comentário por Blog de ​​Tecnologia - 18 de julho de 2010 #

Desculpe, o formulário de comentários está fechado no momento.

Hosted by Yahoo!

Copyright © 2006-2011 Yahoo! Inc. Todos os direitos reservados. Política de Privacidade - Termos de Serviço

Alimentado por WordPress sobre Yahoo! Web Hosting .