O que o processo zigoto ainda está fazendo no Android L?
Estou tentando descobrir as diferenças específicas nos tempos de execução de Dalvik e ART. Sei que o ART não usa mais a Dalvik VM, no entanto, uma das primeiras coisas que notei após a instalação da visualização do Android L foi que o processo zygote ainda está em execução. Se eles realmente se livrassem da VM Dalvik, isso não tornaria o processo do zigoto inútil? Além disso, ao inspecionar o código fonte liberado via AOSP, uma grande parte do Dalvik ainda permanece.
Difícil saber, é uma versão para desenvolvedores e FAR completa. No momento, há muito Kitkat / Jellybean costurado nele apenas para fazê-lo funcionar e inicializar.
Sendo ainda uma " pré-visualização do desenvolvedor ", pode de fato não fazer muito sentido especular (embora eu siga a explicação de Dan). Pode ser como Dan descreveu, ou pode ser um "sobra" ainda não "totalmente obsoleto". Quando ele ainda roda no L-Release, isso é diferente.
O Zygote não está realmente ligado ao Dalvik, é apenas um processo de inicialização. O zigoto é o método que o Android usa para iniciar aplicativos. Em vez de ter que iniciar cada novo processo do zero, carregando todo o sistema e a estrutura do Android novamente toda vez que você deseja iniciar um aplicativo, ele faz esse processo uma vez e depois pára nesse ponto antes que o Zygote faça algo específico do aplicativo . Em seguida, quando você deseja iniciar um aplicativo, o processo do Zygote se bifurca e o processo filho continua de onde parou, carregando o próprio aplicativo na VM.
Embora esse método tenha sido originalmente projetado para Dalvik, não há razão para que o ART não se comporte exatamente da mesma maneira. Ele não precisa compilar aplicativos JIT enquanto eles estão em execução, mas ainda tem muitas coisas Java independentes de aplicativo para carregar (ou seja, toda a estrutura do Android); portanto, faz sentido usar o mesmo fork quando método carregado para iniciar novos processos.
É natural em um projeto tão grande que existam outras sobras da Dalvik que ainda são úteis no mundo pós-Dalvik; portanto, não se surpreenda que haja outro código que foi originalmente escrito para fazer parte ou trabalhe com a Dalvik, que ainda existe para o ART usar.
Corresponde à minha compreensão do Zygote (sendo um não-dev). Na "visão do usuário", provavelmente torna mais fácil pensar no Zygote como "servidor de aplicativos", agindo como uma "camada de abstração" entre os aplicativos e o SO (de alguma forma, como o HAL faz para abstrair o hardware): não importa o que é "abaixo" (Dalvik ou ART), a interface lida com "coisas"?
Talvez seja mais fácil pensar no Zygote como um servidor de aplicativos, mas não é uma descrição muito precisa. É apenas a parte do sistema operacional que inicia os aplicativos e está muito no lado do sistema operacional.
Obrigado, pelo menos meu "entendimento básico" estava correto (eu sei que "servidor de aplicativos" não é preciso, mas é mais fácil de entender por um "usuário normal" - então vamos transformá-lo em " serviço de aplicativo ", para levar adiante o lado do SO;)
O que existe no código-fonte não é "sobra", e não estamos na era pós-Dalvik! O código de bit Dalvik ainda é o IR que está sendo usado. Mesmo com a configuração mais alta, nem tudo é compilado pela AOT, e ainda existem algumas coisas que precisam ser interpretadas. Portanto, para estes, existe o DalvikVM . Além disso, dispositivos com pouco armazenamento, usarão menos AOT e mais interpretações. Por fim, o zygote fornece montes de classes usadas com freqüência, que podem economizar espaço, pois podem ser compartilhadas entre vários aplicativos.
@ Paschalis, você está confundindo o JIT compilando com o DalvikVM. Só porque as versões mais recentes da compilação ART do JIT (just-in-time) não significa que Dalvik ainda está por aí. O Oracle Java também faz a compilação JIT, não significa que ele use Dalvik