tiempo sistemas resueltos respuesta procesos proceso plazo planificador planificacion operativos fcfs estados ejercicios ejemplos corto contexto cambio algoritmos android opencv android-ndk profiling android-traceview

android - sistemas - planificador a corto plazo



¿El cambio de contexto consume mucho tiempo? (1)

He estado teniendo problemas con una aplicación (que usa tanto Java y C ++ como OpenCV), que parece ser muy inconsistente en el tiempo que lleva realizar varias tareas. Para ayudar a diagnosticar esto, hice una función en java (llamada one_off_speed_test() ) que no hizo más que una serie de problemas matemáticos enteros en un bucle que dura aproximadamente medio segundo, y luego imprime el tiempo llevado al registro. Si llamo a esta función repetidamente desde onCreate() , el tiempo empleado para cada llamada es muy constante (+ = 3%), pero si lo llamo desde dentro onCameraFrame() , una función que OpenCV llama cuando tiene una imagen lista desde la cámara, el tiempo requerido para la prueba de matemáticas en cada fram varía hasta un factor de dos. Decidí probar la muestra de ejecución en eclipse / DDMS y ver si podía averiguar qué estaba pasando. Vi que cuando hice clic en one_off_speed_test() , se enumeraron los padres e hijos de esa función, junto con una línea que decía " (cambio de contexto) ". Luego, en esa fila, debajo de una columna etiquetada como " Incl Real Time ", dice "66%". Ahora no soy muy experto en el uso de DDMS, y solo tengo una idea nebulosa sobre el cambio de contexto, pero por la descripción hasta ahora, ¿parece que tengo un problema con el cambio de contexto que lleva mucho tiempo? O estoy malinterpretando la salida DDMS.


El interruptor de contexto describe el tiempo empleado para ejecutar otros hilos. Entonces, cuando su función es llamada desde onCameraFrame() , comparte CPU con otros hilos, no necesariamente hilos que pertenecen a su aplicación.

Vea también las respuestas https://.com/a/10969757/192373 , https://.com/a/17902682/192373

En el ejemplo publicado, onCameraFrame() gastó 14.413665 segundos en el reloj de pared, de los cuales 4.814454 segundos fueron utilizados por one_off_speed_test() (presumiblemente, para 10 fotogramas), y 9.596984 segundos pasaron esperando otros subprocesos. Esto tiene sentido, porque la devolución de llamada onCameraFrame() compite por el recurso de la CPU con el servicio de la cámara, que se ejecuta en un proceso del sistema por separado.