La machine s40 a une meilleure mémoire pour les jeux et la science populaire.

Il existe deux principaux types d'utilisation de la mémoire, à savoir les programmes et les ressources. ·La classe du programme sera compilée dans un fichier de bytecode de classe et chargée dans la mémoire au démarrage du MIDlet, et elle sera ajoutée en une seule fois. C'est-à-dire que plus il y a de classes dans MIDlet, plus un programme de classe unique est long et plus il y a de constantes de chaîne et de données dans la classe, plus le fichier de classe compilé sera volumineux et plus il occupera de mémoire après le chargement. J'utilise souvent la méthode Runtime dans le constructeur de la classe MIDlet pour vérifier la quantité de mémoire occupée par l'ensemble du programme après le démarrage du MIDlet. //Méthode d'optimisation : 1. Le programme MIDlet est écrit en deux classes pour réduire l'utilisation de la mémoire, mais au détriment des fonctionnalités POO de Java. Cet inconvénient sera particulièrement évident lorsque le programme est relativement important. De plus, CoCoMo a déjà rencontré une situation dans laquelle une seule classe était trop grande et le temps de chargement était trop long, ce qui violait la limite de 6 secondes indiquée sur le logo du coffre au trésor. //2. Essayez d'écrire du code élégant, réduisez le nombre de fonctions, supprimez try catch lorsque le programme est publié et minimisez le nombre de lignes de programme. Ce n'est généralement pas possible sur l'ancien 40, mais désormais CoCoMo ne compte plus sur cela pour économiser de la mémoire. //3. Écrivez des données et des chaînes dans des fichiers, chargez-les en mémoire lorsqu'elles sont utilisées et définissez-les sur null lorsqu'elles ne sont pas utilisées. 4. Opération d'E/S getClass(). getResourceAsStream(file);, opération de base de données RecordStore. openRecordStore(nom, true);, Gestionnaire de création sonore. createPlayer();, création d'image Image. createImage(fichier); occupera une grande quantité de mémoire en peu de temps et la libérera plus tard. Si la mémoire restante du programme MIDlet est insuffisante, un débordement de mémoire se produira lorsque ces fonctions sont appelées fréquemment, ce qui entraînera ce que l'on appelle un pic de mémoire, ce qui est particulièrement courant sur les anciens 40. Lorsque vous rencontrez à nouveau OutOfMemoryError, utilisez Runtime pour trouver l'emplacement où le pic de mémoire se produit et essayez d'appeler ces instructions séparément, et utilisez de manière flexible le système. gc() à collecter à temps. //·Ressources Images : Elles occupent une grande quantité de mémoire, notamment les jeux mobiles avec de nombreuses ressources images. Le calcul de l'utilisation de la mémoire des ressources d'image est devenu une tâche régulière pour les développeurs de jeux J2ME. CoCoMo expliquera comment calculer l'utilisation de la mémoire des images : //Utilisation de la mémoire = largeur * hauteur * nombre d'octets de pixels, où le nombre d'octets de pixels varie en fonction du modèle. //Par exemple, l'utilisation de la mémoire d'une image 64*64 sur le 7210 = 64*64*1,5 = 614 4 (octets) = 6 Ko, l'utilisation de la mémoire sur le S60 = 64*64*2 = 8192 (octets) = 8 Ko. Le nombre d'octets de pixels varie selon le modèle. Par exemple, le 7210 est un modèle à 4096 couleurs, ce qui signifie que 12 bits sont utilisés pour représenter un pixel, donc multipliez par 1,5, tandis que le S60 est un modèle à 65536 couleurs, et 16 bits sont utilisés pour représenter un pixel, donc multipliez par 2. //Méthode d'optimisation//Il est faux de penser que la compression des images peut économiser de la mémoire. Selon l'explication ci-dessus, une fois l'image chargée dans la mémoire, elle n'est liée qu'à la largeur et à la hauteur et n'a rien à voir avec la taille des données de l'image. La compression de l'image ne peut réduire que la taille du fichier jar, mais pas l'utilisation de la mémoire. //1. Méthode statique : Réduisez la taille de l'image. Si la largeur et la hauteur sont plus petites, le résultat sera plus petit. Partant de cette idée, des outils tels que des éditeurs d'animation sont apparus, comme Prince of Persia de Gameloft. Une fois les personnages divisés, les parties du corps humain peuvent être réutilisées. Le placement compact de chaque partie permet de réduire la taille de l'image et d'utiliser pleinement chaque centimètre d'espace de l'image. //2. Méthode dynamique : Réduisez le nombre d'images chargées en mémoire en même temps. CoCoMo a déjà rencontré cette situation dans le projet Naruto Samurai. Il y avait 6 types de monstres à cette époque. S'ils étaient chargés dans la mémoire en même temps, cela exploserait certainement sur l'ancien 40. Cependant, seuls deux à trois types de monstres apparaissaient dans chaque niveau, donc chaque niveau n'avait besoin que de charger les images des monstres apparaissant dans ce niveau. Maintenant que je pense à ce projet, les débordements se produisaient fréquemment sur l'ancien 40. //Sound//Sound est également une ressource relativement gourmande en mémoire. Les octets occupés par la piste audio dans le son seront convertis en flux d'octets et chargés dans la mémoire. Par conséquent, réduire les octets occupés par la piste audio peut réduire la consommation de mémoire. L'approche actuelle de Gameloft consiste à utiliser un outil de conversion sonore pour convertir mid en ott, puis à le transformer en un flux d'octets ByteArrayInputStream pour créer un Player.