Portuguese, Brazilian subtitles

← 04-02 Memory,_GC,_and_Performance

04-02 Memory,_GC,_and_Performance

Get Embed Code
13 Languages

Showing Revision 6 created 01/03/2016 by QA_SP_12_PT_BR.

  1. Agora que o nosso código
    está rodando rápido e perfeito,
  2. vamos falar mais sobre memória e
    como afeita a desempenho do sistema.
  3. Muitas linguagens de programação que são
    conhecidas por ser próximas do hardware,
  4. ou melhor, de alto desempenho,
    como C, C++,
  5. e Fortran, fazem os programadores
    gerir a memória.
  6. Programadores são responsáveis
  7. por alocar um bloco de memória
    e então no futuro desalocar
  8. quando ele acabou de usar.
  9. Desde que você defina quando
    e a quantidade de memória para desalocar,
  10. toda a qualidade de gerir a memória
    depende das suas habilidades e eficiência.
  11. É muita responsabilidade!
  12. E na realidade, programadores
    não são sempre os melhores em manter
  13. o controle dos bytes e memórias.
  14. Pense nisso,
    o desenvolvimento de produto é um confuso
  15. e louco processo e geralmente a memória
    não é liberada adequadamente.
  16. Esses blocos de memória não liberados,
    são chamados de vazamento e eles ficam
  17. monopolizando recursos, que poderiam ser
    melhor aproveitados em outro lugar.
  18. Para diminuir esse caos, estresse
    e às vezes perda de dinheiro,
  19. causado pelo vazamento, a linguagem
    de gerenciamento de memória foi criada.
  20. O tempo de execução dessa linguagem
    controla as alocações de memória e
  21. libera a memória para o sistema
    quando não está mais sendo usada
  22. pelo aplicativo, tudo sem nenhuma
    intervenção do programador.
  23. Essa arte, ou melhor, ciência de recuperar
    memória em um ambiente de memória
  24. gerenciada é conhecido como
    coletor de lixo. Esse conceito foi criado,
  25. por John McCarthy em 1959 para solucionar
    problemas na programação de linguagem LISP.
  26. Os princípios básicos da coleta de lixo,
    são as seguintes:
  27. 1 - Achar dados de objetos no programa
    que não podem ser acessados no futuro
  28. por exemplo, qualquer memória que
    não é mais referenciada por um código.
  29. E, 2 - recuperar os recursos
    usados por esses objetos.
  30. Conceito simples na teoria, mas
    fica bem complexo uma vez que
  31. você tem 2 milhões de linhas de códigos
    e quatro giga para alocar.
  32. Pense sobre a coleta de lixo,
    pode ser realmente disforme,
  33. se você tiver 20.000 alocações
    no seu programa agora
  34. quais não serão mais necessárias?
  35. Ou ainda, quando você deve
    rodar a coleta de lixo
  36. para liberar a memória
    que não está sendo usada?
  37. São perguntas difíceis, e
  38. ainda bem que temos quase
    50 anos de inovações que melhoraram
  39. e é por isso que o coletor de lixo
    no Android Runtime,
  40. é um pouco mais sofisticado
    que o modelo original.
  41. Ele foi construído para ser mais rápido
    e menos invasivo possível.
  42. Efetivamente, os heaps de memória
    nos androids são segmentadas em espaços,
  43. baseado no tipo de alocação
  44. e o quão melhor o sistema consegue alocar
    para futuros eventos GC.
  45. Quando um novo objeto é alocado,
  46. essas características são levadas
    em consideração para saber em qual espaço
  47. deve ser alocado, dependendo da
    versão do android em uso.
  48. Um fato importante.
  49. Cada espaço tem um conjunto de tamanho
  50. quando os objetos são alocados,
    nós analisamos os espaços combinados
  51. e quando um espaço aumenta, o sistema
    precisa executar uma coleta de lixo
  52. na tentativa de liberar a memória
    para alocações futuras.
  53. Agora, vale frisar que
    cada coleta de lixo será diferente,
  54. dependendo da versão do Android usada.
  55. Por exemplo, em Dalvik, muitos eventos
    são relevantes, significando
  56. que qualquer código gerenciado que esteja
    rodando vai parar até acabar a coleta.
  57. O que pode ser problemático quando
    esses GC demoram mais que o normal
  58. ou quando vários
    acontecem ao mesmo tempo
  59. pois irão tomar uma parte
    do seu tempo de sistema.
  60. E para ficar claro,
  61. os desenvolvedores de Android trabalharam
    para assegurar que esses eventos
  62. fossem os mais rápido possíveis para
    reduzir as interrupções, com isso
  63. eles ainda podem causar problemas
    nos aplicativos do seu código.
  64. Primeiro, entenda que quanto mais tempo
    seu aplicativo perde fazendo GC,
  65. em um determinado período, menos tempo ele
    tem para manter os processos necessários,
  66. abaixo de 16 milissegundos
    da barreira de renderização.
  67. Então se existem vários ou longos GC,
    que acontecem um após o outro
  68. pode aumentar o tempo de processo
    do sistema em mais de 16 milissegundos
  69. da barreira de renderização, levará a uma
    inutilização ou atraso para os usuários.
  70. Segundo, entenda que o fluxo de código
    pode estar fazendo o tipo de trabalho
  71. que obriga o processo GC a ocorrer
    mais vezes, ou que durem mais que o normal.
  72. Por exemplo, se você está alocando
    as reservas de objetos na parte oculta
  73. do loop que roda por mais tempo,
    então você estará poluindo sua
  74. memória heap com objetos e
    acabara acontecendo vários GC
  75. continuamente, por conta
    dessa pressão da memória adicional.
  76. E mesmo estando em um
    ambiente gerenciável de memória,
  77. vazamentos de memória podem acontecer.
  78. Porém, eles não são tão fáceis de criar
    como as outras linguagens.
  79. Esses vazamentos podem poluir seu heap
    com objetos que não serão liberados
  80. durante o processo de GC, reduzindo
    efetivamente o total de espaço livre
  81. forçando que mais processos GC
    sejam iniciados, várias vezes.
  82. Então é isso,
  83. se você quiser reduzir o total de eventos
    GC que acontecem num período,
  84. você vai precisar focar em aperfeiçoar
    a memória dos seus aplicativos.
  85. Pela perspectiva do código,
    pode ser difícil de achar os problemas,
  86. como esses de acontecerem,
  87. mas ainda bem, o SDK do Android
    tem ferramentas eficazes a sua disposição.
  88. Vamos dar uma olhada.