Portando servidor java a Android

Estoy trabajando en el desarrollo de un sistema de registros médicos usando OpenMRS como back-end para Android. OpenMRS depende de algunas bibliotecas de peso pesado, incluidas Hibernate y Spring.Portando servidor java a Android

"Dexing" toda la aplicación OpenMRS genera un archivo que es demasiado grande incluso para el formato de archivo classes.x de Android (este límite de tamaño ya está bien documentado). Para evitar esto, actualmente estoy trabajando para crear múltiples archivos dex de las dependencias y cargarlos durante el tiempo de ejecución usando el cargador de clases dex de Android.

Debido a la forma en que se usará la versión móvil del servidor en la práctica, las demandas reales de procesamiento serán muy bajas a pesar de las enormes dependencias. No estoy tratando de ejecutar un servidor empresarial en mi teléfono aquí.

Antes de dedicar la mayor parte de mi tiempo a tratar de diseñar esto, solo quería preguntarle a la comunidad de desarrolladores: ¿es esta estrategia solo una quimera? Si cargué todas estas bibliotecas, ¿se cargará todo el binario en la RAM y se romperá el sistema? ¿Hay una buena manera de optimizar tal aplicación? ¿Hay algún problema obvio o solución que me falta aquí?

Fuente

2011-09-06 Nick

A primera vista, diría que el sueño de tener Hibernate y Spring funcionando en Android no es realista. El simple problema de tener suficiente RAM para todas estas dependencias te detiene en seco. – Prime

Has visto http://android-developers.blogspot.com/2011/07/custom-class-loading-in-dalvik.html? La parte difícil aquí parece ser que los diversos archivos dex no pueden simplemente llamar entre sí sin código adicional o preprocesamiento. (Suponiendo que hay suficiente memoria para hacer lo que necesita) –

Esto definitivamente clama por "cliente/servidor". Un problema importante con esta aplicación será asegurar la privacidad (regulaciones de HPIAA, etc.) – paulsm4

La respuesta corta es: Do not.

La respuesta larga es que la mayoría de los dispositivos solo asignan una cantidad relativamente pequeña (entre 40-128 megas de RAM) de memoria a cada pila. Realmente DEBES pensar en la arquitectura de la aplicación para que la mayor parte de la lógica y, por lo tanto, las bibliotecas y el código pesado aún residan en un servidor y la aplicación móvil simplemente esté leyendo datos livianos (JSON?) Del servidor para mostrar. Los dispositivos solo deberían utilizar elementos nativos, como los datos de ubicación, y proporcionar una interfaz para el usuario que sea coherente con el resto del universo de Android. Más allá de eso, deberías buscar maneras de mantener la mayor cantidad de lógica posible fuera de la aplicación nativa. Si no es por otra razón que para mantenerlo más seguro. Las aplicaciones de ingeniería inversa de Android son trivial y cuanto más se mantenga en el lado del servidor, más seguro será.

Fuente

2011-09-12 20:53:55 MattC

Gracias Matt, llegué a una conclusión similar después de seguir los comentarios. Parece que voy a tener que hacer más recodificación de la fuente original de lo que había pensado. Habiendo grabado la memoria RAM que toma en mi propia computadora, ¡me di cuenta de que nada menos que 1GB no funcionaría! Pero, desafortunadamente, el objetivo es que todo el servidor se ejecute en la tableta, ya que lo estamos enviando a áreas empobrecidas que no tienen acceso a Internet. Supongo que esto necesitará algo de ingeniería REAL. Suspiro. – Nick

Respuesta

Cuestiones relacionadas