¿Es apropiado el acceso de archivos SQL o generales en el hilo de la interfaz de usuario principal de Android?

Question

estoy tratando de seguir las mejores prácticas de Android, por lo que en el modo de depuración enciendo la siguiente información en:

StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder().detectAll().penaltyLog().build()); //detect and log all thread violations 
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder().detectAll().penaltyLog().build()); //detect and log all virtual machine violations 

Android ahora me grita cuando intento utilizar cualquier tipo de acceso a archivos o SQL en el principal (UI) hilo. Pero veo tantas recomendaciones para usar acceso a archivos y/o SQL en el hilo principal. Por ejemplo, la actividad principal debe cargar los valores por defecto de preferencia dentro onCreate() en caso de que no se han fijado todavía:

PreferenceManager.setDefaultValues(context, resId, readAgain); 

Vaya --- que da como resultado un acceso a archivos en la primera ejecución de la aplicación, ya que se llama onCreate() en el hilo de la interfaz de usuario La única forma de evitarlo que puedo ver es comenzar un hilo separado --- que introduce una condición de carrera con otro código de UI que podría leer las preferencias y esperar que los valores predeterminados ya estén establecidos.

Piense también en servicios como el DownloadManager. (En realidad, es tan defectuoso que es inútil en la vida real, pero imaginemos que funciona por un segundo.) Si pone en cola una descarga, obtiene un evento (en el hilo principal) indicándole que la descarga ha finalizado. Para obtener realmente información sobre esa descarga (solo le da una ID de descarga), debe consultar el DownloadManager --- que implica un cursor, que le da un error si tiene activada una política estricta.

¿Cuál es la historia --- ¿está bien acceder a los cursores en el hilo principal? ¿O es algo malo, y la mitad del equipo de desarrollo de Android y los autores de libros de Android se olvidó de eso?

Answer 1

La única manera que puedo ver es comenzar un hilo separado --- que introduce una condición de carrera con otro código de UI que podría leer las preferencias y esperar que los valores predeterminados ya estén establecidos.

Después, utilice un AsyncTask, poniendo la llamada setDefaultValues() en doInBackground() y el "otro código de interfaz de usuario que puede leer las preferencias" en onPostExecute().

Para obtener realmente información acerca de esa descarga (solo le da una ID de descarga), debe consultar el DownloadManager --- que implica un cursor, que le da un error si tiene una política estricta activada.

Así que consulta el DownloadManager en una cadena de fondo.

¿Cuál es la historia --- ¿está bien acceder a los cursores en el hilo principal?

Eso depende de su definición de "fino".

En Android 1.xy la mayoría de los dispositivos 2.x, el sistema de archivos utilizado es YAFFS2, que básicamente serializa todo el acceso al disco en todos los procesos. El efecto neto es que, si bien su código puede parecer lo suficientemente funcional de forma aislada, a veces parece lento en la producción debido a otras cosas que ocurren en segundo plano (por ejemplo, la descarga de un nuevo correo electrónico).

Si bien esto es un problema menos problemático en Android 3.xy versiones posteriores (cambiaron a ext4), no hay duda de que la E/S flash sigue siendo relativamente lenta; será un poco más predecible y lenta .

StrictMode está diseñado para indicar dónde puede producirse lentitud. Depende de usted determinar cuáles son benignos y cuáles no. En un mundo ideal, los limpiarías todos; en un mundo ideal, tendría pelo.

¿O es algo malo, y la mitad del equipo de desarrollo de Android y los autores de libros de Android se olvidó de eso?

Siempre ha sido una "mala cosa".

No puedo hablar de "la mitad del equipo de desarrollo de Android". Supongo que, al principio, esperaban que los desarrolladores aplicaran su experiencia de desarrollo existente para detectar un comportamiento lento: esto no es significativamente diferente de los problemas de rendimiento en cualquier otra plataforma. Con el tiempo, han estado ofreciendo más patrones para guiar a los desarrolladores en una ruta positiva (por ejemplo, el marco Loader), además de los cambios en el sistema (por ejemplo, YAFFS2-> ext4) para que esto no sea un problema. En parte, intentan abordar los lugares donde Android presenta distintos desafíos relacionados con el rendimiento, como la interfaz de usuario de subproceso único.

Del mismo modo, no puedo hablar de todos los autores de libros de Android. Ciertamente no me centré en los problemas de rendimiento en las primeras ediciones de mis libros, ya que me estaba centrando en las características y funciones de Android. Con el tiempo, he agregado más consejos en estas áreas. También contribuí con el código fuente abierto relacionado con estos temas. En 2012, haré revisiones masivas a mis libros y crearé más proyectos de fuente abierta para continuar abordando estos problemas. Sospecho, dado su tono, que yo (y probablemente otros) son fracasos completos a sus ojos en este aspecto, y sin duda es bienvenido su opinión.