Return to Video

04-02 Memory,_GC,_and_Performance

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

04-02 Memory,_GC,_and_Performance

more » « less
Video Language:
English
Team:
Udacity
Project:
ud825 - Android Performance
Duration:
04:47

Portuguese, Brazilian subtitles

Revisions Compare revisions