Share
Même si l'iPhone 5 et l'iPad 4 sont dotés d'un puissant processeur A6 (X) et de beaucoup plus de RAM que l'iPhone d'origine, cela ne signifie pas pour autant que les applications iOS sont par définition rapides et performantes. Dans cette astuce, je vais vous donner cinq astuces pour améliorer les performances des applications..
Si une application iOS récupère une ressource distante, il est important qu'elle ne récupère pas les mêmes ressources à chaque fois qu'elle doit y accéder. Si vous envisagez de développer un client Twitter pour iOS, par exemple, le client ne devrait pas télécharger le même avatar à chaque fois qu'il doit l'afficher. La mise en cache de l'avatar améliorera considérablement les performances de l'application.
Qu'est-ce que la mise en cache? L'idée de base de la mise en cache est simple. Lorsque l'application récupère une ressource distante pour la première fois, elle stocke une copie de cette ressource sur le disque pour une utilisation ultérieure. Si cette même ressource est nécessaire ultérieurement, l'application peut la charger à partir du disque au lieu de la récupérer à distance. L'avantage supplémentaire est que la ressource est également disponible lorsque le périphérique n'est pas connecté au Web. L'aspect complexe de la mise en cache est de savoir comment stocker la ressource, quand la stocker et, plus important encore, quand l'actualiser..
Olivier Poitrey a développé une petite bibliothèque nommée SDWebImage qui vise à la mise en cache des images. Il fournit une catégorie sur UIImageView un peu comme AFNetworking Est-ce que. La principale différence est que SDWebImage met en cache les images qu'il télécharge. Les images sont téléchargées en arrière-plan et chaque image est décompressée, ce qui accélère les temps de chargement. La bibliothèque exploite Grand Central Dispatch pour que le thread principal reste réactif. Si votre application fonctionne avec des images distantes, vous devriez jeter un coup d'œil à ce petit bijou..
L'une des leçons les plus importantes à apprendre lors du développement pour la plate-forme iOS est de ne jamais bloquer le thread principal. Si vous bloquez le thread principal avec une opération longue, telle que le téléchargement d'images ou d'autres ressources, votre application ne répondra plus tant que l'opération ne sera pas terminée. Prenez l’habitude de déplacer des tâches longues vers un fil d’arrière-plan. Même si vous n'avez besoin que de quelques octets, si la connexion du périphérique au Web est lente, l'opération bloque toujours le thread principal..
L'écriture de code multithread sécurisé est devenue beaucoup plus facile avec l'introduction de Grand Central Dispatch. Examinez les extraits de code suivants. Le premier extrait télécharge les données sur le thread principal, tandis que le deuxième extrait exploite Grand Central Dispatch pour effectuer la même tâche dans une file d'attente en arrière-plan..
NSData * data = [NSData dataWithContentsOfURL: URL]; UIImage * image = [UIImage imageWithData: data]; [imageView setImage: image];
Accentsconagua
dispatch_queue_t queue = dispatch_queue_create ("downloadAsset", NULL); dispatch_async (file d'attente, ^ NSData * data = [NSData dataWithContentsOfURL: URL]; dispatch_async (dispatch_get_main_queue (), ^ UIImage * image = [UIImage imageWithData: data]; [imageView setImage: image];);); Être paresseux n'est pas toujours mauvais, surtout si vous êtes programmeur. Le chargement paresseux est un concept bien connu dans le développement de logiciels. Cela signifie simplement que vous différez l'instanciation d'un objet jusqu'à ce que vous en ayez besoin. Ceci est avantageux pour plusieurs raisons. En fonction de l'objet et du coût de l'instanciation, il peut améliorer considérablement les performances des applications et l'utilisation de la mémoire. Le chargement d'objets paresseux n'est pas un concept difficile. L’implémentation la plus simple de ce modèle remplace le getter d’une propriété, comme indiqué ci-dessous..
- (MyClass *) myObject if (! _MyObject) _myObject = [[MyClass alloc] init]; return _myObject;
Le modèle de chargement paresseux peut être appliqué dans de nombreux domaines du développement logiciel. Par exemple, si une partie de l'interface utilisateur de votre application n'est pas affichée par défaut, il peut être avantageux de différer son instanciation jusqu'à ce que cette partie soit sur le point d'être affichée..
Les vues de table et de collection utilisent une combinaison de mise en cache et de chargement différé pour optimiser les performances. Si la cellule ou l'élément suivant est sur le point d'être affiché à l'écran, la vue Table ou Collection recherche une cellule ou un élément qu'elle peut réutiliser (mise en cache). La table ou la vue de collection (ou sa source de données) instanciera une nouvelle cellule ou un nouvel élément (chargement différé) uniquement si aucune cellule ou élément réutilisable n'est disponible.
Si vous remarquez que votre application est parfois lente et que vous souhaitez savoir ce qui la cause, vous devrez peut-être profiler votre application avec un outil tel que Instruments. Colin Ruffenach a écrit un bon tutoriel sur le profilage du temps avec Instruments sur Mobiletuts+.
Si Instruments ne vous donne pas de réponse claire, vous serez peut-être intéressé par MGBenchmark, une bibliothèque d'analyse comparative développée et maintenue par Mattes Groeger. Cette bibliothèque compacte vous permet de mesurer la rapidité d'exécution de votre code et vous aide à localiser les goulots d'étranglement dans votre base de code. En fait, il complète très bien les instruments, vous ne devez donc pas utiliser l’un ou l’autre. La bibliothèque de Mattes Groeger est fournie avec un ensemble complet de fonctionnalités et est remarquablement puissante. Je le recommande fortement comme alternative ou complément aux instruments.
Si vous développez une application qui fonctionne avec beaucoup de données, il est important de la tester avec… bien… beaucoup de données! Lors du développement d’une application, il n’est pas toujours facile ni possible d’imaginer comment vos utilisateurs utiliseront votre application, mais il est bon de la mettre à l’essai avant de la publier. Votre application peut fonctionner admirablement pendant le développement et très mal dans les situations où elle est inondée de données. Vous ne pourrez probablement pas prédire, et encore moins tester, toutes les circonstances dans lesquelles votre application sera utilisée, mais vous pouvez essayer de reproduire des situations courantes en créant des ensembles de données avec lesquels tester.
Je crée souvent un petit script ou une classe qui remplit l'application avec des données de test pour mesurer ses performances avec beaucoup de données. Idéalement, vous souhaitez remplir l'application avec plus de données de test que l'utilisateur moyen en aura, dans la mesure où vous pouvez le prédire pendant le développement. Lorsque je développais Pixelsync, une application iPad qui s'interface avec Aperture et iPhoto, j'ai créé une bibliothèque Aperture contenant près de 500 000 images. Si Pixelsync fonctionnait bien avec une photothèque de cette taille, je pouvais être assez sûr que l'utilisateur moyen ne rencontrerait pas de problèmes de performances..
Si vous êtes vraiment un développeur paresseux ou si vous ne disposez pas de suffisamment de temps, vous pouvez également faire preuve de plus de créativité en construisant un robot qui fera le travail à votre place..
Les performances des applications restent un aspect essentiel du développement logiciel malgré le fait que la nouvelle génération d'appareils soit beaucoup plus puissante et performante. Par exemple, le blocage du fil principal aura toujours pour conséquence une mauvaise expérience utilisateur, quelle que soit la capacité du périphérique..
