Une brève analyse du mécanisme de fonctionnement des mini-programmes

Contexte de l'écriture

Je suis exposé aux mini-programmes depuis un certain temps. De manière générale, le seuil pour le développement de mini-programmes est relativement bas, mais vous devez toujours comprendre le fonctionnement de base. mécanismes et principes. "Par exemple, on m'a posé une question sur un mini-programme lors de l'entretien. Le mini-programme a-t-il un objet fenêtre ? Il a dit oui", mais en fait ce n'est pas le cas. On a l'impression qu'il ne comprend pas certaines des choses sous-jacentes au mini-programme. En dernière analyse, il ne peut utiliser que cet outil, mais il n'en comprend pas la raison.

Les mini-programmes sont très différents du développement web ordinaire. Cela doit être analysé du fond de son architecture technique. Par exemple, les développeurs habitués au développement de Vue et React se plaindront de la lourdeur de la création d'une nouvelle page pour un mini-programme. La page doit être composée de plusieurs fichiers, la prise en charge des composants est incomplète et chaque fois que les données sont dans les données. modifié, setData doit être défini. Ce n'est pas aussi pratique que les moniteurs Vue Watch et ne peut pas faire fonctionner Dom, ce qui n'est pas bon pour les scénarios complexes. Il ne prenait pas en charge npm, sass et les langages de traitement moins précompilés auparavant.

"Certaines personnes disent que les mini-programmes sont comme Vue castré", haha. Bien sûr, leurs points de départ pour la conception sont différents. Nous devons également comprendre l'intention initiale de la conception des mini-programmes. Pourquoi cette architecture technique est-elle adoptée et quels sont les avantages de cette architecture technique ? Je pense que vous la comprendrez après avoir compris cela ? Ensuite, j'analyserai le mécanisme de fonctionnement du mini programme et son architecture technique globale dans les perspectives suivantes.

Comprendre l'origine des mini-programmes

Avant la sortie des mini-programmes, WeChat WebView est progressivement devenu une entrée importante vers le Web mobile. WeChat a publié un ensemble complet de développement Web. Boîtes à outils Appelé JS-SDK, il ouvre une nouvelle fenêtre pour tous les développeurs Web, permettant à tous les développeurs d'utiliser les capacités natives de WeChat pour accomplir des choses qui étaient auparavant impossibles ou difficiles à faire.

Cependant, le modèle JS-SDK ne résout pas les problèmes de mauvaise expérience lors de l'utilisation de pages Web mobiles, comme la possibilité d'un écran blanc en raison des performances limitées de l'appareil et de la vitesse du réseau. Par conséquent, une version améliorée de JS-SDK a été conçue, qui est "WeChat Web Resource Offline Storage", mais le problème de l'écran blanc se produit toujours sur les pages complexes, en raison de la rigidité du changement de page et du décalage des clics. À l'heure actuelle, un système qui ne peut pas être géré par JS-SDK est nécessaire pour améliorer l'expérience utilisateur, et de petits programmes ont vu le jour.

Chargement rapide

Capacités plus puissantes

Expérience native

Ouverture des données WeChat facile à utiliser et sécurisée

Efficace et simple développement

La différence entre les petits programmes et le développement de pages Web ordinaires

Par rapport au développement de pages Web ordinaires, le développement de petits programmes est très similaire. Le principal langage de développement est également JavaScript. , mais il existe encore quelques différences entre les deux.

Le développement Web ordinaire peut utiliser l'API DOM fournie par divers navigateurs pour effectuer des opérations DOM. La couche logique et la couche de rendu de l'applet sont séparées. La couche logique s'exécute dans JSCore et n'a pas d'objet de navigateur complet. , manquant ainsi de l'API DOM et de l'API BOM associées.

Les threads de rendu de développement Web ordinaires et les threads de script s'excluent mutuellement, c'est pourquoi l'exécution d'un script à long terme peut entraîner une perte de réponse de la page. Dans les petits programmes, les deux sont séparés et exécutés différemment dans le thread.

Lorsque les développeurs Web développent des pages Web, ils n'ont besoin que d'utiliser un navigateur et d'utiliser des outils ou éditeurs auxiliaires. Le développement de mini-programmes est différent. Il doit passer par le processus de demande d'un compte de mini-programme, d'installation d'outils de développement de mini-programmes, de configuration de projets, etc.

Environnement d'exécution du mini programme

Architecture du mini programme

Sélection de la technologie

Général Généralement. En parlant, il existe trois technologies pour le rendu des interfaces :

Rendu à l'aide de la technologie native côté client pur

Rendu à l'aide de la technologie Web pure

Utilisation de la technologie native côté client et de la technologie Web Technologie hybride combinée (Hybrid technology en abrégé) pour le rendu

À travers l'analyse des aspects suivants, quelle solution technique est utilisée pour le mini programme

Seuil de développement : le seuil Web est bas, Native a aussi quelque chose comme la prise en charge de RN Framework

Expérience : l'expérience native est bien meilleure que le Web, l'hybride est plus proche de l'expérience native que du Web dans une certaine mesure

Mise à jour de la version : le Web prend en charge les mises à jour en ligne, le natif doit être emballé dans WeChat pour examen Release

Contrôle et sécurité : le Web peut sauter ou modifier le contenu de la page, et il existe des facteurs incontrôlables et des risques de sécurité

Étant donné que l'environnement hôte du mini-programme est WeChat , si vous utilisez un client natif pur. Si vous utilisez la technologie pour écrire des mini-programmes, le code du mini-programme doit être publié à chaque fois avec le code WeChat. Cette méthode n'est certainement pas réalisable.

Il est donc nécessaire de disposer d'un package de ressources pouvant être mis à jour à tout moment dans le cloud comme la technologie web. En le téléchargeant en local, l'interface peut être rendue après exécution dynamique. Si vous utilisez une technologie Web pure pour restituer de petits programmes, vous risquez de rencontrer des problèmes de performances dans certaines interactions complexes. En effet, dans la technologie Web, le rendu de l'interface utilisateur et l'exécution du script JavaScript sont exécutés dans un seul thread, ce qui peut facilement conduire à certaines tâches logiques. saisir les ressources de rendu de l'interface utilisateur.

Nous avons donc finalement utilisé la technologie hybride qui combine les deux pour rendre le petit programme. Il peut être développé d'une manière similaire au Web, et le code peut être mis à jour en même temps, en introduisant également des composants. présente les avantages suivants :

Étendez les capacités du Web. Par exemple, les composants de la zone de saisie (entrée, zone de texte) ont la capacité de mieux contrôler le clavier

L'expérience est meilleure et cela réduit également le travail de rendu de WebView

Contournement de setData, communication de données et processus de re-rendu pour améliorer les performances de rendu

L'utilisation du rendu natif côté client pour intégrer certains composants complexes peut offrir de meilleures performances

Modèle à double thread.

La couche de rendu et la couche logique du mini programme sont gérées respectivement par deux threads : l'interface de la couche de vue utilise WebView pour le rendu et la couche logique utilise les threads JsCore pour exécuter des scripts JS.

Alors pourquoi est-il conçu ainsi ? Le contrôle et la sécurité ont également été mentionnés plus tôt. Afin de résoudre ces problèmes, nous devons empêcher les développeurs d'en utiliser certains, comme l'objet fenêtre du navigateur, le saut de page ou l'exploitation du DOM. et exécution dynamique. Interface ouverte pour les scripts.

On peut utiliser le moteur JavaScript du système client, le framework JavaScriptCore sous iOS, et l'environnement JsCore fourni par le noyau Tencent x5 sous Android.

Cet environnement sandbox fournit uniquement un environnement d'interprétation et d'exécution JavaScript pur, sans aucune interface liée au navigateur.

C'est l'origine du modèle double thread du mini programme :

Couche logique : Créez un thread séparé pour exécuter JavaScript. Tout le code lié à la logique métier du mini programme est. exécuté ici, responsable du traitement logique, des demandes de données, des appels d'interface, etc.

Couche d'affichage : toutes les tâches liées au rendu de l'interface sont exécutées dans le thread WebView, et les interfaces rendues sont contrôlées via la couche logique code. Un petit programme a plusieurs interfaces, il y a donc plusieurs threads WebView dans la couche d'affichage

JSBridge sert de pont entre le développement de niveau supérieur et Native (couche système), permettant au petit programme d'utiliser des fonctions natives via le API et certains composants sont implémentés en tant que composants natifs, vous avez donc une bonne expérience

3. Communication à double thread

Mettez le code logique JS du développeur dans un espace séparé. thread à exécuter, mais dans le thread Webview, les développeurs ne peuvent pas manipuler directement le DOM.

Comment changer dynamiquement l'interface ?

Comme le montre la figure ci-dessus, la communication entre la couche logique et la couche vue sera relayée par Native (client WeChat), et les requêtes réseau envoyées par la couche logique seront également transmises par Native.

Cela signifie que nous pouvons mettre à jour le DOM via une simple communication de données.

DOM virtuel Je crois que tout le monde le sait déjà, c'est probablement ce processus : Utiliser des objets JS pour simuler l'arborescence DOM -> Comparez les différences entre les deux arborescences DOM virtuelles -> Arbre DOM.

Comme le montre la figure :

Convertissez WXML en l'objet JS correspondant dans la couche de rendu.

Lorsque des modifications de données se produisent dans la couche logique, les données sont transférées de la couche logique vers Native via la méthode setData fournie par l'environnement hôte, puis transmises à la couche de rendu.

Après avoir comparé les différences avant et après, appliquez les différences à l'arborescence DOM d'origine et mettez à jour l'interface.

Nous réalisons l'interaction et la communication entre la couche logique et la couche de rendu en convertissant WXML en données et en les transmettant via Native.

Un framework aussi complet ne peut être séparé de la bibliothèque de base du mini programme.

4. La bibliothèque de base du mini programme

La bibliothèque de base du mini programme peut être injectée dans la couche de vue et la couche logique pour le fonctionnement, et est principalement utilisé dans les aspects suivants :

Dans la couche vue, divers composants sont fournis pour former les éléments de l'interface

Dans la couche logique, diverses API sont fournies pour gérer diverses logiques

Traitement des systèmes de liaison de données et de composants, du système d'événements, du système de communication et d'une série de logiques de cadre

Puisque la couche de rendu et la couche logique de l'applet sont gérées par deux threads, les deux threads sont chacun injectés dans la bibliothèque de base.

La bibliothèque de base du mini programme ne sera pas empaquetée dans le package de code d'un certain mini programme, elle sera intégrée au client WeChat à l'avance.

Cela peut :

Réduire la taille du package de code de l'applet métier

Vous pouvez corriger les bugs de la bibliothèque de base indépendamment sans modifier le package de code de l'applet métier

5. Exparser Framework

Exparser est le cadre d'organisation des composants du mini programme WeChat. Il est intégré à la bibliothèque de base du mini programme et fournit une prise en charge de base pour divers composants de. le mini programme. Tous les composants du mini-programme, y compris les composants intégrés et les composants personnalisés, sont organisés et gérés par Exparser.

Les principales fonctionnalités d'Exparser sont les suivantes :

Basé sur le modèle Shadow DOM : le modèle est très similaire au ShadowDOM de WebComponents, mais ne s'appuie pas sur le support natif du navigateur. Il n'y a pas d'autres bibliothèques dépendantes lors de la mise en œuvre, d'autres API ont été spécifiquement ajoutées pour prendre en charge la programmation de petits composants de programme.

peut fonctionner dans un environnement JS pur : cela signifie que la couche logique possède également certaines capacités d'organisation de l'arborescence des composants.

Efficace et léger : les performances sont bonnes, en particulier dans les environnements avec un grand nombre d'instances de composants, et la taille du code est également petite.

Dans l'applet, toutes les opérations liées à l'arborescence des nœuds reposent sur Exparser, y compris WXML pour la construction de l'arborescence des nœuds finale de la page, les appels createSelectorQuery et les fonctionnalités des composants personnalisés, etc.

Composants intégrés

Basé sur le framework Exparser, le mini programme dispose d'un ensemble de composants intégrés qui fournissent des classes de conteneurs de vue, des classes de formulaire et des classes de navigation. , classes multimédias, classes ouvertes, etc. Des dizaines de composants. Avec un ensemble de composants aussi riche, associé à WXSS, vous pouvez créer une interface avec n'importe quel effet. Au niveau fonctionnel, il répond également à la plupart des besoins.

6. Mécanisme de fonctionnement

Il existe deux situations lorsque le mini-programme est démarré, l'une est un "démarrage à froid" et l'autre est un "démarrage à chaud". Si l'utilisateur a déjà ouvert un petit programme et l'ouvre à nouveau dans un certain laps de temps, il n'est pas nécessaire de redémarrer à ce moment-là. Il suffit de faire passer le petit programme en arrière-plan au premier plan. un démarrage à froid fait référence à l'utilisateur. Lorsque le mini-programme est ouvert pour la première fois ou rouvert après avoir été activement détruit par WeChat, le mini-programme doit être rechargé et démarré.

Le mini programme n'a aucune notion de redémarrage

Lorsque le mini programme entre en arrière-plan, le client maintiendra un état d'exécution pendant un certain temps. période de temps (actuellement 5 minutes) Sera activement détruit par WeChat

Lorsque plus de deux alarmes de mémoire système sont reçues dans un court laps de temps (5 secondes), le mini programme sera détruit

7. Mécanisme de mise à jour

Si une nouvelle version du mini programme est trouvée lors du démarrage à froid, la nouvelle version du package de code sera téléchargée de manière asynchrone et démarrée avec le package local de le client en même temps, c'est-à-dire que la nouvelle version du mini-programme doit attendre la prochaine fois. Elle ne sera appliquée qu'après un démarrage à froid. Si vous devez appliquer la dernière version immédiatement, vous pouvez utiliser l'API wx.getUpdateManager pour la gérer.

8. Optimisation des performances

Les principales stratégies d'optimisation peuvent être résumées en trois points :

Rationaliser le code et réduire la complexité de la structure WXML et Code JS ;

Utiliser raisonnablement les appels setData pour réduire le nombre de setData et la quantité de données

Utiliser l'optimisation de la sous-traitance lorsque nécessaire.

1. Comment fonctionne setData

La couche d'affichage de l'applet utilise actuellement WebView comme support de rendu, tandis que la couche logique utilise JavascriptCore indépendant comme environnement d'exécution. Sur le plan architectural, WebView et JavascriptCore sont des modules indépendants et ne disposent pas de canaux pour le partage direct de données. Actuellement, la transmission de données entre la couche de visualisation et la couche logique est en fait implémentée via le évaluerJavascript fourni par les deux parties. Autrement dit, les données transmises par l'utilisateur doivent être converties en chaîne et transmises. En même temps, le contenu des données converties est fusionné dans un script JS, puis transmis aux environnements indépendants des deux côtés en s'exécutant. le script JS.

L'exécution d'evaluJavascript sera affectée par de nombreux aspects, et les données arrivant à la couche de vue ne sont pas en temps réel.

2. Erreurs courantes d'opération setData

setData fréquentes Dans certains cas que nous avons analysés, certains petits programmes setData très fréquemment (en millisecondes) setData, ce qui entraîne deux conséquences. : les utilisateurs sous Android se sentiront bloqués lors du glissement et le retour d'opération sera sérieusement retardé. Parce que le thread JS a été compilé et rendu, il ne parvient pas à transmettre les événements d'opération de l'utilisateur à la couche logique à temps, et la couche logique également les résultats du traitement des opérations. ne peut pas être transmis à la couche de vue à temps ; il y a un retard dans le rendu. Étant donné que le thread JS de WebView est toujours occupé, le temps de communication de la couche logique à la couche de page augmente et le message de données reçu par la couche de vue est. retardé à partir du moment où il est envoyé. Des centaines de millisecondes se sont écoulées et les résultats du rendu ne sont pas en temps réel

Chaque setData transfère une grande quantité de nouvelles données. De l'implémentation sous-jacente de setData, nous savons que. notre transmission de données est en fait un processus de script évalueJavascript

, lorsque la quantité de données est trop importante, cela augmentera le temps de compilation et d'exécution du script, occupera le thread WebView JS et exécutera setData en arrière-plan Lorsque la page entre dans l'état d'arrière-plan (invisible pour l'utilisateur), setData ne doit pas continuer à restituer la page d'état d'arrière-plan à l'utilisateur. De plus, settingsData sur la page d'arrière-plan préemptera également l'exécution du premier plan. page.

Résumé

L'architecture sous-jacente du mini programme est grossièrement analysée à partir des perspectives ci-dessus, de l'origine du mini programme à l'émergence des doubles threads, de la conception, la communication et les bases Les bibliothèques, le framework Exparser, le mécanisme d'exécution, l'optimisation des performances, etc. sont tous des choix liés et s'affectant mutuellement. Il devrait y avoir beaucoup plus de détails sur la conception du framework sous-jacent aux petits programmes. La naissance de chaque framework a sa propre signification. En tant que développeurs, ce que nous pouvons faire, c'est non seulement utiliser cet outil, mais aussi comprendre ses modèles de conception. Ce n’est qu’ainsi que vous pourrez ne pas vous laisser influencer par les outils et aller plus loin !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!