Série d'optimisation des performances iOS 07｜Un processus de convergence des causes profondes du dépannage des performances iOS

Lors du dépannage des performances iOS, le plus ennuyeux est que la scène est souvent désordonnée dès le début.

Le produit a déclaré que la page d’accueil était bloquée, le test a indiqué qu’il s’agissait d’une suppression d’images dans la liste, le développement a pensé qu’il s’agissait peut-être des images et le backend soupçonnait que l’interface était lente. Tout le monde parle comme une question, mais quand on commence à y regarder, on constate souvent qu’ils ne décrivent pas du tout la même chose.

Après avoir fait ce genre de travail plusieurs fois, mon plus grand sentiment est : **Le dépannage des performances commence par les problèmes de convergence, suivi de l’analyse des données. **

Si le problème n’est pas résolu en premier, plus vous ouvrez d’outils, plus il sera facile de vous égarer. Parce que chaque indicateur que vous voyez semble contenir des informations, mais chaque information ne suffit pas pour tirer une conclusion.

L’article suivant ne parle pas de « comment dépanner théoriquement », mais écrit selon le rythme qui se produira dans un projet réel : Comment le problème de perte de trame dans le flux d’informations de la page d’accueil est-il passé du “sentiment un peu bloqué” étape par étape jusqu’au point où il peut être résolu manuellement ?

Clouez d’abord la scène, sinon toutes les analyses ultérieures seront perdues.

La description initiale de ce problème était très ordinaire :

• La page d’accueil ne glisse pas facilement *Certains modèles sont plus évidents
• La dernière version semble encore plus bloquée.

Cette description ressemble à une information, mais en réalité il est presque impossible de l’utiliser directement pour le dépannage. Parce qu’il est mélangé à au moins trois couches de choses :

*La plage de pages n’est pas claire *Le type de phénomène n’est pas clair *Les conditions de réapparition ne sont pas claires

La description qui a réellement commencé à fonctionner s’est finalement réduite à ceci :

iPhone 13 Pro, iOS 18, compte de connexion A, démarrage à froid pour accéder au flux de recommandation de la page d’accueil, passez à l’onglet « Suivre » une fois le premier écran chargé, puis revenez au flux de recommandation, faites glisser votre doigt vers le haut 4 écrans d’affilée et continuez à supprimer des images à partir du 3ème écran. Le problème se produit principalement dans la disposition mixte des graphiques et du texte et dans la disposition mixte des cartes vidéo.

L’importance de ce passage n’est pas qu’il soit écrit comme un cas de test, mais qu’il élimine d’un coup beaucoup d’ambiguïtés :

*C’est la carte de flux recommandée sur la page d’accueil *C’est plus évident la deuxième fois que vous entrez *fait défiler et laisse tomber des images *La zone où les images et les textes se mélangent est plus évidente.

Le véritable début de l’enquête commence souvent par cette « définition de la portée ». Sans cette étape, toute « analyse » ultérieure pourrait simplement se résumer à sa propre imagination.

Ne vous précipitez pas pour examiner les outils en premier, déterminez d’abord s’il s’agit d’un gel occasionnel ou d’une fréquence d’images faible et continue.

Les quatre mots « ne glisse pas en douceur » peuvent en réalité correspondre à des problèmes complètement différents.

La première chose que j’ai faite cette fois-là a été d’enregistrer l’écran et de le faire glisser plusieurs fois pour caractériser le phénomène.

En fin de compte, il s’agit d’une fréquence d’images faible et soutenue très typique :

• Une fois entré dans une zone de contenu spécifique, plusieurs écrans consécutifs ne se dérouleront pas correctement. *est lourd pendant toute la phase de roulage
• Le sentiment subjectif de l’utilisateur est que « cette section ne peut pas glisser »

Cette distinction est très importante.

Parce que les décalages occasionnels ressemblent généralement davantage à :

• Un certain décodage d’image a soudainement touché le fil principal
• Le temps d’initialisation d’un gros objet est erroné
• Une certaine passe de mise en page devient parfois lourde

Et les images basses soutenues ressemblent davantage à :

• Faire un travail répétitif à chaque image
• La structure cellulaire elle-même est trop lourde
• Les résultats asynchrones sont continuellement remplis pendant le défilement
• La plage d’actualisation de l’état de la liste est trop grande

Si ces deux types de problèmes ne sont pas séparés au départ, les données ultérieures seront facilement mal interprétées.

Le chemin de reproduction doit être noté, sinon les mots “modifié” n’auront aucun sens.

L’un des symptômes les plus courants des problèmes de performances est le suivant : “C’était évident tout à l’heure, mais maintenant c’est parti”.

Ainsi, lors de ce dépannage, la première mesure que j’ai prise a été stupide, mais très précieuse : écrire le chemin de récurrence en étapes fixes.

Ce qui a été réglé à ce moment-là était :

1. Tuez l’application et redémarrez à froid
2. Connectez-vous au compte A
3. Entrez dans le flux de recommandation de la page d’accueil et attendez que le premier écran soit complètement stable.
4. Passez à l’onglet « Suivre »
5. Revenez au flux de recommandations
6. Faites glisser 4 écrans vers le haut en succession rapide
7. Observez les performances de fréquence d’images et l’occupation du thread principal à partir du troisième écran

Pensez également à l’environnement :

*Modèle d’équipement *Version du système *Conditions du réseau

• Niveau de données
• S’il faut activer le commutateur de débogage

L’importance de ceci n’est pas seulement de faciliter la reproduction par d’autres, mais plus important encore, de faciliter la vérification ultérieure.

Parce que la phrase la plus inutile en matière d’optimisation des performances est :

Je me sens mieux qu’avant.

Il n’y a pas de chemin fixe et le mot « éviter » n’a aucune valeur analytique. C’est peut-être simplement parce que les données sont différentes, le réseau est différent, la page ne glisse pas vers le même paragraphe, ou même le doigt ne glisse pas aussi vite cette fois.

Le premier tour de jugement ne trouve pas la cause profonde, mais détermine uniquement sur quel lien réside le problème.

Lorsque je commence à traiter ce type de problème, je veux demander :

• Quelle ligne de code est lente ?
• Quelle fonction prend le plus de temps ?
• Quelle bibliothèque pose problème ?

Mais dans une véritable enquête, il est généralement trop tôt pour poser la question.

Ce que j’ai fait en premier cette fois-là, c’était une segmentation grossière des liens :

Est-ce un problème de données ou un problème de rendu ?

Cette étape est essentielle, car une page d’accueil lente peut facilement faire douter instinctivement les gens de l’interface.

J’ai d’abord fait une vérification très directe : Essayez de corriger les résultats du réseau autant que possible, de sorte que les données lors de la deuxième saisie du flux de recommandation proviennent de résultats existants plutôt que de modifications du réseau.

Le résultat est clair : Les données sont revenues, le défilement est toujours lourd et stable.

Cette étape peut essentiellement éliminer le « défilement bloqué en raison d’une interface lente » du problème principal.

L’interface lente affectera le premier temps d’écran, mais elle n’explique pas “après une deuxième entrée, un certain élément de contenu commence à avoir des images basses continues”.

Est-ce le thread principal qui est occupé, ou est-ce que le travail en arrière-plan revient sans cesse au thread principal ?

La prochaine chose à examiner est ce que fait le thread principal lorsque la carte est bloquée.

Le but de cette étape est également de déterminer dans un premier temps la forme du problème :

• Le fil principal continue d’être occupé
• Ou les rappels en arrière-plan sont trop denses et le thread principal est interrompu les uns après les autres.

La dernière chose que j’ai vue était plutôt la première : Le fil conducteur n’est pas toujours centré sur la phase de défilement.

Cela montre que la direction commence à devenir claire :

• L’accent n’est pas mis sur le réseau
• L’accent n’est pas mis sur une seule grande tâche
• Le focus ressemble plus à un lien d’affichage de liste lui-même qui est trop lourd

S’agit-il d’un point d’exception unique ou d’une surcharge systémique ?

C’est un jugement que j’apprécie à chaque fois.

Si une seule fonction s’épuise occasionnellement pendant 200 ms, c’est facile à gérer, il suffit de l’attraper. Mais ce n’était pas le cas cette fois-là.

La vraie chose gênante à cette époque était qu’il n’y avait rien de si scandaleux que d’être “un vrai tueur en un coup d’œil”, mais beaucoup de petites dépenses qui n’étaient pas exagérées étaient empilées, et elles tombaient toutes sur le chemin critique défilant.

Ce type de problème est le plus ennuyeux, car il n’a pas de pile particulièrement claire comme un crash. C’est plutôt comme si le système vous disait que chaque petite décision qui était « écrite comme ça » dans le passé est désormais imputée ensemble.

Cela vaut seulement la peine d’ouvrir Instruments à ce stade, et cela doit être fait avec suspicion.

Je n’ai jamais vraiment aimé l’approche de dépannage « ouvrir tous les outils d’abord, puis parler ». Il est si facile d’utiliser des outils comme substituts à la réflexion.

Avant d’entrer dans Instruments cette fois-là, j’avais en fait plusieurs doutes en tête :

Suspicion 1 : Le lien vers l’image place dans la période glissante les travaux qui ne devraient pas être placés dans la période glissante.

Il s’agit du suspect le plus courant dans les scénarios de flux d’informations.

Surtout :

• La taille de l’image de couverture n’est pas uniforme
• Disposition mixte de cartes graphiques, texte et vidéo
• Le rythme de remplissage des images est instable
• Avant l’affichage, des traitements tels que les coins arrondis, les ombres et la mise à l’échelle sont également effectués.

Si tout ce travail se produit réellement pendant le défilement, la fréquence d’images sera difficile à stabiliser.

Suspicion 2 : La présentation cellulaire a été préparée trop tard

De nombreuses listes semblent « logiquement claires » au premier abord, mais lorsque vous faites défiler l’équipement, un vieux problème apparaîtra :

Un grand travail de préparation à l’affichage est effectué lorsque la cellule est sur le point d’être affichée.

Par exemple :

• Assemblage de texte enrichi *Découpe de rédaction
• Formatage de l’heure *Calcul d’altitude
• Jugement du statut de l’interface utilisateur
• Préparation des objets enterrés

Chaque élément n’est pas si gros en soi, mais une fois qu’ils sont tous insérés dans le chemin critique défilant, il passera de « acceptable » à « la liste entière est lourde ».

Suspicion 3 : La plage d’actualisation du statut est trop large

Cette situation est particulièrement courante dans les architectures réactives.

En apparence, il s’agit simplement d’un changement de statut de carte, mais ce qui est en réalité déclenché est :

• Reliure au niveau de la section
• Trop de différences locales
• Couplage du reporting d’exposition et du rafraîchissement de l’interface utilisateur
• Les rappels de préchargement reviennent fréquemment au fil de discussion principal

Ce type de problème est le plus ennuyeux, car il ne provoque pas nécessairement un pic particulièrement élevé sur une certaine fonction, mais l’expérience globale sera toujours médiocre.

Ce qui restreint vraiment la direction, ce sont quelques séries d’expériences bon marché.

Cette fois-là, nous avons vraiment réduit le problème à quelques séries d’expériences très simples.

Expérience 1 : Remplacer toutes les images par des images d’espace réservé

Cette expérience est très grossière, mais extrêmement utile.

Une fois l’image remplacée, le défilement est évidemment de retour. Cette étape n’explique pas directement que la cause première est « trop d’images », mais elle suffit à montrer que les liens d’images doivent être l’une des directions principales.

Si vous continuez à demander à ce moment-là, ce ne sera plus un « oui » général mais plus précis :

• Si le décodage tombe sur le fil principal
• La stratégie de taille est-elle incohérente ?
• Le remplissage d’images entraîne-t-il une nouvelle mise en page ?
• Y a-t-il trop de traitements supplémentaires effectués avant l’affichage ?

Expérience 2 : Prétraiter une partie du texte dynamique de la cellule

Avec ce changement, le défilement a également été considérablement amélioré.

Cela montre que l’autre sens est également vrai : Il est en effet trop tard pour préparer la liste avant qu’elle ne soit présentée, et il y a plus d’une ou deux de ces tâches.

En d’autres termes, le problème est que le lien image et le lien présentation sont dupliqués ensemble.

Expérience 3 : désactivez temporairement ces actions de bord telles que l’exposition, le préchargement et la lecture automatique

Après cette série d’expériences, la fréquence d’images a continué à se stabiliser.

À ce stade, le problème est fondamentalement clair : C’est le flux d’informations de la page d’accueil qui implique trop de travail de type « faites-le » pendant la phase de défilement.

Ces tâches semblent généralement raisonnables en elles-mêmes :

• Les photos doivent être remplies
• L’exposition doit être déclarée
• Le préchargement doit être effectué
• La carte vidéo doit être réchauffée

Mais lorsqu’ils se produisent ensemble sur le chemin critique défilant, ils font tomber toute la liste.

La véritable cause profonde ressemble en fin de compte à un ensemble de mauvaises décisions

Lorsqu’il a finalement atterri, le vrai problème était probablement cette combinaison de coups :

• La stratégie de taille d’image n’est pas uniforme, ce qui entraîne des coûts de traitement avant affichage
• Certaines images sont décodées trop tard
• Le travail de préparation de l’affichage des cellules est effectué sur site dans le fil principal
• Les rappels d’exposition et de préchargement sont trop denses pendant la période de défilement * La liste des changements d’état local déclenche une plage de rafraîchissement plus large que prévu

Voilà à quoi ressemblent réellement de nombreux problèmes de performances.

Ce n’est pas la fin de la “ligne 357 trouvée”, Mais au final, vous constaterez que la conception de plusieurs couches n’est pas assez restreinte, et finalement elles seront réglées ensemble lors de la phase de laminage.

Par conséquent, je déteste de plus en plus l’argument selon lequel « il doit y avoir une fonction clé pour les problèmes de performances ». Bien sûr, cela se produit dans des projets réels, mais le plus souvent il s’agit « d’un ensemble de mauvaises formes accumulées depuis longtemps ».

La phase de vérification a surtout peur des sentiments subjectifs. Il faut revenir par le même chemin pour comparer.

Après la modification, le problème n’a pas été résolu directement, mais le chemin de récurrence d’origine a été repris.

Le même appareil, le même compte, la même méthode de commutation, le même glissement vers la zone de contenu, puis regardez :

• Les chutes d’images se produisent-elles toujours de manière stable ?
• Le fil conducteur se concentre-t-il toujours sur la même période ?
• Les comportements de remplissage et de contour des images sont-ils toujours en concurrence avec le défilement pour rivaliser avec le fil principal ?

À cette étape, j’ai également examiné les effets secondaires :

• Une fois le lien image connecté, y a-t-il une augmentation significative de la mémoire ?
• Si vous effectuez trop de prétraitement, le premier écran deviendra-t-il plus lent ?
• La déclaration de l’exposition est retardée. Les statistiques seront-elles affectées ?

Une erreur souvent commise en optimisation des performances : Ils se concentrent uniquement sur “si un indicateur semble bon”, mais ne cherchent pas à savoir s’il a remplacé d’autres problèmes.

Mais dans le travail réel, l’optimisation est toujours une question d’échange dans l’expérience globale. Un échange acceptable est appelé optimisation, l’échange d’autres problèmes n’est pas appelé optimisation.

Ce type d’article est le plus susceptible d’être écrit sous forme de paroles vides de sens, mais c’est également l’endroit le plus réaliste pour le dépannage des performances.

De nombreux articles de synthèse finiront par écrire :

• Définissez d’abord le problème
• Établir une hypothèse
• Pour vérifier les résultats

Ces paroles sont certainement vraies, mais elles peuvent trop facilement se transformer en absurdités.

La différence dans l’expérience réelle n’est pas de savoir si vous pouvez prononcer ces mots, mais si vous avez vécu les moments suivants :

• Au début, tout le monde disait que cela ressemblait au même problème, mais en fait, ce n’était pas du tout le même problème.
• La direction qui ressemble le plus à la cause profonde à première vue n’est en fin de compte qu’un faux indice.
• Chaque indicateur de l’outil semble anormal, mais il n’y a qu’une seule véritable ligne principale
• La réponse finale est un ensemble de petits frais généraux qui s’additionnent au fil du temps

Une fois que vous aurez fait ces choses plusieurs fois, vous comprendrez naturellement une chose :

**La véritable valeur du dépannage des performances est la suivante : “puis-je transformer une scène chaotique en un lien exploitable ?” **Cela ne peut pas être fait, plus il y a d’outils, plus ce sera compliqué. En faisant cela, vous pouvez vous rapprocher de plus en plus de la cause profonde de nombreux problèmes sans passer par tous les graphiques.

Lorsque j’examine les problèmes de performances maintenant, ce qui m’importe le plus est de savoir si nous pouvons amener l’équipe à se mettre d’accord sur les points suivants le plus rapidement possible :

Nous étudions actuellement le même problème et nous savons déjà à quel lien il correspond principalement.

Tant que cela est établi, les réparations ultérieures ne sont généralement pas trop déroutantes. Ce qui est vraiment difficile, c’est toujours de rassembler le problème sous une forme qui puisse être résolue.