Nous avons récemment converti notre code pour utiliser Uidocument au lieu de manipuler des fichiers sur le système de fichiers directement, et nous avons rencontré des problèmes de performance. Nous vous demandons si nous utilisons ce cours de manière incorrecte, si quelqu'un d'autre avait ces problèmes et quelles sont les moyens communs de les résoudre.
Nous avons une "application de chaussures à chaussures" qui gère un tas de documents, chacun composé de plusieurs fichiers image pouvant être assez lourds, un petit fichier de métadonnées et une petite image d'aperçu. L'utilisateur peut avoir de nombreux documents sur son appareil (1000 documents). Les fichiers de chaque document sont regroupés dans un répertoire et nous utilisons NsfileWrapper pour les lire et les écrire.
Lorsque notre application commence, elle a besoin des métadonnées de tous les documents afin de montrer un index de document et un sous-ensemble des images de prévisualisation. Plus d'images de prévisualisation sont chargées lorsque l'utilisateur Fait défiler.
Pour obtenir cette information, nous ouvrons tous les documents, lisons leurs métadonnées et leur aperçu de l'image si nous devons, les fermons, puis ouvrir à nouveau à la demande.
Il faut beaucoup de temps pour ouvrir tous les documents et lire leurs métadonnées. Je pense qu'il y a plusieurs facteurs contribuant à ce problème: - chaque document de document est relativement lente - Les blocs de documents ouverts et les blocs d'achèvement sont exécutés sur la même file d'attente, ce qui rend la latence de l'opération très mauvais (mon document est ouvert, mais le bloc d'achèvement doit attendre les blocs de document Open avant qu'il ne puisse fonctionner)
Nous avons pensé à résoudre ce problème à l'aide d'un fichier d'index distinct, mais cette approche a l'inconvénient que nous devrons gérer les métadonnées à deux endroits et que nous devrons le garder synchronisé avec le système de fichiers au cas où ICLOUD change le Fichiers.
Chaque document ouvert crée son propre "fil d'accès au fichier". Lorsque nous ouvrons de nombreux documents simultanément, la surcharge écrase l'application.
Nous avons résolu ce problème en faisant appel aux opérations ouvertes à l'aide d'un sémaphore. Cette approche a l'inconvénient qu'il ralentit le chargement encore plus.
merci!
3 Réponses :
OK, pas de bonnes nouvelles ici.
Nous avons essayé de consulter des amis dans l'industrie, au profilage de l'uidocument et en utilisant des implémentations modifiées qui modifient divers aspects de son fonctionnement afin de déterminer si nous pouvons améliorer ses performances, mais en vain.
Ma conclusion est que l'uidocument ne convient pas à ce type d'utilisation - il n'est tout simplement pas conçu pour prendre en charge les exigences de la latence et du débit que nous avons pour les opérations ouvertes. Uidocument ne doit être utilisé que lorsque vous souhaitez ouvrir un petit nombre de fichiers à un moment donné (beaucoup comme des processeurs de texte et des applications de dessin). Certes, c'est exactement ce que dit la documentation d'Apple, mais je suppose que nous avons dû apprendre à quel point ils étaient sérieux de la difficulté :)
Nous avons fini par utiliser des "astuces" pour améliorer l'expérience utilisateur et s'éloignera de l'uidocument dès que possible.
Donc, ma recommandation est que seulement si:
Puis utilisez-le. Sinon, considérez d'autres solutions.
une note latérale qui n'est pas directement liée à la question, mais je vais ajouter ici en tant que service public: le modèle Async d'Uidocument a nécessité des modifications majeures de l'architecture d'applications lorsque nous sommes passés d'un accès direct au fichier. Si vous envisagez de faire ce déménagement, évaluez le travail que vous devrez faire soigneusement.
bonne chance futurs programmeurs.
Hila, merci pour ce suivi étendu! Je profilene de l'épargne et du chargement à l'aide de NsfileWrappers. Il semble que NsfileWrapper chargerait vraiment toutes les données dans la RAM, ce qui le rend inutilisable pour les fichiers volumineux. Je suis plus convaincu que je suis maintenant convaincu d'utiliser une solution personnalisée qui prend en charge des métadonnées et des fichiers volumineux. Une autre option que je voudrais, je faisait prouver Savetourl: Forsaveoperation: Terminéhandler . Vos optimisations ont-elles eu lieu pour inclure cela?
@RENGERS Nous avons également soupçonné NsfileWrapper, mais aussi loin que je sache, la mappage de mémoire qui ne devrait pas être aussi mauvaise que la lecture de toutes les données en mémoire (je me trompe peut-être). Nous avons testé son effet en remplaçant notre classe de base uidocument avec une classe modifiée qui utilise une implémentation qui lit les données à la demande, mais elle n'a pas beaucoup amélioré notre performance. Nous avons également créé une application de test qui a ouvert un groupe de fichiers vraiment petits et la performance était également médiocre. Je ne me souviens pas de quelles méthodes avons essayé de modifier.
@Rengers Je soupçonne que le modèle de threading est le coupable, mais je n'avais pas le temps de le vérifier car à un moment donné, nous avons dû couper nos pertes et passer à autre chose. J'espère que cela t'aides :)
Cela aide bien, on dirait que je suis dans le même bateau que vous étiez gars il y a quelque temps :). Je vais probablement passer à un design personnalisé après avoir entendu cela. Enregistrement de fichiers vraiment volumineux sur iCloud n'est pas vraiment réalisable de toute façon et séparer les métadonnées gardant un peu défaite les avantages des documents autonomes. Merci encore!
Les classes de documents ont des méthodes pour lire de manière asynchrone. Avez-vous essayé ça?
Cela ressemble vraiment à quelque chose de plus adapté aux données de base ou à la sqlite, pour les métadonnées. À tout le moins, cache les métadonnées dans les données de base (un magasin unique pour l'application entière, pas un par document).
Avez-vous déjà trouvé une solution? Je cours dans les mêmes problèmes avec beaucoup d'uidocuments contenant plusieurs grands fichiers vidéo. Je pense à la sortie uidocument tout à fait ou à garder un fichier d'index distinct. Peut-être que vous avez acquis des idées à ce sujet?
@Rengers s'il vous plaît voir ma réponse ci-dessous. Malheureusement, je n'ai aucune bonne nouvelle pour vous.