arrière-planintroduire
Sur le marché des smartphones, ce sont souvent les modèles haut de gamme qui attirent le plus l'attention, mais les modèles bas de gamme occupent également une part incontournable. Afin de répondre aux besoins du marché bas de gamme, de nombreux fabricants continuent de lancer des séries de téléphones mobiles bas de gamme. De plus, les modèles milieu à haut de gamme de ces dernières années sont désormais classés comme modèles bas de gamme avec une itération rapide du matériel système. iQiyi APP dispose d'une énorme base d'utilisateurs, parmi laquelle les utilisateurs de modèles bas de gamme représentent également une part considérable. L'optimisation des machines bas de gamme peut apporter une expérience utilisateur stable, fluide et efficace à ces utilisateurs. Ce qui suit présentera la stratégie d'optimisation d'iQiyi APP pour les machines bas de gamme à partir de trois dimensions : démarrage à froid, fluidité et vitesse de chargement.
Stratégie de classement de machines bas de gamme
Avant d'introduire l'optimisation, examinons les normes des machines bas de gamme. Le jugement des machines bas de gamme est généralement basé sur des facteurs tels que le modèle de l'appareil, la taille de la mémoire et la version du système. iQiyi APP dispose de sa propre stratégie de notation de machine bas de gamme, qui peut configurer des stratégies d'optimisation par scénario (démarrage, maîtrise, etc.) et niveaux (mémoire, modèle, système, etc.) dans le contexte politique pour garantir la meilleure expérience dans différents scénarios.
Démarrer l'optimisation
Le lancement est la première porte qu'une application ouvre aux utilisateurs. Son temps affecte directement l'expérience de visualisation et la rétention ultérieures de l'utilisateur, et a un impact significatif sur les indicateurs commerciaux. Par conséquent, l’optimisation du démarrage est un contenu de travail clé dans le sens de l’optimisation technique.
Introduction connexe
Le point de départ et le point final de la phase de démarrage : iQiyi APP utilise Application.attachBaseContext comme point de départ ; les données de la page d'accueil affichent le point final. La durée de cette phase est considérée comme l'heure normale de démarrage à froid en ligne. Cela passe principalement par l'étape de création d'application, l'étape de création et d'affichage de MainActivity, la publicité, le chargement et le rendu des données de navigation en haut et en bas de la page d'accueil, le chargement et le rendu des données de la page d'accueil.
Dans ce processus, il est nécessaire de trier le travail effectué par la couche métier, d'évaluer la nécessité et le calendrier de son exécution, ainsi que la rationalité du thread de planification. Il est nécessaire de surveiller l'état du thread principal pour voir s'il est exécuté ; est tombé en veille à long terme ; le message du fil principal/la surveillance et la gestion des messages d'arrière-plan, si des tâches qui ne répondent pas aux attentes sont déclenchées, si les ressources du système sont pleinement utilisées, si les opportunités inactives sont pleinement utilisées pour le préchargement, etc.
Atomisation des fonctions métier : afin de planifier les tâches dans la phase de démarrage de manière ordonnée et d'allouer les ressources de manière raisonnable, un ensemble de cadres de gestion des tâches TaskManager a été développé et la mise en œuvre des fonctions métier a été regroupée en tâches personnalisées, divisées en suffisamment de détails, et conçu Déterminez les dépendances d'exécution entre les tâches, les threads qui doivent être planifiés pour l'exécution, le calendrier d'exécution, etc., puis transmettez-les au TaskManager pour un traitement unifié. Cette couche de gestion des tâches est la base de notre mise en œuvre de l'optimisation du démarrage.
Pratique d'optimisation
Fusion de la page d'accueil de l'écran ouvert
Au début, l'application iQiyi avait deux activités : l'écran d'ouverture et la page d'accueil. Les deux activités entraînaient des problèmes d'expérience utilisateur : la machine bas de gamme était évidemment en retard lorsque l'écran était ouvert et que la page d'accueil était accédée. ne s'affiche pas immédiatement et l'utilisateur peut voir les données de la page d'accueil et les images ont un processus de chargement à partir de zéro.
La plupart des scènes de la phase d'ouverture d'écran comportent des publicités d'ouverture d'écran. Fusionnez l'ouverture d'écran et la page d'accueil en une seule activité. Utilisez la phase de publicité d'ouverture d'écran pour charger la page d'accueil sous la page d'ouverture d'écran et séparez les données de la page d'accueil et l'interface utilisateur. affichage pour le traitement parallèle. En maximisant cette étape, la page d'accueil peut être affichée immédiatement à la fin de l'écran de démarrage, et les décalages sur les machines bas de gamme sont considérablement améliorés .
Le rendu de la page d'accueil a également un certain impact sur l'ouverture de l'écran publicitaire. L'affichage du compte à rebours des publicités est instable et les effets de quelques types de publicités ne sont pas fluides. Le chargement de la page d'accueil est divisé en plusieurs étapes pour résoudre le problème du déclenchement du rappel de la publicité. L'affichage du compte à rebours utilise le rendu surfaceView pour assurer sa stabilité.
Optimisation de la planification des tâches
En fonction du type de démarrage, organisez la séquence d'exécution des tâches dans la phase de démarrage pour avancer, retarder ou ne pas s'exécuter, afin que les utilisateurs puissent voir la page cible le plus tôt possible. Voici les ajustements apportés par iQiyi aux tâches sous le chemin de démarrage normal des machines bas de gamme.
Résoudre les conflits de verrouillage
Concours de verrouillage de chargement de bibliothèque native : le chargement de la bibliothèque de couche C est verrouillé. La couche Java ouvre plusieurs threads pour charger la bibliothèque Lib. Après avoir atteint la couche C, le chargement sera toujours effectué en séquence, ce qui entraînera le blocage du thread de couche Java. et attendre. iQIYI doit charger la bibliothèque Lib au stade de l'application et doit appeler la méthode JNI appropriée une fois que le thread principal attend la fin de son chargement et lorsqu'il rencontre la situation où le module de lecture affiche la page de lecture à des fins externes ; est nécessaire de précharger la lecture. La bibliothèque Lib associée est requise, ce qui fera entrer le thread principal dans un état d'attente. En identifiant la page de destination cible pendant la phase de démarrage, vous pouvez décider d'effectuer ou non le préchargement de la bibliothèque Lib liée à la lecture, évitant ainsi le décalage de la plupart des utilisateurs qui démarrent normalement vers la page d'accueil. (Machine d'essai Redmi K40, système Android12)
Concurrence de verrouillage de ressources : avant l'affichage de la page d'accueil d'iQiyi, d'autres modules préchargent les fichiers de mise en page dans des sous-threads, ce qui entraîne une concurrence féroce pour les verrous de couche LayoutInfalter / ResourceManager / AssertsManager. Planifiez la tâche de préchargement de la mise en page à exécuter après l'affichage de la page d'accueil et limitez l'exécution de la mise en page préchargée dans le même sous-thread. Vous pouvez voir que le nombre de conflits de verrouillage est considérablement réduit après l'amélioration, ce qui permet le. la page d'accueil s'affiche plus rapidement.
Profils de référence
Profils de base : Google lancera des profils de base en 2022, permettant aux développeurs de créer des profils de base de code de point d'accès personnalisés dans apk. Lors de l'installation de l'APP, le système précompile les codes de point d'accès à l'avance via des fichiers de configuration. Vous pouvez ignorer les étapes d'interprétation et de compilation juste à temps des chemins de code inclus dans le runtime pour améliorer la vitesse d'exécution du code au premier démarrage.
Profils de démarrage : les profils de démarrage sont un sous-ensemble des profils de base mentionnés ci-dessus. L'utilisation de profils de démarrage peut améliorer la présentation du code dans le fichier DEX de l'APK, optimisant ainsi davantage les classes et méthodes incluses. iQiyi APP construit le code de la phase de démarrage dans le même fichier DEX via le fichier de configuration de démarrage. En utilisant les deux stratégies ci-dessus, la première vitesse de lancement de l'application iQiyi sur certains modèles est augmentée d'environ 10 %.
Optimisation du lancement des liens externes
L'extraction de liens externes est également un moyen important de démarrer. Elle est généralement lancée par H5, le partage, une application tierce, etc. La différence avec le démarrage à froid normal est que les liens externes ne sont souvent pas la page d'accueil, mais une cible spécifique. page. Le scénario le plus courant pour iQiyi consiste à afficher la page de lecture. Si nous identifions la page de destination à l'avance (étape de candidature), nous pouvons ajuster la priorité des tâches pour la page de destination. Lorsque le lien externe affiche la page de lecture, nous pouvons. identifier la page de lecture à l'avance et y associer le joueur. La tâche est initialisée à l'avance. Grâce à cette stratégie, les liens externes bas de gamme embarqués peuvent accélérer la diffusion d'environ 1,5 seconde.
Optimisation de la fluidité
La plupart des pages de l'application iQiyi sont développées sur la base du framework Card auto-développé. Le framework de cartes est un framework d'interface utilisateur hautement réutilisable sur la base de l'utilisation de code natif pour implémenter la disposition de base de l'interface utilisateur et la logique métier, le style de conteneur de base est contrôlé via le contrôle CSS émis par le backend pour réaliser la réutilisation globale du bloc de page et la dynamique. peaufinage des styles de contenu. C'est une solution pour nous permettant de réaliser une réutilisation globale des pages et un réglage local des deux côtés (Android et IOS). Sur la base de ce framework, la fluidité des pages dans l'APP est optimisée. Le framework Card présente les fonctionnalités suivantes :
-
Haute réutilisabilité : les blocs de contenu (blocs) sont composés de contrôles, les lignes sont composées de plusieurs blocs ; les cartes sont composées de plusieurs lignes et la page de liste entière est composée de plusieurs cartes. La plus petite unité commerciale réutilisable est Block.
-
Hautement dynamique : prend en charge la configuration des fichiers CSS en arrière-plan et la modification dynamique du style d'une certaine interface utilisateur (taille du texte, couleur, coins arrondis, etc.).
Pratique d'optimisation
Style natif
La dynamique et la réutilisabilité de la page Carte entraînent une complexité dans la présentation de l'interface utilisateur. Un type de bloc doit être compatible avec plusieurs styles. Par exemple, les quatre coins d'une image doivent être intégrés avec différents types de logique d'indice. Les types d'indice incluent des images pures, du texte brut, des images + du texte et une sélection facultative. forme moyenne. La mise en œuvre de différents styles entraînera un grand nombre de vues et des niveaux d'imbrication profonds, ce qui rendra certaines pages pas assez fluides pour glisser sur des machines bas de gamme.
Afin d'optimiser cette situation, certaines cartes avec des formes commerciales stables ont été sélectionnées, les styles de ces cartes ont été solidifiés et la mise en page a été considérablement rationalisée. Cela entraîne une augmentation significative de la fréquence d’images lors du glissement de haut en bas. Par exemple, dans la carte de flux Waterfall, nous avons réduit le nombre de vues implémentées de 40+ à 17, et réduit le niveau de mise en page de 6 à 2 couches sur différentes machines bas de gamme , cela a entraîné un glissement de Frame d'environ 10 % à 20 % ; le taux a augmenté .
Afficher le dessin de fusion
L'effet d'amélioration apporté par la stratégie de simplification de la présentation ci-dessus est évident, mais en raison de la diversification des formes d'entreprise, certaines vues nécessaires ne peuvent pas être supprimées. Afin de réduire davantage le nombre et le niveau des vues, plusieurs vues dans les dispositions de bloc couramment utilisées sont fusionnées dans une vue personnalisée, et le canevas de la vue est utilisé pour dessiner du texte, des images, des boutons et d'autres informations de style. Cette méthode peut réduire efficacement le nombre de vues et de niveaux d'imbrication, mais elle doit toujours gérer l'événement de clic et l'effet de pression de chaque élément. Sur les machines bas de gamme , cette stratégie peut entraîner une augmentation glissante de la fréquence d'images d' environ 1 à 2 ips .
Pré-création et chargement asynchrone
Pré-création de mise en page : Parmi les trois styles de cartes présentés dans l'image ci-dessus, le même type de bloc est utilisé (image ci-dessus et ci-dessous). Nous préchargeons ces dispositions de blocs couramment utilisées et hautement réutilisables dans le pool de cache pendant la phase de démarrage, afin que les dispositions pré-créées puissent être directement utilisées dans le glissement de liste, réduisant ainsi le temps de gonflage dans le dessin de l'interface utilisateur.
Création asynchrone de mise en page : la pré-création a un bon effet sur les mises en page couramment utilisées, mais les mises en page peu courantes représentent toujours la majorité. Ce type de mise en page utilise AsyncLayoutInflater pour créer de manière asynchrone la mise en page qui apparaîtra pendant le processus de défilement, réduisant ainsi le temps de création de la mise en page. disposition de défilement dans le fil de l'interface utilisateur. En même temps, cela peut également améliorer l'efficacité de la prélecture de RecyclerView.
Prélecture de RecyclerView : de nombreuses pages de l'application iQiyi utilisent RecyclerView imbriqué pour créer des formulaires de produits à défilement horizontal. La plupart des cartes de ce formulaire afficheront 3 à 5 éléments sur un écran. Différents paramètres de prélecture sont définis en fonction des différents formulaires. peut réduire le décalage lorsque ce type de carte est exposé.
Le thread principal réduit l'exécution de tâches non- UI : il faut du temps pour détecter le thread principal pendant le processus de défilement. On constate que certaines tâches non-dessin sont exécutées sur le thread principal. Le thread UI analyse JSON et établit des liens avec la base de données. , etc. et les place dans des tâches asynchrones pour exécution.
Planification des messages de l'interface utilisateur de démarrage à froid
Pendant le processus de démarrage à froid des machines bas de gamme, la consommation de ressources atteindra progressivement un état maximal ; il y a un grand nombre de messages d'interface utilisateur (qui doivent être exécutés sur le thread d'interface utilisateur) et d'autres tâches en arrière-plan qui doivent être exécutées. Grâce à l'interception et à l'analyse des points enfouis, plus de 4 000 messages (en 15 secondes) doivent être exécutés sur le thread de l'interface utilisateur à ce stade. Le temps d'exécution de ces messages varie de 1 ms à 150 ms sur les machines bas de gamme. Lorsque ces messages sont exécutés, le rendu des messages de l'interface utilisateur du système sera retardé. Sur les machines bas de gamme, les utilisateurs sont confrontés à des problèmes tels qu'un décalage de glissement et une réponse lente au clic lors du premier lancement de l'application.
Pour résoudre ce problème, notre solution consiste à intercepter tous les messages envoyés au thread de l'interface utilisateur et à les ajouter à une file d'attente de messages personnalisée ; puis à surveiller si la file d'attente des messages de l'interface utilisateur du système est inactive et, lorsqu'elle est inactive, à supprimer les messages de la file d'attente personnalisée et à les rediriger. à l'exécution de la file d'attente des messages de l'interface utilisateur du système ; de plus, un mécanisme de liste blanche est ajouté pour publier certains messages de haute qualité. Il existe un mécanisme de secours pour gérer les exceptions.
En planifiant les messages de l'interface utilisateur, le décalage des machines bas de gamme pendant la phase de démarrage à froid a été considérablement amélioré grâce à la surveillance du Big Data en ligne, le nombre d'images gelées et d'images perdues a été considérablement réduit. Pendant la phase de démarrage à froid , la fréquence d'images est augmentée d'environ 8 ips .
Stratégie de dégradation des performances
Sur les machines bas de gamme, la rétrogradation de certains effets peut réduire efficacement le retard dans des scénarios spécifiques. iQiyi APP a mis en œuvre la stratégie de rétrogradation suivante.
Rétrogradation des effets de mouvement : effets de mouvement de navigation haut et bas rétrogradés en images statiques, effets de mouvement de contrôle de lecture désactivés, effets de mouvement simplifiés pour certaines fonctions du produit, etc.
Rétrogradation de la lecture : stratégies telles que lancer la lecture retardée et ne pas démarrer certaines scènes.
Rétrogradation du préchargement de ViewPager : désactive le préchargement des onglets gauche et droit, réduisant ainsi le temps de dessin de la vue et la surcharge de mémoire.
Rétrogradation de l'image : certaines animations de page ne sont pas lues et les images utilisent le format 565 pixels.
Optimisation de la vitesse de chargement
En plus de l'optimisation de démarrage susmentionnée, nous nous concentrons également sur l'optimisation de certaines pages importantes, car ces pages sont visitées très fréquemment par les utilisateurs et leur optimisation peut améliorer considérablement l'expérience utilisateur. Par exemple, la recherche est l’une des fonctions fréquemment utilisées par les utilisateurs, nous avons donc soigneusement disséqué le comportement de recherche et optimisé chaque étape de la recherche.
Pratique d'optimisation
pré-demande
Habituellement, le processus de rendu de page démarre généralement à partir de la méthode onCreate de l'activité. Faites ensuite une requête réseau pour obtenir les données nécessaires. Après avoir obtenu les données spécifiques, la page est affichée. Nous avons également suivi ce processus dans le scénario de recherche précédent.
Est-il possible d'obtenir les données requises à l'avance ?
En effet, lorsque l'utilisateur clique sur le champ de recherche de la page d'accueil, il dispose déjà des paramètres nécessaires à la requête réseau. Ensuite, vous pouvez lancer une requête réseau à l'avance en cliquant sur. La requête réseau et le saut de page seront effectués simultanément, ce qui raccourcit le temps de requête réseau. Si les performances de la machine sont moins bonnes, plus il faut de temps pour que la page clique sur la méthode onCreate et plus il faut de temps pour l'optimiser. Le temps de vérification sur les machines bas de gamme est réduit d'environ 200 ms.
Publié par lots
Lorsque l'utilisateur entre dans la page, seules les données du premier écran seront affichées, tandis que les données au bas de la page ne peuvent pas être affichées tant que l'utilisateur n'a pas effectué une opération de glissement. Par conséquent, nous accordons la priorité à assurer l'affichage des données du premier écran. En réduisant la taille de la première livraison de données, nous réduisons le temps nécessaire à l'acquisition, à la transmission et à l'analyse des données. Une fois le rendu des données du premier écran terminé, nous lancerons à nouveau une demande d'interface pour garantir que les données suivantes puissent être présentées immédiatement lorsque l'utilisateur effectue une opération de glissement. Cette solution est utilisée pour l'optimisation de nombreuses pages clés telles que la page d'accueil, la page de demi-lecture et la recherche. Par exemple, lors de l'utilisation de cette solution dans le scénario de recherche, le temps de vérification est réduit d'environ 200 ms.
pré-créé
Pré-création de la mise en page : lorsque la page intermédiaire de recherche est inactive, nous créons à l'avance des mises en page hautement réutilisables dans le cache. Lorsque la page est réellement rendue, la mise en page pré-créée est directement utilisée pour éviter le temps de gonflement de la vue.
Pré-création de fragment : lorsque la page intermédiaire de recherche est inactive, le conteneur de fragments de la page de résultats est créé à l'avance. Il n'est pas nécessaire de créer le conteneur correspondant lorsque la page de résultats est affichée, ce qui réduit le temps nécessaire à la création du conteneur.
Optimisation du fil principal
Lorsque la page est chargée, on espère que les tâches du fil principal liées à la page seront exécutées en premier autant que possible. Si la planification des tâches importantes est anticipée, l'effet de rendu de la page sera affecté. Grâce à notre outil Tracepeed interne auto-développé, qui reprend Looper.loop() du thread principal, nous pouvons découvrir les tâches chronophages dans le thread principal. Si vous constatez que les tâches peu prioritaires qui prennent beaucoup de temps sont exécutées en premier, vous pouvez ajuster le calendrier des tâches afin que les tâches importantes soient exécutées en premier.
Par exemple, lors du processus de chargement de la page de résultats de recherche, le chargement des images est une tâche importante. Cependant, sur les machines bas de gamme, on constate que dans certains cas une autre tâche préemptera le thread principal, ce qui fait que le temps de chargement de l'image peut parfois prendre jusqu'à 1 seconde. Pour ce scénario, ajustez la planification des tâches afin que la tâche de chargement d'image soit exécutée en premier et que la consommation de temps se stabilise à plus de 100 ms.
Optimisation de la logique métier
Pour différentes entreprises, nous avons également analysé la logique métier spécifique et optimisé la logique pertinente :
-
Optimisation des images vides : Lorsque la sélection est chargée, dans certains scénarios, le backend délivrera une image vide, et cette image vide sera également chargée, ce qui augmentera le temps de chargement de la page. Par conséquent, nous limitons le chargement des images vides.
-
Optimisation logique haute fréquence : lors de l'optimisation, les méthodes haute fréquence sont un point sur lequel il faut se concentrer. En optimisant certaines méthodes haute fréquence couramment utilisées, la consommation de temps de chaque page peut être optimisée. Par exemple : lors de l'initialisation des contrôles de base, cela évite l'exécution de méthodes inutiles et réduit le temps nécessaire à ces méthodes à haute fréquence.
-
Exécution asynchrone de méthodes chronophages : pendant le processus de chargement de la page, il y aura également une logique métier avec une faible priorité. Lorsque ces logiques sont découvertes, elles peuvent être exécutées via le framework asynchrone, réduisant ainsi le temps de chargement de la page.
Anti-détérioration
Après une optimisation continue, le temps de chargement des pages a atteint un niveau stable. Cependant, au cours des itérations de développement en cours, nous avons remarqué une certaine augmentation de la consommation de temps. Comment prévenir efficacement ce type de détérioration ?
En intégrant des méthodes clés dans le code, les tâches du pipeline sont exécutées régulièrement chaque jour et la valeur moyenne est calculée après plusieurs exécutions. Utilisez des méthodes visuelles pour détecter les fluctuations du chargement des pages. En cas de détérioration, vous pouvez intuitivement trouver la différence de temps entre les deux tâches grâce à la comparaison des tâches, puis analyser et optimiser la différence de temps.
Résumé et perspectives
L'optimisation des machines bas de gamme comprend de nombreux aspects. Certaines des méthodes d'optimisation présentées ci-dessus dans plusieurs scénarios commerciaux de base donnent la priorité aux problèmes de performances clés et améliorent efficacement les performances de fonctionnement des machines bas de gamme. Parmi elles, l'analyse des outils, la surveillance en ligne et les normes de mesure. requis. Non mentionnés ici, ce sont également des outils importants pour l’optimisation des performances. Android est sérieusement fragmenté et il reste un long chemin à parcourir pour optimiser les téléphones bas de gamme. À l'avenir, nous continuerons à affiner et à trouver de nouveaux points de rupture pour l'optimisation, à utiliser l'innovation technologique pour offrir aux utilisateurs une expérience utilisateur stable et fluide et à promouvoir une croissance de haute qualité.
Cet article est partagé à partir du compte public WeChat - Équipe produit technologique iQIYI (iQIYI-TP).
En cas d'infraction, veuillez contacter [email protected] pour suppression.
Cet article participe au « Plan de création de sources OSC ». Vous qui lisez, êtes invités à vous joindre et à partager ensemble.
