web-dev-qa-db-fra.com

Comment implémenter didReceiveMemoryWarning dans Swift?

Chaque fois que je crée une nouvelle sous-classe View Controller, Xcode ajoute automatiquement la méthode

override func didReceiveMemoryWarning() {
    super.didReceiveMemoryWarning()
    // Dispose of any resources that can be recreated
}

Habituellement, je le supprime ou l'ignore. C'est aussi ce que font tous les tutoriels que j'ai vus. Mais je suppose que puisque Xcode me le donne à chaque fois, cela devrait être quelque peu important, non? Que dois-je faire ici? Je suppose que l'élimination des ressources signifie leur mise à zéro, mais que sont exactement les "ressources qui peuvent être recréées"?

J'ai vu ces questions:

Mais ils sont tous pré-Swift. Bien que je ne sache pas grand chose sur Objective-C, j'ai entendu dire que la gestion de la mémoire est différente. Comment cela affecte-t-il ce que je dois faire dans didReceiveMemoryWarning?

Autres notes:

  • Je suis vaguement conscient du comptage automatique des références et de l'instanciation paresseuse
  • Le documentation sur didReceiveMemoryWarning que j'ai trouvé était plutôt bref.
iosswiftdidreceivememorywarning
31
Suragch

Swift

Swift utilise ARC comme Objective-C ( source to Apple Docs ). Le même type de règles s'applique pour libérer de la mémoire, supprimez toutes les références à un objet et il sera désaffecté.

Comment libérer de la mémoire

Je suppose que l'élimination des ressources signifie leur mise à zéro, mais que sont exactement les "ressources qui peuvent être recréées"?

"les ressources qui peuvent être recréées" dépendent vraiment de votre application.

Exemples

Imaginons que vous soyez une application de médias sociaux qui traite de nombreuses photos. Vous voulez une interface utilisateur accrocheuse afin de mettre en cache les 20 images suivantes en mémoire pour accélérer le défilement. Ces images sont toujours enregistrées sur le système de fichiers local.

  • Les images peuvent occuper beaucoup de mémoire
  • Vous n'avez pas besoin de ces images en mémoire. Si l'application manque de mémoire, prendre une seconde supplémentaire pour charger l'image à partir d'un fichier est très bien.
  • Vous pouvez vider entièrement le cache d'images lorsque vous recevez cet avertissement de mémoire.
  • Cela libérera de la mémoire dont le système a besoin

Vous créez un jeu étonnant qui a un certain nombre de niveaux différents. Le chargement d'un niveau dans votre moteur de jeu sophistiqué prend un certain temps, donc si l'utilisateur a suffisamment de mémoire, vous pouvez charger le niveau 3 pendant qu'il joue au niveau 2.

  • Les niveaux occupent beaucoup de mémoire
  • Vous n'avez pas besoin du niveau suivant en mémoire. Ils sont agréables à avoir mais pas essentiels.
  • LevelCache.sharedCache().nextLevel = nil libère toute cette mémoire

Que ne faut-il pas désallouer

Ne désallouez jamais ce qui est à l'écran. J'ai vu des réponses à des questions connexes désallouer la vue de l'UIViewController. Si vous supprimez tout de l'écran, vous pourriez bien planter (à mon avis).

Exemples

Si l'utilisateur a ouvert un document qu'il est en train de modifier, NE PAS le désallouer. Les utilisateurs se mettront en colère contre vous si votre application supprime leur travail sans jamais être enregistrée. (En fait, vous devriez probablement avoir un mécanisme de sauvegarde d'urgence lorsque cela se produit)

Si votre utilisateur écrit un article pour votre fabuleuse application de médias sociaux, ne perdez pas son travail. Enregistrez-le et essayez de le restaurer lorsqu'ils rouvrent l'application. Bien que la configuration nécessite beaucoup de travail, j'adore les applications qui le font.

Remarque

La plupart des appareils modernes manquent rarement de mémoire. Le système fait un très bon travail en tuant les applications en arrière-plan pour libérer de la mémoire pour l'application qui s'exécute au premier plan. Vous avez probablement déjà vu une application "ouverte" dans le sélecteur d'applications lorsque vous avez appuyé sur l'application, elle s'est ouverte à son état initial. Le système d'exploitation a tué l'application en arrière-plan pour libérer de la mémoire. Voir State Restoration pour plus d'informations sur la façon d'éviter ce problème.

Si votre application reçoit des avertissements de mémoire cohérents lorsque vous n'effectuez pas une énorme quantité de traitement, assurez-vous que vous ne perdez pas de mémoire en premier. La détection des fuites de mémoire sort du cadre de cette réponse. Docs et un tutoriel .

37
Kevin

Lorsque didReceiveMemoryWarning est appelé, cela signifie que votre application utilise trop de mémoire (par rapport à la mémoire de l'appareil), et vous devez release any additional memory used by your view controller pour réduire la mémoire de votre application. Si l'application mémoire dépasse la mémoire de l'appareil, iOS va tuer votre application immédiatement. "ressources qui peuvent être recréées" signifie quelque chose que vous pouvez recréer quelque part, vous n'en avez pas besoin maintenant (pas besoin de les mettre en mémoire). Et vous pouvez le libérer lorsque vous obtenez didReceiveMemoryWarning.

Voici un autre sujet de détail: budget de mémoire maximum de l'application ios

3
tuledev