编程知识 cdmana.com

Comment gérer systématiquement la stabilité iOS

Cet article est le professeur Feng Yadong2021 ArchSummit Lors du Sommet mondial des architectes「Comment gouverner systématiquement iOS Problèmes de stabilité」Partager le texte intégral de.
 
Commencez par vous présenter.:C'est Feng Yadong.,2016 Année 4 Mois ajouter un saut d'octet,J'ai fait les gros titres aujourd'hui. App Architecture d'ingénierie pour、Bases de données de base et optimisation de l'expérience.2017 Année 12 Mois à ce jour APM Orientation,De 0 À 1 Participation à l'écoulement des octets APM Construction de la station moyenne,Gamme complète de produits pour les octets,Actuellement, la responsabilité principale iOS Surveillance et optimisation de la stabilité des performances.
Ce partage est principalement divisé en quatre chapitres,Respectivement.:1.Classification des problèmes de stabilité;2.Méthodes de gestion des problèmes de stabilité;3.Attribution des problèmes difficiles;4.Examen sommaire. Le troisième chapitre 「Attribution des problèmes difficiles」 C'est l'objet de ce partage , Ça pourrait prendre 60%L'espace de.
 

Un.、Classification des problèmes de stabilité

Avant de parler de classification , Commençons par le contexte : Tout le monde sait que pour les applications mobiles, , FLASHBACK est le pire que l'utilisateur puisse rencontrer bug, Parce que l'utilisateur ne peut pas continuer à utiliser le produit après FLASHBACK , Il n'y a donc aucun moyen de parler de la conservation ultérieure des utilisateurs et de la valeur commerciale du produit lui - même .
Voici quelques données à partager avec vous :Oui. 20% Lorsque vous utilisez des produits mobiles , Le problème le plus insupportable est de reculer. , C'est juste après les publicités intempestives. ; Parmi les utilisateurs perdus en raison de problèmes d'expérience ,Oui. 1/3 Les utilisateurs de , Donc le problème de FLASHBACK est très mauvais et grave .
Le saut d'octets est comme avoir un son comme Shaker 、 Super grand nombre de titres, etc App Entreprises, La question de la stabilité est très importante .Ces dernières années, Nous avons investi beaucoup de personnel et de ressources dans ce domaine. , De bons résultats en matière de gouvernance ont également été obtenus. . Ces deux dernières années, le son tremblant 、Les gros titres、Flying Books, etc. App Les taux d'écrasement anormaux de 30% Optimisation ci - dessus , Certains indicateurs pour les produits individuels sont même 80% Optimisation ci - dessus .
Le diagramme circulaire à droite de l'image ci - dessus montre :Nous avons iOS Exemple de plate - forme, Selon la cause du problème de stabilité , Les problèmes de stabilité connus sont classés dans ces cinq catégories , Trier de haut en bas par rapport à : La première grande catégorie est OOM , C'est un crash dû à une consommation excessive de mémoire. , Cette proportion peut représenter 50% Ci - dessus;Et ensuite, Watchdog, C'est - à - dire coincé , Analogique avec Android ANR; Encore une fois, c'est normal Crash; Enfin, le disque IO Anomalies et CPU Anomalie.
Il y a peut - être une question en vous voyant ici : Qu'est - ce que Byte Jump a fait exactement? , Ce n'est qu'à ce moment - là que nous avons obtenu ce résultat. ? Ensuite, je vais partager avec vous notre méthodologie sur la gouvernance de la stabilité .
 

2.、 Méthodologie de gestion des problèmes de stabilité

Premièrement, nous pensons qu'en ce qui concerne la gouvernance des problèmes de stabilité , Du point de vue de la plate - forme de surveillance , Le plus important est d'avoir une couverture complète des capacités , Par exemple, pour tous les types de problèmes de stabilité mentionnés dans la section précédente , Les plates - formes de surveillance devraient être en mesure de détecter rapidement et avec précision .
Et du point de vue des étudiants en recherche et développement : Gestion des problèmes de stabilité , Nécessité d'un cycle de vie complet tout au long du développement de logiciels , Y compris la recherche et le développement sur la demande 、Tests、Intégration、Niveaux de gris、 En ligne, etc , À chaque étape ci - dessus , Les étudiants en recherche et développement devraient prêter attention à la découverte et à la gestion des problèmes de stabilité .
À droite de l'image ci - dessus se trouvent deux principes de gouvernance plus importants que nous avons résumés :
Le premier est Contrôler l'ajout , Gérer les stocks . En général, les nouveaux problèmes de stabilité peuvent être sujets à des explosions , L'impact est assez grave . Le problème des stocks est relativement difficile , Longue période de réparation .
L'article 2 est plus facile à comprendre : D'abord. C'est urgent. Retard ,Facile avant difficile. Nous devrions accorder la priorité à la réparation des problèmes qui ont éclaté et qui sont relativement faciles à résoudre. .
Si nous concentrons le cycle de développement du logiciel sur la gouvernance des problèmes de stabilité , Les liens suivants peuvent également être résumés: :
La première étape est la découverte de problèmes. : Lorsque l'utilisateur rencontre n'importe quel type de FLASHBACK en ligne , La plate - forme de surveillance devrait être en mesure de détecter et de signaler en temps opportun . En même temps, grâce à l'alarme et à la distribution automatique des problèmes , Informez les développeurs de ces questions pour la première fois , Veiller à ce que ces problèmes soient corrigés en temps opportun .
La deuxième étape est l'attribution : Quand les développeurs auront un problème de stabilité , La première chose à faire est de résoudre ce problème . Selon un scénario différent , Nous pouvons diviser l'attribution en un seul point. 、 Attribution générale et attribution des problèmes d'éclosion .
Une fois que la cause du problème a été trouvée , L'étape suivante consiste à corriger ce problème. ,C'est - à - dire Gouvernance des problèmes . Nous avons ici quelques outils pour gérer les problèmes : Si c'est en ligne , Nous pouvons d'abord faire quelques problèmes de protection , Par exemple, Netease a mentionné il y a quelques années un article basé sur OC Runtime En ligne Crash Solution de réparation automatique Grand blanc , Sur la base de ce scénario, nous pouvons le faire directement en ligne Crash Protection; En outre, des problèmes de stabilité ont éclaté en raison de la mise en service du Service d'arrière - plan. , Nous pouvons obtenir un arrêt dynamique des pertes en faisant reculer le Service . En plus de ces deux moyens , D'autres scénarios doivent encore être développés pour la réparation hors ligne native Code, Et faire une correction complète par la distribution .
La dernière étape a également été un sujet brûlant ces dernières années ,C'est Prévention de la détérioration du problème . Il s'agit de l'étape entre la recherche et le développement et la mise en ligne de la demande , Peut être testé par l'unit é d'automatisation du Rack /UIEssais automatisés, Et la recherche et le développement peuvent être réalisés à l'aide d'un certain nombre d'outils ,Par exemple, Xcode Et Instruments, Y compris certains outils de tiers , Comme Wechat open source MLeaksFinder Pour identifier et résoudre les problèmes de stabilité à l'avance .
 
Si nous voulons bien gérer les problèmes de stabilité , Tous les étudiants en recherche et développement doivent prêter attention à chacun des liens ci - dessus , Pour atteindre le but ultime . Mais qu'est - ce qu'on se concentre sur tant de choses? ? Du point de vue de l'expérience de la gestion des problèmes de saut d'octets , Nous pensons que le lien le plus important est le deuxième —— Attribution des problèmes en ligne . Parce que les statistiques internes : La raison pour laquelle la ligne existe depuis longtemps n'est pas concluante , Il n'y a aucun moyen de réparer le problème , C'est surtout parce que la recherche et le développement ne s'attaquent pas aux causes profondes de ces problèmes . Le prochain chapitre est donc aussi au centre de ce partage :Attribution des problèmes difficiles.
 

Trois、Attribution des problèmes difficiles

Nous avons trié ces questions en fonction de la familiarité des développeurs ,Respectivement.:Crash、Watchdog、OOM Et CPU&Disk I/O. Je partage le contexte et les solutions correspondantes pour chaque type de problème difficile , Et démontrera comment les outils d'attribution peuvent résoudre ces problèmes difficiles avec des cas réels .
3.1 Première catégorie de problèmes difficiles —— Crash
Le diagramme circulaire à gauche de l'image ci - dessus est basé sur Crash Pour différentes raisons , Subdiviser en quatre grandes catégories :Y compris: Mach Anomalie、 Unix Signal Anomalie、OC Et C++ Anomalies au niveau linguistique . Le pourcentage le plus élevé est Mach Anomalie,Et ensuite, Signal Anomalie,OC Et C++ Relativement peu d'exceptions .
Pourquoi cette proportion ?
Vous pouvez voir qu'il y a deux données dans le coin supérieur droit . Le premier est un article publié par Microsoft , Appelé sa publication 70% Les correctifs de sécurité ci - dessus sont des erreurs liées à la mémoire ,Correspond à iOS La plate - forme est Mach Accès illégal à l'adresse dans l'exception ,C'est - à - dire EXC_BAD_ACCESS. Les statistiques internes montrent que , Byte Jumper Line Crash Oui. 80% C'est une longue période sans conclusion ,Dans cette partie Crash Milieu,90% Tout ce qui précède Mach Exception ou Signal Anomalie.
Regarde ça., Il doit y avoir un autre doute. , Pourquoi tant de Crash Ça ne résout pas?Où est le problème?? Nous résumons les difficultés d'attribution de ces problèmes :
  • D'abord différent de OC Et C++ L'exception de, Peut - être que la pile d'appels crash que le développeur obtient est une pile d'appels système pure , Ce genre de problème est évidemment très difficile à réparer ;
  • Il pourrait y avoir une autre partie Crash C'est un problème occasionnel, pas nécessairement. , Il est très difficile pour les étudiants de R & D de reproduire les problèmes hors ligne , Parce qu'il n'y a pas de répétition , C'est dur de passer IDE Débogage pour résoudre et localiser ces problèmes ;
  • En outre, pour les problèmes d'accès à des adresses illégales , La pile d'appels écrasée peut ne pas être la première scène . Voici un exemple très simple :A Débordement d'allocation de mémoire pour l'entreprise , J'ai marché sur B Mémoire d'affaires , À ce moment - là, nous pensons que A Les affaires devraient être la principale cause de ce problème ,Mais c'est possibleB L'entreprise a utilisé cette mémoire à un moment ultérieur , Il y a eu un crash . Il est clair que le problème est en fait A En raison de l'entreprise , Et il s'est effondré B Dans la pile d'appels d'affaires , Cela peut causer beaucoup d'interférence pour les développeurs dans le dépannage et la résolution de ce problème .
 
Il y a peut - être un autre problème. : Comme ces problèmes sont si difficiles à résoudre, , Il n'y a pas de solution? ?Pas vraiment., .Je vais partager deux outils d'attribution très utiles à l'intérieur des octets pour résoudre ce genre de problèmes difficiles .
3.1.1 Zombie Détection
Le premier est Zombie Détection, Si tout le monde l'avait utilisé Xcode De Zombie Surveillance, Vous devriez être familier avec cette fonctionnalité . Si nous l'ouvrons avant le débogage Zombie Objects Cet interrupteur, En cours d'exécution, si vous rencontrez OC Crash causé par le pointeur de champ objet ,Xcode Une ligne de journal est imprimée dans la console , Il indique au développeur quel objet s'est écrasé en appelant quel message .
On va expliquer Zombie Définitions,C'est très simple., Se réfère à ce qui a été libéré OC Objet.
Zombie Quels sont les avantages attribués à la surveillance? ? Tout d'abord, il peut aller directement à la classe où le problème se produit , Au lieu de quelques piles d'appels de crash aléatoires ; En outre, il peut augmenter la probabilité de récurrence du problème de coïncidence , Parce que la plupart des problèmes d'épissage peuvent être liés à l'environnement d'exécution multithreadé , Si nous pouvions transformer un problème de coïncidence en un problème de nécessité , Alors les développeurs peuvent utiliser IDE Et le débogueur est très pratique pour résoudre les problèmes . Mais ce programme a aussi son propre champ d'application , Parce que son principe sous - jacent est basé sur OC De runtime Mécanismes, Donc ça ne s'applique qu'à OC Problèmes de mémoire causés par les pointeurs d'objets sauvages .
Revenons en arrière. Zombie Le principe de la surveillance : D'abord, on va hook Classe de base NSObject De dealloc Méthodes,Quand n'importe quel OC Quand l'objet est libéré ,hook Après ça dealloc La méthode ne libère pas vraiment cette mémoire , En même temps ISA Pointeur vers une classe de zombies spéciale , Parce que cette classe spéciale de zombies n'implémente aucune méthode , Donc cet objet zombie reçoit n'importe quel message plus tard Crash, En même temps, nous signalerons le nom de classe de cet objet zombie sur la scène de crash et le nom de la méthode alors appelée à l'analyse de fond .
Voici un vrai cas d'octets : Le problème est que fliebook est sur une ligne de version Top 1 De Crash, Ça a duré deux mois. . Tout d'abord, vous pouvez voir que cette pile d'appels crash est une pile d'appels système pure , Son type de crash est un accès illégal à l'adresse , Une animation de transition qui se produit au Contrôleur de navigation de vue , Peut - être que les développeurs n'avaient aucune idée quand ils ont vu cette pile d'appels crash au début .
Alors regardons Zombie Crash Call Stack après l'activation de la fonction : Les messages d'erreur seront plus abondants à ce stade , Le type d'objet qui peut être positionné directement sur un pointeur de champ ,- Oui. MainTabbarController L'objet appelle retain C'est arrivé quand la méthode Crash.
Tout le monde doit avoir des doutes. ,MainTabbarController En général, c'est le Contrôleur racine de la page d'accueil , Théoriquement, il ne devrait pas être libéré tout au long de son cycle de vie . Pourquoi est - ce devenu un objet de pointeur sauvage ? Vous pouvez voir un message d'erreur aussi simple , Parfois, ce n'est pas assez pour que les développeurs se concentrent sur la cause profonde du problème . Nous allons donc plus loin. , Une fonctionnalité étendue :Oui. Zombie L'information sur la pile d'appels lorsque l'objet est libéré est également rapportée .
Regardez l'avant - dernière ligne , En fait, c'est un code de vol. , Est une méthode de substitution pour la reconnaissance des gestes du Contrôleur de navigation de vue , Cette méthode est libérée au moment de l'appel MainTabbarController. Parce que le point d'appel du Code d'affaires a été trouvé à travers cette pile d'appels , Donc nous avons juste besoin de comparer le code source pour analyser pourquoi il est publié TabbarController, Pour déterminer la cause du problème .
Le côté droit de la figure ci - dessus est le code source simplifié ( Parce qu'il y a des problèmes de confidentialité de code , Donc au lieu d'un commentaire ). Dans l'histoire, pour résoudre les conflits de retour de glissement de geste , Un paragraphe est écrit dans la méthode d'agent de reconnaissance des gestes du Contrôleur de navigation flybook View trick Code,C'est ça. trick Le schéma a entraîné une libération inattendue du Contrôleur de navigation de la vue d'accueil .
J'ai vérifié ici., Nous trouvons la cause profonde du problème , Le plan de réparation est très simple : Laisse tomber ça trick Programme, Et s'appuyer sur l'implémentation native du Contrôleur de navigation pour déterminer si ce geste est déclenché résout ce problème .
 
3.1.2 Coredump
J'ai aussi mentionné:Zombie Le programme de surveillance comporte certaines limites. , Il ne s'applique qu'à OC Problème de pointeur sauvage pour l'objet . On peut encore se demander : C Et C++ Le Code peut également avoir des problèmes de pointeur sauvage ,In Mach Anomalies et Signal Dans l'exception , En plus des problèmes de mémoire , Il y a beaucoup d'autres types d'exceptions, comme EXC_BAD_INSTRUCTIONEtSIGABRT. Comment résoudre d'autres problèmes? ? Voici une autre solution —— Coredump.
Ceci explique d'abord ce qu'est Coredump:Coredump C'est par lldb Un format de fichier spécial défini ,Coredump Les fichiers peuvent être restaurés App L'état de fonctionnement complet à un moment donné ( Ici, l'état de fonctionnement se réfère principalement à l'état de mémoire ). Vous pouvez simplement comprendre :Coredump Le fichier est l'équivalent d'un point d'arrêt sur les lieux de l'accident , Et obtenir des informations de registre pour tous les fils à ce moment - là , Mémoire de pile et mémoire de tas complète .
Coredump Quel est son avantage d'attribution? ? D'abord parce que c'est lldb Format de fichier défini , Donc il soutient naturellement lldb Commande de débogage pour , C'est - à - dire que les développeurs n'ont pas besoin de répéter le problème , Vous pouvez réaliser le débogage post - événement pour les problèmes difficiles en ligne . De plus, parce qu'il a toutes les informations de mémoire sur place au moment de l'écrasement , Cela fournit aux développeurs une grande quantité de matériel d'analyse de problèmes .
Le champ d'application de ce programme est large. , Peut être appliqué à n'importe quel Mach Exception ou Signal Analyse des problèmes anormaux .
Voici également une analyse de cas réels en ligne : Ce problème est apparu dans tous les produits Byte , Et dans de nombreux produits, c'est très grand. ,ClassementTop 1 Ou Top 2, Ce problème n'a pas été résolu depuis deux ans .
Comme vous pouvez le voir, la pile d'appels crash est aussi une méthode de bibliothèque système , Il s'est effondré à libdispatch Une méthode dans la Bibliothèque , Le type d'exception est hit System Library assertion .
On va s'effondrer. Coredump Après la soumission du document ,Avec ce qui a été mentionné précédemment lldb Commande de débogage pour analyser , Parce que vous avez l'état complet de la mémoire au moment de l'écrasement , Nous pouvons donc analyser des informations telles que les registres et la mémoire de pile pour tous les Threads .
Enfin, nous avons analysé : Crash thread 0 Cadre de pile no ( La première ligne appelle la pile ),C'est... x0 L'expéditeur est en fait libdispatch Informations sur la structure de la file d'attente définies dans . Au début, l'adresse est décalée 0x48 Où les octets , C'est la file d'attente label Propriétés( Peut être interprété simplement comme le nom de la file d'attente ). Le nom de cette file d'attente est crucial pour nous , Parce que pour corriger ce problème , Il faut d'abord savoir quelle file d'attente a un problème. .Adoption memory read Nous avons reçu l'ordre de lire directement les informations de cette mémoire , Il s'est avéré que c'était un C La chaîne de,Je m'appelle com.apple.CFFileDescriptor, Cette information est cruciale . Nous avons fait une recherche globale de ce mot clé dans le code source , Il s'avère que cette file d'attente a été créée dans la Bibliothèque réseau au bas de l'octet , Cela explique aussi pourquoi tous les produits Byte ont ce crash .
Finalement, nous avons vérifié avec nos camarades de classe de la Bibliothèque web ,Combinaison simultanée libdispatch Source de, La raison pour laquelle nous nous sommes concentrés sur ce problème est GCD Le nombre de références externes dans la file d'attente est inférieur à 0, Il y a un problème de libération excessive , L'affirmation finale de la Bibliothèque système hit a causé un crash .
Après avoir résolu le problème ,La solution est simple: Tout ce qu'il nous faut, c'est quand cette file d'attente sera créée ,Utiliser dispatch_source_create Pour augmenter le nombre de références externes dans la file d'attente ,Peut résoudre ce problème. Après avoir communiqué avec les camarades de classe qui maintiennent la bibliothèque en ligne , Confirmez que cette file d'attente est dans App Ne devrait pas être libéré pendant la durée de vie de . Les avantages de la résolution finale de ce problème sont que les octets de tous les produits Crash Taux réduit8%.
 
3.2 Deuxième catégorie de problèmes difficiles —— Watchdog
Nous passons à la deuxième catégorie de problèmes difficiles —— Watchdog C'est - à - dire coincé .
Sur le côté gauche de l'image ci - dessus se trouvent deux images que j'ai coupées sur Twitter. , C'est la plainte de l'utilisateur après avoir rencontré un problème de blocage . On peut voir que le problème de blocage nuit beaucoup à l'expérience de l'utilisateur. . Qu'est - ce que ça peut faire? ?
Le premier problème de blocage se produit habituellement lorsque l'utilisateur ouvre App Phase de démarrage à froid de , L'utilisateur a dû attendre 10 La seconde n'a rien fait ,C'est App Il s'est effondré., C'est très mauvais pour l'expérience utilisateur . De plus, notre surveillance en ligne a révélé , S'il n'y a pas de remède au problème du blocage , Son échelle peut être normale Crash De 2-3 X. De plus, l'industrie surveille maintenant OOM La pratique de l'effondrement est l'exclusion , S'il n'y a pas eu d'élimination de l'écrasement , En conséquence, il y aura une augmentation OOM La probabilité d'une erreur judiciaire .
Quelles sont les difficultés d'attribution des problèmes de blocage? ? Tout d'abord, sur la base des programmes traditionnels ——Surveillance de katon: Le temps de non - réponse du fil principal est considéré comme supérieur à 3Secondes~5 Une seconde plus tard, elle s'est coincée , Ce système traditionnel est très facile à falsifier , Quant à la raison pour laquelle les faux positifs , Nous en parlerons à la page suivante . De plus, la cause du blocage peut être très compliquée. , Ce n'est pas nécessairement un problème unique. : Blocage du fil principal 、Verrouillez et attendez.、Le fil principal IO Il y a un risque de coincement. . Le troisième point est que le problème de blocage est une cause commune de problèmes de blocage . Le seuil d'analyse de l'impasse dans le système traditionnel est relativement élevé. , Parce qu'il dépend fortement de l'expérience des développeurs , Les développeurs doivent s'appuyer sur l'expérience humaine pour analyser avec quel ou quels Threads principaux attendent l'un l'autre pour provoquer une impasse , Et pourquoi la serrure de la vie et de la mort .
Comme vous pouvez le voir, c'est basé sur le système traditionnel de carton pour surveiller la saisie , Sujet aux faux positifs .Pourquoi?? Les sections vertes et rouges de la figure sont les différentes phases de temps du fil principal . Si le fil principal est maintenant bloqué au - delà du seuil de blocage , Ce qui s'est passé dans le numéro 5 Temps écoulé , Nous allons maintenant récupérer la pile d'appels du fil principal , Apparemment, ce n'est pas la principale raison du temps , En fait, le problème se pose principalement dans le contexte de la 4 Temps écoulé , Mais en ce moment 4 Le temps est écoulé. , Il y aura donc une fausse alerte , Cela pourrait laisser les développeurs manquer le vrai problème .
Pour les points de douleur mentionnés ci - dessus , Nous avons proposé deux solutions : Tout d'abord, vous pouvez saisir la pile d'appels du thread principal plusieurs fois lorsque la surveillance est bloquée , Et enregistrer l'état du fil du fil principal à différents moments , ..Quelles informations sont incluses dans l'état du fil , La page suivante mentionne .
De plus, nous pouvons identifier automatiquement les problèmes de blocage causés par l'impasse , Identifier ces problèmes , Et peut aider les développeurs à restaurer automatiquement les relations d'attente de verrouillage entre les fils individuels .
Premièrement, le premier outil d'attribution ——État du fil, Ce graphique est l'information que le thread principal appelle la pile à différents moments , Trois après chaque nom de fil tag , Il s'agit de l'état des trois Threads , Y compris les fils de l'époque CPU Occupation、 État de fonctionnement du fil et drapeaux du fil .
Le côté droit de l'image ci - dessus est l'état de fonctionnement du thread et l'explication du drapeau du thread . Quand vous voyez l'état du fil , Nos principales idées d'analyse sont les suivantes: :Première catégorie, Si vous voyez le fil principal CPU L'occupation est 0, Actuellement en attente , A été remplacé par , Alors nous avons des raisons de soupçonner que le blocage actuel pourrait être dû à une impasse ;Un autre, Les caractéristiques diffèrent ,Du fil principal CPU L'occupation a été élevée , En état de fonctionnement , Alors il faut se demander s'il y a des boucles mortes dans le fil principal, etc CPU Tâches intensives.
Le deuxième outil d'attribution est l'analyse des fils de blocage , Cette fonction est relativement nouvelle , Donc d'abord, je vais vous montrer comment ça marche . Basé sur l'état du fil mentionné à la page précédente , Nous pouvons obtenir l'état de tous les Threads lorsque la carte est morte et filtrer tous les Threads en attente , Puis obtenir le courant de chaque thread PC Adresse, C'est la méthode en cours d'exécution. , Et si c'est un moyen de verrouiller l'attente par symbolisation .
La figure ci - dessus énumère quelques - unes des méthodes d'attente de verrouillage que nous couvrons actuellement ,Y compris mutex、Lire et écrire la serrure、Spin Lock、 GCD La serrure!. Chaque méthode de verrouillage en attente définit un paramètre , Informations entrantes en attente de verrouillage actuel . Nous pouvons lire ces informations d'attente de verrouillage à partir du registre , Fort à la structure correspondante , Un thread est défini dans chaque structure idPropriétés de, Indique quel thread attend actuellement que ce thread libère le verrou . Après une telle série d'opérations pour chaque thread en attente , Nous pouvons obtenir une relation d'attente de verrouillage complète pour tous les fils , Et construire un diagramme d'attente de verrouillage .
Adoption du programme susmentionné, Nous pouvons identifier automatiquement les fils bloqués . Si on pouvait juger 0 Le thread n° 1 attend 3 Thread release Lock , En même temps3 Le thread n° 1 attend 0 Thread release Lock , Donc C'est évidemment deux fils qui attendent l'un l'autre et qui finissent par se bloquer. .
Comme vous pouvez le voir ici, le fil principal est marqué comme une impasse. ,C'est... CPU L'occupation est 0, L'état est l'état d'attente , Et a été remplacé par , Cela correspond à notre méthodologie précédente d'analyse de l'état du fil .
Après une telle analyse , Nous pouvons construire un diagramme d'attente de verrouillage complet , Et qu'il s'agisse d'un problème d'impasse causé par deux fils ou plus qui attendent l'un l'autre , Peut être identifié et analysé automatiquement .
C'est une source schématique du problème d'impasse dans l'image ci - dessus . Le problème est que le thread principal détient un mutex , Sous - thread hold GCD Verrouillage, L'attente entre les deux fils a causé une impasse . La solution présentée ici est : S'il peut y avoir des opérations longues dans le Sous - thread , Essayez de ne pas entrer en concurrence avec le thread principal ; En outre, si l'exécution est synchronisée dans une file d'attente série block Et si,Soyez prudent..
L'image ci - dessus est un outil de surveillance et d'attribution sur la ligne interne des octets , Résumez les causes les plus courantes de blocage des déclencheurs , Des impasses, respectivement 、Concours de serrures、Le fil principalIO、Communication inter - processus.
3.3 Troisième catégorie de problèmes difficiles —— OOM
OOM C'est Out Of Memory, Cela signifie que l'application consomme trop de mémoire , Un crash qui a finalement été tué par le système. .
OOM Quels sont les dangers de l'effondrement ? Tout d'abord, nous pensons que les utilisateurs utilisent App Plus le temps est long , Plus c'est facile OOM Crash,Alors dis OOM L'écrasement nuit beaucoup à l'expérience de l'utilisateur ;Affichage des statistiques,Si OOM Les problèmes ne sont pas gérés de façon systématique , Son échelle est généralement ordinaire Crash De 3-5 X. Enfin, les problèmes de mémoire sont différents Crash Et coincé ,Relativement discret, Très facile à dégrader lors d'itérations rapides .
Alors OOM Quelles sont les difficultés d'attribution des problèmes? ? Tout d'abord, la composition de la mémoire est très compliquée , Il n'y a pas d'informations très explicites sur la pile d'appels d'exception . De plus, nous avons des outils hors ligne pour résoudre les problèmes de mémoire ,Par exemple, Xcode MemoryGraph Et Instruments Allocations, Mais ces outils hors ligne ne s'appliquent pas aux scènes en ligne .C'est aussi pour cette raison que, Si le développeur veut simuler et reproduire hors ligne OOM La question est très difficile .
Voici la solution en ligne OOM Les outils d'attribution des problèmes difficiles sont: MemoryGraph.Ici. MemoryGraph Se réfère principalement à ce qui peut être utilisé dans l'environnement en ligne MemoryGraph.Suivez - moi. Xcode MemoryGraph Il y a quelque chose comme, Mais il y a aussi des différences . La plus grande différence, bien sûr, est qu'il peut être utilisé dans un environnement en ligne , Deuxièmement, il peut compter et agréger les noeuds de mémoire dispersés , Permet au développeur de localiser l'empreinte mémoire de l'en - tête .
Voici un aperçu de la ligne MemoryGraph La raison d'être de: D'abord, on va le tester régulièrement. App Utilisation de la mémoire physique pour , Quand il dépasse le seuil de danger , Déclenche la mémoire dump,En ce moment SDK Les informations signées pour chaque noeud mémoire sont enregistrées , Et leurs références mutuelles , S'il est possible de déterminer s'il s'agit d'une référence forte ou d'une référence faible , Vous pouvez également signaler cette référence forte ou faible en même temps , Finalement, l'ensemble de l'information a été enregistré dans les coulisses , Pour aider les développeurs à analyser les problèmes d'exception tels que la grande consommation de mémoire et les fuites de mémoire .
Voici un exemple pratique pour vous montrer MemoryGraph Comment résoudre exactement OOM Problématique.
Analyse MemoryGraph L'idée d'un document est généralement d'éplucher un cocon , Trouver les causes profondes étape par étape .
L'image ci - dessus est MemoryGraph Un exemple d'analyse de fichier , La boîte rouge ici indique différentes zones : En haut à gauche se trouve la liste des classes , Il résume le nombre d'objets du même type et la taille de la mémoire qu'ils consomment ; A droite se trouve la liste des adresses de toutes les instances de cette classe , Les développeurs de la zone inférieure droite peuvent retracer manuellement les relations de référence des objets ( Quels autres objets se réfèrent à l'objet courant 、 Quels autres objets il fait référence ), La zone la plus large au milieu est le diagramme de référence .
Parce qu'il n'est pas pratique de lire la vidéo , Donc voici quelques conclusions clés : Voir d'abord la liste des classes ,Ce n'est pas difficile à découvrir. ImageIO Les objets de type ont 47 - Oui.,Mais ça... 47 Un objet a pris 500 Beaucoup. MB Mémoire, Apparemment, ce n'est pas une utilisation raisonnable de la mémoire .Allons - y. ImageIO Liste des classes pour , Prenons par exemple le premier objet , Retraçant ses références . Nous avons découvert qu'il n'y avait qu'une seule référence à cet objet ,C'est VM Stack: Rust Client Callback , En fait, c'est au bas du flybook. Rust Fils de bibliothèque réseau .
J'ai vérifié ici.,Tout le monde sera curieux.:Voilà. 47 Tous les objets ont - ils la même relation de référence? ? Ici, nous pouvons utiliser le chemin en bas à droite add tag Fonction, Filtrer automatiquement ceci 47 Existe - t - il la même relation de référence pour les objets . Vous pouvez voir le coin supérieur droit de l'image ci - dessus , Après avoir passé le filtre , Nous confirmons que 47 Objets 100% Ont la même relation de référence .
On va analyser VM Stack: Rust Client CallbackCet objet. Il a trouvé deux noms très sensibles parmi les objets qu'il a référencés ,L'un est ImageRequest,L'autre est ImageDecoder , On peut facilement déduire de ces deux noms : Devrait être l'objet de la demande d'image et du décodage d'image .
Nous utilisons ces deux mots clés pour rechercher dans la liste des classes ,On peut le découvrir. ImageRequest Les objets ont 48 - Oui.,ImageDecoder Les objets ont 47 - Oui..Si tout le monde a encore une impression, L'objet qui prend le plus de mémoire sur la page précédente ImageIO C'est aussi 47 - Oui.. Ce n'est évidemment pas une coïncidence , Nous allons vérifier les relations de référence entre ces deux types d'objets , Nous avons constaté que ces deux types d'objets sont également 100% Par VM Stack: Rust Client Callback Objet référencé.
Finalement, nous avons localisé la cause du problème avec nos camarades de classe de flybook Photo Library : Demandes concurrentes en même temps 47 Image et décodage , Ce n'est pas une conception raisonnable . La cause profonde du problème est que le téléchargeur de flybook Picture Library dépend de NSOperationQueue Gérer et programmer les tâches , Mais il n'y a pas de concurrence maximale configurée , Dans des scénarios extrêmes, il peut y avoir un problème d'utilisation excessive de la mémoire . La solution correspondante est de définir le nombre maximum de concurrence pour le téléchargeur d'images , Et ajuster la priorité en fonction de si l'image à charger est dans la zone de visualisation .
La figure ci - dessus est un outil de surveillance et d'attribution en ligne à l'intérieur des octets , Résumez les types de déclencheurs les plus courants OOM Cause du problème,Respectivement.:Fuite de mémoire, C'est plus commun ; Le deuxième est l'accumulation de mémoire ,Se réfère principalement à AutoreleasePool Pas nettoyé à temps; Troisièmement, les ressources sont anormales , Comme charger une image surdimensionnée ou une image surdimensionnée PDF Documentation; Le dernier est une mauvaise utilisation de la mémoire , Par exemple, le cache mémoire n'a pas de mécanisme conçu pour éliminer le nettoyage .
3.4 No Quatre Problèmes de classe —— CPU Exceptions et disques I/O Anomalie
La raison pour laquelle ces deux types de problèmes sont combinés ici , Parce que ces deux types de problèmes sont très similaires : Tout d'abord, il s'agit d'une occupation anormale des ressources. ; Et ils sont tous différents de la retraite éclair. , La cause de l'effondrement n'a pas eu lieu en un instant , Et c'est l'utilisation anormale des ressources pendant un certain temps .
Anomalie CPU Occupation et disque I/O Quels sont les dangers de l'occupation ? D'abord, nous pensons que , Ces deux types de problèmes, même s'ils n'aboutissent pas à App Crash, Il est également particulièrement susceptible de causer des problèmes de performance tels que le blocage ou le repassage de l'équipement. . Deuxièmement, l'ampleur de ces deux types de problèmes ne peut être ignorée . En outre, par rapport aux problèmes de stabilité précédents , Les développeurs ne sont pas familiers avec ce genre de problèmes , Attention insuffisante , Très facile à dégrader .
Quelles sont les difficultés d'attribution de ces problèmes ? Tout d'abord, il vient d'être mentionné que sa durée est très longue , La cause n'est peut - être pas unique ; De même, l'environnement d'utilisation et le chemin d'exploitation de l'utilisateur sont complexes. , Il est également difficile pour les développeurs de reproduire ces problèmes hors ligne ;Et si App Pour surveiller et attribuer de tels problèmes à l'état utilisateur , L'information sur la pile d'appels échantillonnée à haute fréquence peut être nécessaire pendant un certain temps. , Cependant, il est clair que la perte de rendement de cette méthode de surveillance est très élevée .
Sur le côté gauche de l'image ci - dessus, nous sommes iOS Un segment exporté dans l'appareil CPU Journal d'écrasement anormalement occupé , J'ai intercepté la partie critique . Cette partie de l'information signifie :En cours App In 3 Dans les minutes CPU L'occupation du temps a dépassé 80%, C'est plus que 144 Secondes, Ça a finalement déclenché cet effondrement .
Sur la photo ci - dessus, à droite, j'ai pris la pomme. WWDC2020 Un session Capture d'écran de , Apple Officials on such issues , Quelques suggestions de schéma d'attribution sont présentées. :D'abord Xcode Organizer, C'est l'arrière - plan officiel d'Apple pour la surveillance des problèmes . Puis il y a la suggestion que les développeurs peuvent également accéder à MetricKit , La nouvelle version parle de CPU Informations diagnostiques anormales .
Le côté gauche de l'image ci - dessus est le journal de crash pour les écritures d'exception de disque ,Aussi de iOS Exporter dans l'appareil , Encore une fois, il n'a intercepté que la partie critique. :In 24 Dans les heures,App La quantité d'écriture sur le disque a dépassé 1073 MB, Ça a finalement déclenché cet effondrement .
Sur le côté droit de l'image ci - dessus se trouve le document officiel d'Apple , Des conseils sur l'attribution de tels problèmes sont également donnés . Encore deux suggestions : L'un est la dépendance Xcode Organizer, L'autre est la dépendance MetricKit. Nous avons finalement décidé d'adopter MetricKit Programme, La principale considération est de garder les sources de données entre vos mains. .Parce que Xcode Organizer Après tout, c'est la boîte noire d'une pomme. , Nous n'avons pas accès aux coulisses du Groupe , Il est encore plus difficile de construire une alarme 、 Attribution automatique des questions 、issue Processus de suivi comme la gestion de l'état .
MetricKit Est le cadre officiel d'Apple pour l'analyse du rendement et le diagnostic des problèmes de stabilité , Parce que c'est une bibliothèque système , Donc il a une faible perte de performance .In iOS 14 Au - dessus du système,Basé surMetrickit, Nous pouvons facilement obtenir CPU Et le disque I/O Informations diagnostiques anormales . Son intégration est également très pratique . Il suffit d'importer le fichier d'en - tête de la Bibliothèque système , Configurer un auditeur , Dans le rappel correspondant CPU Et écrire des informations diagnostiques anormales sur le disque pour l'analyse de fond .
En fait, les formats d'information diagnostique de ces deux types d'anomalies sont très similaires. , Il s'agit d'enregistrer les appels de toutes les méthodes au fil du temps et le temps écoulé pour chaque méthode . Après avoir escaladé les coulisses , Nous pouvons visualiser ces données comme des diagrammes de flamme très intuitifs . Par cette forme intuitive , Aide les développeurs à localiser facilement les problèmes . Pour le diagramme de flamme à droite dans l'illustration ci - dessus ,Nous pouvons simplement comprendre que: Plus le bloc rectangulaire est long ,Occupé CPU Plus ça prendra de temps . Il suffit de trouver le plus long bloc rectangulaire App Pile d'appels, Pour trouver le problème. . La boîte rouge surlignée de l'image , Les mots clés d'une de ces méthodes sont animateForNext, C'est un programme d'animation. .
Finalement, nous nous sommes penchés sur la cause du problème avec nos camarades de classe de flybook : Flipbook applet Business a une animation qui ne s'arrête pas quand elle est cachée ,A causé CPU L'occupation continue est élevée . .La solution est aussi très simple , Il suffit de mettre l'animation en pause pendant qu'elle est cachée .

Quatre、Examen sommaire

Dans le deuxième chapitre, la méthodologie de gouvernance des problèmes de stabilité ,J'ai mentionné“ Si vous voulez résoudre le problème de stabilité, , C'est ce qu'il faut faire à chaque étape du cycle de développement du logiciel , Y compris la découverte du problème 、Attribution、 Gouvernance et prévention de la détérioration ”, En même temps, nous pensons que l'attribution des problèmes en ligne, en particulier des problèmes difficiles en ligne , Est la priorité absolue de l'ensemble du lien . Pour chaque catégorie de problèmes difficiles , Ce partage fournit des outils d'attribution utiles :Crash Oui. Zombie Surveillance et Coredump;Watchdog Analyse de l'état du fil et du fil bloqué ;OOM Oui. MemoryGraph;CPU Et le disque I/O Les exceptions sont MetricKit.

 

Schéma d'attribution pour tous les problèmes difficiles mentionnés dans ce partage ,Sauf queMetricKit Au - delà, Les autres sont des sauts d'octets auto - développés , La communauté open source n'a pas encore de solution complète . Ces outils et plates - formes seront suivis par des octets Suite de développement d'applications de moteurs volcaniques MARS Sous le drapeau APM Plus Plate - forme Fournir une solution d'entreprise à guichet unique . Toutes les capacités mentionnées dans ce partage ont été validées et polies dans les principaux produits en octets pendant de nombreuses années , Sa propre stabilité et l'effet commercial après l'accès sont évidents , Je vous souhaite une attention soutenue. .
 

版权声明
本文为[Technologie du terminal de saut d'octets]所创,转载请带上原文链接,感谢
https://cdmana.com/2021/11/20211125171653785Y.html

Scroll to Top