GREF que aumenta / que disminuye en servicio multi-hilo (aidl) – qué significa?

Tengo una actividad androide y un servicio implementado usando aidl. Funciona como un campeón, tengo una configuración de devolución de llamada para pasar algunas notificaciones de hilo a la interfaz de usuario, y que parece funcionar bien, con la excepción de un montón de

GREF ha aumentado a 101, 201, 301, 401, 501, etc, y el GREF ha disminuido. Hice una cierta búsqueda en línea y encontré que tiene que hacer w / referencias globales.

08-17 02:31:19.735: DEBUG/dalvikvm(2558): GREF has increased to 301 ... 08-17 02:31:25.823: DEBUG/dalvikvm(2558): GREF has increased to 401 ... 08-17 02:31:36.772: DEBUG/dalvikvm(2558): GREF has increased to 501 ... 08-17 02:31:42.694: DEBUG/dalvikvm(2558): GREF has increased to 601 ... 08-17 02:31:48.695: DEBUG/dalvikvm(2558): GREF has increased to 701 ... 08-17 02:31:59.883: DEBUG/dalvikvm(2558): GREF has decreased to 599 08-17 02:31:59.912: DEBUG/dalvikvm(2558): GREF has decreased to 499 08-17 02:31:59.912: DEBUG/dalvikvm(2558): GREF has decreased to 399 08-17 02:31:59.912: DEBUG/dalvikvm(2558): GREF has decreased to 299 08-17 02:31:59.912: DEBUG/dalvikvm(2558): GREF has decreased to 199 

Hice un poco de búsqueda y ver que la mayoría de las observaciones sobre esto son bastante antiguos. Mi preocupación es que estoy implementando mi cliente / servicio correctamente, y quería saber cómo puedo rastrear lo que está causando que el GREF aumente. Cualquier sugerencias / sugerencias son bienvenidas. ¡Gracias!

Flujo Básico del Programa

 Client -> Creates Callback Client -> Starts Service Service -> Inits & Starts CountDownTimer Service.CountDownTimer.onFinish() -> DownloadAndParse() DownloadAndParse() -> initialize new saxRequest(), new Handler for this request. Service.Handler->beginBroadcast() Client.CallbackStub -> updateUI() Client.CallbackStub -> service.startCountDownTimer() 

Esperemos que esto tenga sentido. Yo fijaría el código aquí, pero hay tanto en tan muchos diversos archivos. Pensé que iba a tratar de poner el flujo hasta ver si hay algo deslumbrante … Lo único que puedo ver es tal vez volver a utilizar el saxRequest () en lugar de crear una nueva instancia … Voy a tratar de que ahora en realidad , Pero me gustaría saber sobre el impacto del GREF y la Garbage Collection.

Estas son referencias globales de JNI. Si no está escribiendo código nativo, no tiene control directo sobre ellos. Los mensajes de registro aparecen cuando CheckJNI está habilitado, que está activado de forma predeterminada para las compilaciones de ingeniería y el emulador.

Los mensajes sólo significan que el código nativo le está diciendo a la VM que no está permitido descartar algunos objetos. En esencia, las referencias globales son una forma en que el código nativo agrega referencias al conjunto raíz del GC. Asumiendo que el código nativo está escrito correctamente, las refs globales se borrarán cuando el código nativo ya no las necesite.

La única causa de preocupación sería si el número de referencias globales continúa subiendo, ya que eso sugeriría una fuga de referencia global. Dado que la máquina virtual no puede liberar los objetos, una fuga de ref global hará que la máquina virtual se quede sin memoria. Para ayudar a identificar estos problemas, se coloca un límite en el número de referencias globales cuando CheckJNI está habilitado (el límite actual es 2000).

  • Método de servicio de Android llamado en hilo diferente. ¿Sigue funcionando en el hilo principal?
  • ¿Por qué los servicios de android se ejecutan en el hilo de la interfaz de usuario?
  • Sincronización entre servicio local con un hilo y una actividad
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.