Y a-t-il une limite au stockage des valeurs dans NSUserDefaults ?

Question

Je suis nouveau dans le développement de l'iPhone et objective C . J'ai utilisé NSUserDefaults pour stocker certaines valeurs dans mon application. Mais je ne sais pas s'il y a une limite pour stocker des valeurs dans mon application. NSUserDefaults . Quelqu'un peut-il m'aider à le savoir ?

Merci d'avance.

Answer 1

Tant qu'il y a suffisamment d'espace sur l'iPhone/iPad, vous pouvez stocker les valeurs de NSUserDefault. Toutes ces valeurs sont stockées dans un fichier .plist, et ce fichier est très petit, la plupart du temps moins de 1 kb (sauf si vous stockez beaucoup de données).

Answer 2

Il y a des limites aux types que vous pouvez stocker : ils doivent tous être des objets Property List, à savoir NSString , NSNumber , NSData , NSArray y NSDictionary . En outre, vous ne pouvez stocker que NSArray y NSDictionary si les valeurs sont également des objets de la liste de propriétés ; de même, toutes les clés de l'objet NSDictionary doivent être des chaînes de caractères.

Notez qu'un objet comme UIColor ne figure pas dans la liste ci-dessus. Donc, si vous voulez stocker une couleur dans la base de données des valeurs par défaut, vous devrez d'abord la convertir en chaîne de caractères ou en objet de données, puis la reconvertir lorsque vous lirez les valeurs par défaut.

En ce qui concerne les limites de taille, il n'y en a aucune qui soit documentée, mais notez que toutes les données seront stockées dans un fichier de liste de propriétés. Le fichier entier est lu et écrit comme un tout, donc si vous utilisez la commande NSUserDefaults pour stocker une grande quantité de données qui ne changent que partiellement, vous perdrez beaucoup de temps à effectuer des E/S inutiles.

Answer 3

À partir des codes du SDK iOS, et document officiel d'Apple en rapport. .

extension UserDefaults {

    /*!
     NSUserDefaultsSizeLimitExceededNotification is posted on the main queue when more data is stored in user defaults than is allowed. Currently there is no limit for local user defaults except on tvOS, where a warning notification will be posted at 512kB, and the process terminated at 1MB. For ubiquitous defaults, the limit depends on the logged in iCloud user.
     */
    @available(iOS 9.3, *)
    public class let sizeLimitExceededNotification: NSNotification.Name

    // ....
 }   

---

Résumé

1. Il n'y a actuellement aucune limite pour les valeurs par défaut des utilisateurs locaux.
2. Sur tvOS où une notification d'avertissement sera affichée à 512kB, et le processus se terminera à 1MB.
3. Pour les valeurs par défaut omniprésentes, la limite dépend de l'utilisateur iCloud connecté.

Answer 4

Tout le monde a répondu à la question directe "y a-t-il une limite ?". Cependant, j'ai trouvé ce fil de discussion cherchant vraiment à comprendre " combien est trop à stocker dans UserDefaults ?"

Si vous cherchez cette réponse, voici une utile filetage . Les réponses que j'ai trouvées utiles étaient d'aller dans votre fichier de projet et de regarder la taille du fichier plist :

5 objets, c'est presque rien. Vous vous en sortirez !

---

Sur ma machine, j'ai environ 28 mégaoctets de données dans mes paramètres par défaut. Cela ne pose aucun problème.

---

D'après mon expérience générale de la programmation avec les tableaux, je pense que les performances commencent à diminuer rapidement lorsque vous atteignez des milliers d'éléments, en fonction de leur taille. Par conséquent, dans un programme, je n'aurais pas de problème à stocker quelques centaines d'éléments. Ceci dit, si j'étais vous, je commencerais probablement à utiliser une base de données sqlite3 ou coredata, le plus tôt possible.

Il est important de s'en souvenir :

Ce qui précède a apaisé mes craintes que mon nombre croissant de valeurs par défaut (environ 20-25 maintenant) ne pose des problèmes. J'utilise déjà CoreData, et je me demandais donc lequel utiliser puisque le nombre de préférences/personnalisations utilisateur autorisées ne cesse d'augmenter. Donc, je vais rester avec les valeurs par défaut de l'utilisateur.

Cependant Comme d'autres réponses l'ont souligné, le fichier sera lu et écrit comme un tout. Donc lire 20 dictionnaires clé/chaîne et 5 dictionnaires clé/booléen juste pour récupérer une chaîne de caractères... pas vraiment l'idéal. Néanmoins, si cela ne nuit pas aux performances et permet d'économiser une tonne de code, pourquoi pas ?

Answer 5

Comme beaucoup l'ont déjà mentionné : Je n'ai pas connaissance d'une quelconque limitation de TAILLE (hormis la mémoire physique) pour stocker des données dans un .plist (par exemple UserDefaults). Ce n'est donc pas une question de TAILLE.

La vraie question devrait être de savoir à quelle fréquence vous écrivez des valeurs nouvelles ou modifiées... Et ceci est lié à la décharge de la batterie que ces écritures vont provoquer.

L'IOS n'a aucune chance d'éviter une écriture physique sur le "disque" si une seule valeur change, juste pour préserver l'intégrité des données. En ce qui concerne les UserDefaults, cela entraîne la réécriture de tout le fichier sur le disque.

Cela alimente le "disque" et le maintient sous tension plus longtemps et empêche l'IOS de passer en état de faible consommation.

Extrait du "Guide de l'efficacité énergétique pour les applications iOS" :

Minimisez les écritures de données. N'écrivez dans les fichiers que lorsque leur contenu a changé, et regroupez les changements en une seule écriture chaque fois que cela est possible. Évitez d'écrire un fichier entier si seuls quelques octets ont été modifiés. Si vous modifiez fréquemment de petites portions de fichiers volumineux, envisagez plutôt d'utiliser une base de données pour stocker les données.

Les READS ne posent aucun problème, car toutes les valeurs sont mises en cache en mémoire.

EDITAR: (juillet 2019) : Je viens de trouver ce très bon article de blog de Jeffry Fulton.

https://jeffreyfulton.ca/blog/2018/02/userdefaults-limitations-and-alternatives

Il décrit en détail les différents aspects des paramètres par défaut de l'utilisateur et présente également quelques tests de performance.

Bon codage ! !!