studio android android-intent otto localbroadcastmanager

studio - localbroadcastmanager android



Otto vs LocalBroadcast: (3)

Soy un gran admirador de las contribuciones de código abierto que Square ha hecho a la comunidad de Android y estaba investigando su última contribución, Otto (bus de eventos)

http://square.github.io/otto/

Profundizando más Veo que Otto usa la reflexión y no hay transmisión ordenada (un patrón donde se transmite un mensaje no consumido de un receptor al próximo receptor que escucha en el mismo tipo de evento) Otto cree en un modelo más de fuego y olvido.

Ahora, Android tiene LocalBroadcastManager (LBM) en su biblioteca de soporte v4 que cumple la misma función, aunque es más voluminosa y tiene más restricciones sobre los objetos que se pasan. Pero en el lado positivo, es compatible con la transmisión ordenada y es más similar a la transmisión normal.

Tanto Otto como LBM se encuentran dentro del mismo espacio de proceso, por lo que en términos de velocidad, supongo que ambos serían lo mismo. La única diferencia real que pude ver es que Otto te permite definir eventos personalizados y no tienes que serializar / Parcelar los objetos.

Por lo tanto, mi verdadera pregunta es cuándo usarías Otto si LBM hace las mismas cosas.

Referencias

http://nick.perfectedz.com/otto-event-system/

Usar Intents o un bus de eventos para comunicarse dentro de la misma aplicación

https://plus.google.com/107049228697365395345/posts/6j4ANWngCUY


Tanto Otto como LBM están dentro del mismo espacio de proceso, por lo que, en términos de velocidad, supongo que ambos serían lo mismo.

Descubrí que registrar eventos de Otto es bastante caro, a veces demoran más de 16 milisegundos para registrar suscriptores de eventos (¡Eso significa que se eliminan 1 FPS!). Eso es algo esperado, ya que el evento de suscripción en Otto se hace por reflexión. Mientras que para LBM, solo toma unos pocos cientos de μs solo para registrarse, que es casi 32 veces más rápido. (Resultado de traceview, Samsung Galaxy S4)

Pero, por supuesto, usar Otto puede escribir menos código, hay una compensación.


Pero en el lado positivo, admite la transmisión ordenada

Realmente no. No hay sendOrderedBroadcast() en LocalBroadcastManager , y la prioridad en el IntentFilter no parece ser utilizada. Si quiere decir "las transmisiones serán entregadas en el orden en que registré los receptores", ese podría ser el comportamiento actual, pero no hay garantía de que siga siendo así.

Tanto Otto como LBM están dentro del mismo espacio de proceso, por lo que en términos de velocidad, supongo que ambos serían los mismos

Serían similares, aunque probablemente no idénticos.

Por lo tanto, mi verdadera pregunta es cuándo usarías Otto si LBM hace las mismas cosas

Comparando esos dos, Otto tiene una API más limpia, en mi humilde opinión.

Personalmente, usaría el EventBus de greenrobot sobre cualquiera de esos, porque ofrece modelos de subprocesamiento más flexibles.


  1. otto hace el código más limpio, más pequeño
  2. otto hace las pruebas más fáciles