Performances du stockage persistant

Le stockage persistant se trouve dans le stockage d'application. La latence d'écriture dans le stockage d'application est supérieure à la latence de lecture. La lecture dans le stockage persistant est relativement rapide alors que les validations sont relativement lentes.

Méthode recommandée : utilisation d'une structure de données efficace

La structure de données choisie définit le nombre d'identificateurs d'objets et le volume de mémoire flash utilisés par une application. Un choix incorrect de structure de données risque de consommer des ressources clés sans améliorer les fonctionnalités ni l'expérience utilisateur.

Prenez en compte les recommandations suivantes :

  • La structure de données doit comprendre le moins d'objets possible, en particulier lorsque vous utilisez des objets de haut niveau, tels que Vector ou Hashtable. Ces classes offrent d'importantes fonctionnalités mais ne constituent pas un mécanisme de stockage efficace. Si possible, évitez de les utiliser avec le stockage persistant.
  • Dès que possible, utilisez des primitives au lieu d'objets. En effet, les primitives réduisent le nombre d'identificateurs d'objets utilisés sur le smartphone. Un tableau de primitives est un objet qui utilise un identificateur d'objets.
  • Les objets String sont aussi efficaces que les tableaux d'octets. Un objet String utilise uniquement un identificateur d'objets et est équivalent si votre application stocke tous les caractères sous forme d'un octet. En d'autres termes, la valeur de chaque caractère est inférieure ou égale à la valeur décimale de 255. Si votre application ne peut pas stocker de caractère sous forme d'un octet, vous pouvez les stocker en tant que String, ce qui équivaut à stocker un tableau char.

Méthode recommandée : conservation des identificateurs d'objets

L'une des erreurs les plus courantes rencontrées par les développeurs d'applications est l'insuffisance d'identificateurs d'objets persistants. La quantité d'espace de stockage d'application du smartphone détermine le nombre fixe d'identificateurs d'objets persistants disponibles sur le système. Selon le type de structure de données choisi, les enregistrements stockés peuvent rapidement épuiser le nombre d'identificateurs d'objets persistants. Un objet persistant utilise un identificateur d'objets persistants et un identificateur d'objets. Un objet temporaire n'utilise qu'un identificateur d'objets.

Par exemple, un enregistrement contenant dix champs String, représentant des éléments tels que nom, numéro de téléphone et adresse, utilise onze identificateurs d'objets persistants : un pour l'objet Record et un pour chaque champ String. Si une application conserve 3 000 enregistrements, l'application utilise 33 000 identificateurs d'objets persistants, nombre supérieur au nombre d'identificateurs d'objet persistants disponibles sur un smartphone disposant de 16 Mo de mémoire flash.

Vous pouvez utiliser la classe net.rim.device.api.system.ObjectGroup pour consolider les identificateurs d'objets en un objet sous un groupe. À l'aide de l'exemple du paragraphe précédent, si vous regroupez l'enregistrement, il n'utilise qu'un identificateur d'objets persistants au lieu de onze. L'identificateur d'objets des champs String consolide sous l'identificateur d'objets Record.

Lorsque vous consolidez les identificateurs d'objets en un groupe, l'identificateur d'objets est en lecture seule. Vous devez dégrouper l'objet avant de pouvoir le modifier. Une fois les modifications terminées, regroupez de nouveau l'objet. Si vous tentez de modifier un objet regroupé sans d'abord le dégrouper, une exception ObjectGroupReadOnlyException est lancée.

Le dégroupement d'un objet affecte les performances. Le système crée une copie de l'objet regroupé et alloue des identificateurs à chaque objet de ce groupe. Par conséquent, les objets ne doivent être dégroupés que lorsque nécessaire.

Pour la validation, il est possible que le stockage persistant survienne lors du nettoyage des instances sans méthode commit() explicite, de sorte que le regroupement d'objets doit toujours survenir avant l'appel de setContents() ou de commit(). Pour plus d'informations sur le regroupement d'objet, consultez le progiciel net.rim.device.api.system.ObjectGroup.

Suppression des objets persistants

Lorsqu'une application est supprimée d'un terminal BlackBerry, les objets persistants définis dans l'application sont automatiquement supprimés. Ce comportement est dû au fait que chaque objet persistant appartient à un type de classe défini dans l'application. Lorsque l'application est supprimée, le type de classe est également supprimé. Par conséquent, les objets persistants sont eux aussi supprimés.

Pour assurer le nettoyage du stockage persistant que vous utilisez, vous devez toujours stocker les instances de vos propres classes ou vos propres extensions des classes fournies.

Pour supprimer des données individuelles, traitez les données comme des objets classiques et supprimez-en toutes les références. Une opération de nettoyage de la mémoire supprime les données.


Ces informations vous ont-elles été utiles ? Envoyez-nous vos commentaires.