2012-09-04 4 views
1

Parfois, il est nécessaire de contourner la limite de mémoire de segment de l'application et d'en utiliser plus qu'elle ne le permet.Utilisation de la mémoire native via java

J'ai pensé à une solution qui inclura un mécanisme de mise en cache qui stockera des octets dans la mémoire native (pas dans la mémoire de tas, mais dans la mémoire non gérée).

Bien sûr, je prendrai en compte la taille maximale disponible du système.

Alors, sachant un peu direct buffers, j'ai utilisé ce pour stocker un tableau d'octets dans la mémoire native:

final ByteBuffer nativeBytes=ByteBuffer.allocateDirect(bytes.length); 
    nativeBytes.put(bytes); 

Cependant, il semble que sur Android, la mémoire utilisée pour cela est utilisé dans le tas et pas dans la mémoire native.

Que se passe-t-il? Y at-il une alternative facile pour stocker & chargement des données de la mémoire native?

+0

Il n'existe pas de "mémoire native"; la mémoire n'a aucune compréhension de native vs bytecode. Cela rend votre question très floue. – mah

+0

il y a de la mémoire gérée et de la mémoire non gérée. la mémoire gérée a une limite d'environ 48 Mo et lorsque vous la passez, vous obtenez une exception de MOO. La mémoire non gérée correspond à peu près à la taille de la RAM de l'appareil, mais vous devez prendre soin de la libérer. une telle chose est disponible lorsque vous utilisez NDK ou OpenGL. –

+0

Je n'appellerais pas cela facile (donc digne d'un commentaire peut-être pas une réponse), mais à partir de votre description, il semble que vous pourriez créer une classe avec des méthodes natives, où ces méthodes natives effectuent malloc() et free(). Si votre description de la façon dont DalvikVM gère la mémoire est correcte, cela devrait vous permettre de contourner la vérification DVM (en supposant qu'Android ne prenne pas de mesures actives pour l'empêcher). Le problème à résoudre serait alors de savoir comment accéder à cette mémoire à partir de Java. – mah

Répondre

0

Vous pouvez implémenter quelque chose en utilisant NDK qui va allouer de la mémoire dans le tas natif pour vous et communiquer avec lui en utilisant JNI. Les parties natives sont implémentées en C et utilisent les appels malloc() pour allouer de la mémoire dans le tas natif. Cependant, vous serez toujours soumis au maximum de tas par processus.

Voici une autre alternative. Au lieu d'essayer d'utiliser le tas natif dans votre propre processus, utilisez simplement le dalvik-heap dans un autre processus.

Créez un service et exécutez le service dans un autre processus. Vous pouvez envoyer des données entre votre service et le reste de votre application. Les limites de tas sont par processus, ce qui double efficacement la quantité de mémoire que votre application peut utiliser.

Bien sûr, cela peut ne pas aider dans votre cas particulier, mais il est bon de savoir que cette option est disponible.

+0

mallocs sont également soumis à la limite de tas ?! Non seulement j'ai entendu dire que c'est le contraire, mais pourquoi le suggérez-vous si cela n'aide pas? aussi, n'y a-t-il pas un moyen plus facile de le faire? l'utilisation de plusieurs processus peut ne pas aider, car j'ai besoin d'un accès relativement rapide aux données, et l'utilisation d'intentions pour cela n'est pas vraiment recommandée, en particulier lors de l'utilisation de tableaux de grands octets. Conseil cool cependant. –

+0

mallocs sont soumis aux limites de tas natif, pas les limites de tas dalvik (pour autant que je sache, mais je n'ai pas vérifié réellement cela - désolé si elle est incorrecte).Vous pouvez obtenir des données d'un autre processus en utilisant des appels synchrones aux services liés assez rapidement. J'ai construit des applications qui fonctionnent comme ça et ça marche très bien. –

+0

Je ne vous ai probablement pas compris: quelles sont les limites du tas natif? à propos du service, est-ce aussi rapide que d'obtenir les données du même processus? –