¿Qué sigue haciendo el proceso de cigoto en Android L?

Estoy tratando de descubrir las diferencias específicas en los tiempos de ejecución de Dalvik y ART. Me doy cuenta de que ART ya no usa la VM de Dalvik; sin embargo, una de las primeras cosas que noté después de instalar la vista previa de Android L fue que el proceso de zygote aún se está ejecutando. Si realmente se deshicieron de la VM de Dalvik, ¿no haría eso que el proceso de cigoto fuera inútil? Además, al inspeccionar el código fuente publicado a través de AOSP, aún queda una gran parte de Dalvik.

Difícil de saber, es un lanzamiento de desarrollador y LEJOS de estar completo. Hay mucho Kitkat / Jellybean cosido en este momento solo para que funcione y arranque.
Siendo todavía una " vista previa para desarrolladores ", podría no tener mucho sentido especular (aunque sigo la explicación de Dan). Puede ser como lo describió Dan, o podría ser un "sobrante" que aún no está "totalmente obsoleto". Cuando todavía se ejecuta en L-Release, eso es algo diferente.

Respuestas (1)

Zygote no está realmente relacionado con Dalvik, es solo un proceso de inicio. Zygote es el método que utiliza Android para iniciar aplicaciones. En lugar de tener que iniciar cada nuevo proceso desde cero, cargar todo el sistema y el marco de Android de nuevo cada vez que desea iniciar una aplicación, realiza ese proceso una vez y luego se detiene en ese punto, antes de que Zygote haya hecho algo específico de la aplicación. . Luego, cuando desea iniciar una aplicación, el proceso de Zygote se bifurca y el proceso secundario continúa donde lo dejó, cargando la aplicación en la máquina virtual.

Aunque este método fue diseñado originalmente para Dalvik, no hay razón para que ART no se comporte exactamente de la misma manera. No tiene que compilar aplicaciones JIT mientras se ejecutan, pero todavía tiene muchas cosas de Java independientes de la aplicación para cargar (es decir, todo el marco de trabajo de Android), por lo que tiene sentido usar la misma bifurcación cuando: método cargado para iniciar nuevos procesos.

Es natural que en un proyecto tan grande haya otros sobrantes de Dalvik que aún son útiles en un mundo posterior a Dalvik, por lo que no debería sorprenderse de que haya otro código que se escribió originalmente para ser parte de o para trabajar con Dalvik, que todavía está disponible para que ART lo use.

Coincide con mi comprensión de Zygote (siendo un no desarrollador). Desde la "vista del usuario", probablemente sea más fácil pensar en Zygote como un "servidor de aplicaciones", que actúa como una "capa de abstracción" entre las aplicaciones y el sistema operativo (de alguna manera, como lo hace HAL para abstraer el hardware): no importa ¿Qué hay "abajo" (Dalvik o ART), la interfaz se ocupa de "cosas"?
Puede que sea más fácil pensar en Zygote como un servidor de aplicaciones, pero no es una descripción muy precisa. Es solo la parte del sistema operativo que inicia las aplicaciones, y está muy en el lado del sistema operativo del límite entre la aplicación y el sistema operativo.
Gracias, así que al menos mi "comprensión básica" era correcta (soy consciente de que "servidor de aplicaciones" no es exacto, pero es más fácil de entender para un "usuario normal", así que hagámoslo " servicio de aplicaciones ", para llevarlo más adelante el lado del sistema operativo;)
Lo que existe en el código fuente no son "restos", ¡y no estamos en la era posterior a Dalvik! El código de bits de Dalvik sigue siendo el IR que se está utilizando. Incluso con la configuración más alta, no todo está compilado por AOT, y todavía hay algunas cosas que deben interpretarse. Entonces, para estos, existe DalvikVM . Además, los dispositivos con poco almacenamiento utilizarán menos AOT y más interpretación. Por último, zygote inicia sus montones de clases de uso frecuente, lo que puede ahorrar espacio, ya que se pueden compartir entre varias aplicaciones.
@Paschalis, está confundiendo la compilación JIT con DalvikVM. El hecho de que las versiones más nuevas de la compilación ART do JIT (justo a tiempo) no significa que Dalvik siga existiendo. Oracle Java también compila JIT, no significa que use Dalvik
edite mi comentario anterior: b̶i̶t̶c̶o̶d̶e̶ -> bytecode. D̶a̶l̶v̶i̶k̶V̶M̶-> ART's Interpreter. DalvikVMno se usa Pero su intérprete y JIT se fusionan en ART.
DalvikVM solía hacer interpretación y JIT. ART hace AOT, JIT (>=Turrón) e interpretación. Una compilación (ya sea JIT o AOT) toma Dalvik bytecode(Oracle toma el código de bytes de Java) y lo transforma. Un APK contiene solo el código de bytes dalvik, y cuando dex2oatlo compila, los filtros deciden qué AOT (y en tiempo de ejecución, los perfiles deciden qué JIT).
¿Qué sigue haciendo el proceso de cigoto en Android L?
RespuestasAquíPolítica de privacidad1y, 0v