2012-02-09 6 views
5

He creado una instancia de controlador en el hilo principal de ui (mUIHandler) y de un hilo de trabajo (otro hilo) cuando intento ejecutar el método de ejecución de el método runnable run se ejecuta casi 9 de cada 10 veces, pero hay una vez en que no se ejecuta.handler.post (ejecutable) no siempre ejecuta el método de ejecución en android

mUIHandler.post (uiRunnable) -> lo hace no siempre garantiza para ejecutar el método de ejecución presentes en el ejecutable?

Incluso agregué métodos de registro para verificar y pude ver que los registros hasta la invocación del método de publicación se ejecutan pero los registros del método de ejecución no se muestran.

¿Cómo funciona la publicación (ejecutable) internamente? ¿garantiza que el hilo ui (hilo con el controlador) ejecutará esto tan pronto como se invoque la publicación?

Cualquier ayuda sería apreciada.

Gracias!

+4

Código postal relacionado con el problema. – kosa

+1

@thinksteep intentará analizar la sugerencia dada por mattc a continuación para ver si puedo hacer algo al respecto. Estoy evitando publicar el fragmento de código aquí, ya que tiene más de 500 líneas de código. ¡Gracias! – Deva

Respuesta

6

Nunca he visto un controlador que no ejecute correctamente el ejecutable publicado. Algunas cosas para investigar:

  1. ¿Hay alguna lógica que pueda dar lugar a una condición de carrera entre los datos con los que podría estar interactuando el subproceso mientras se ejecuta el subproceso de UI-thread?
  2. ¿Tiene un try/catch en cualquier lugar que podría estar comiendo de forma silenciosa una excepción?

Mi voto (sin haber visto su código) es que probablemente sea # 1. No sería la primera persona en ser víctima de condiciones de carrera difíciles de rastrear como resultado de una lógica concurrente.

+0

Gracias Mattc por la respuesta voy a verificar para ver si hay una posible condición de carrera. (Espero haber podido localizarla). Se actualizará. – Deva

+1

Gracias @Mattc era la condición de carrera que lo estaba haciendo. Afortunadamente fue capaz de encontrar la causa. De hecho, un buen aprendizaje. – Deva

+0

Me alegra que lo haya encontrado. La lógica de subprocesos es notoriamente delicada y difícil de depurar. – MattC

10

También me he encontrado con este problema en Android 2.2, en mi caso tanto Runnables como Messages se usaban con el mismo controlador.

Después de mirar el código fuente del controlador, resulta que eliminar mensajes con un valor "que" de 0 también elimina todos los ejecutables ejecutables. Esto sucede porque en la clase Handler un Runnable se publica internamente como un mensaje con un valor 'what' de cero, que se eliminan mediante cualquier llamada al removeMessages(0). Por lo tanto, evite usar cero como id de mensaje.

+0

Si solo hubiera dos respuestas preferidas. No tengo idea de cuánto tiempo me salvaste con esta respuesta, ¡pero es mucho tiempo! –

Cuestiones relacionadas