2011-09-06 9 views
6

Sto lavorando allo sviluppo di un sistema di cartelle cliniche utilizzando OpenMRS come back-end per Android. OpenMRS dipende da alcune librerie seriamente pesanti, tra cui Hibernate e Spring.Porting java server per Android

"Dexing" l'intera applicazione OpenMRS genera un file troppo grande anche per il formato di classi classes.dex di Android (questo limite di dimensioni è già ben documentato). Per ovviare a questo, sto attualmente lavorando alla creazione di più file dex dalle dipendenze e caricandoli durante il runtime utilizzando il programma di caricamento dex di Android.

A causa del modo in cui verrà utilizzata la versione mobile del server, le richieste effettive di elaborazione saranno molto basse nonostante le enormi dipendenze. Non sto cercando di eseguire un server aziendale sul mio telefono qui.

Prima di passare più settimane del mio tempo a cercare di ingegnerizzare questo, volevo solo chiedere alla comunità di sviluppatori: questa strategia è solo un sogno irrealizzabile? Se caricassi tutte queste librerie, l'intero binario verrà caricato nella RAM e interromperà il sistema? C'è un buon modo per ottimizzare tale applicazione? C'è qualche ovvio problema o soluzione che mi manca qui?

+3

A prima vista, direi che il sogno di avere Hibernate e Spring in esecuzione su Android non è realistico. Il semplice problema di avere abbastanza RAM per tutte queste dipendenze ti blocca completamente nelle tue tracce. – Prime

+1

Hai visto http://android-developers.blogspot.com/2011/07/custom-class-loading-in-dalvik.html? La parte difficile qui sembra essere che i vari file dex non possono semplicemente chiamare tra di loro senza codice aggiuntivo o pre-elaborazione. (Supponendo che ci sia abbastanza memoria per fare ciò che ti serve.) –

+4

Questo sicuramente grida per "client/server". Un problema significativo con questa app sarà quello di assicurare la privacy (regolamenti HPIAA, ecc.) – paulsm4

risposta

1

La risposta breve è: no.

La risposta lunga è che la maggior parte dei dispositivi assegna ancora una quantità relativamente piccola (tra 40-128 mega di RAM) di memoria a ciascun heap. Hai davvero bisogno di pensare all'architettura dell'app in modo che la maggior parte della logica e quindi le librerie e il codice dei pesi massimi risiedano ancora su un server e l'app mobile stia semplicemente leggendo i dati leggeri (JSON?) Dal server per la visualizzazione. I dispositivi dovrebbero in realtà utilizzare solo elementi nativi come i dati sulla posizione e fornire un'interfaccia all'utente coerente con il resto dell'universo Android. Oltre a ciò, dovresti cercare dei modi per mantenere il più possibile la logica dell'app nativa possibile. Se non altro per tenerlo più sicuro. Le applicazioni Android di reverse engineering sono banali e più continuate sul lato server, più sarete sicuri.

+0

Grazie Matt, sono arrivato a una conclusione simile dopo aver seguito i commenti. Sembra che dovrò fare più ricodifica della fonte originale di quanto pensassi. Avendo effettivamente registrato la RAM che impiega sul mio computer, mi sono reso conto che qualcosa di meno di 1 GB non avrebbe funzionato! Ma sfortunatamente l'obiettivo è quello di avere l'intero server in esecuzione sul tablet, poiché lo stiamo inviando a aree impoverite che non dispongono di accesso a Internet. Immagino che questo richiederà un po 'di ingegneria REALE. Sospiro. – Nick