Processus d'exécution du framework ThinkPHP (avec carte cérébrale)
咔咔
Libérer： 2020-11-06 16:21:33
original
5230 Les gens l'ont consulté
"
Cet article présente principalement le processus d'exécution du framework
"
Avant-propos
Si vous ne savez pas comment le framework est exécuté, alors la majeure partie du code consiste simplement à comprendre le code. Lire le code source consiste à apprendre les idées de conception. et les modèles de code du framework.
Le processus d'exécution consiste à relier les choses que nous apprenons ensemble pour mieux comprendre. Kaka dessinera également pour vous le processus d'exécution sous la forme d'une carte mentale.
Tant que tout le monde apprendra un peu de connaissances grâce à cet article, Kaka sera satisfait.
Cet organigramme concerne uniquement le processus d'exécution d'initialisation. Le reste du processus d'exécution sera complété ultérieurement et sera présenté à chacun sous forme de cartes mentales.
Organigramme d'exécution
1. Paramètres de données pour l'application d'initialisation du processus d'exécution du framework.
Le contenu ici est un peu répétitif avec le contenu du conteneur, car le processus d'exécution commence à partir du fichier d'entrée et est finalement exécuté via le conteneur.
Le fichier d'entrée
entrera alors la méthode d'exécution du fichier thinkphp/library/think/App.php Dans cette méthode, la méthode d'initialisation est exécutée principalement à l'endroit indiqué dans le cadre ci-dessous.
En ce qui concerne la méthode d'initialisation, regardons d'abord la première moitié.
microtime(true);Renvoie le nombre de microsecondes sous Unix
memory_get_usageRenvoie la quantité de mémoire allouée à PHP en unités d'octets
L'étape suivante consiste à définir plusieurs chemins du framework
static::setInstance($this);Voici comment définir l'instance d'application en tant que conteneur Exemple
$this->instance('app', $this); Cela a été mentionné dans le chapitre sur le conteneur auparavant, afin de lier la classe d'application au conteneur, qui est le mode arbre d'enregistrement.
Voici un petit problème pour tout le monde. Il existe dans cette méthode d'initialisation de l'application. ligne de code.
Quelqu'un a-t-il des doutes à propos de cet $this->env et des $this->config appels suivants ?
Si vous avez des doutes, suivez simplement Kaka et lisez-le. Si vous n'avez aucun doute, vous pouvez continuer à lire.
La classe App est une classe conteneur héritée, donc env et config n'ont pas ces deux attributs ni dans l'application ni dans la classe conteneur.
Alors comment peut-on l'appeler directement ? Et le suivi du code sera retracé jusqu'à la classe env et la classe conteneur.
Pour connaître la source, nous devons jeter un coup d'œil au code de la classe conteneur.
Résoudre les doutes, pourquoi il peut être utilisé de cette manière
Après une lecture difficile, vous pouvez voir quelques lignes de code dans l'image ci-dessous. Ces lignes de code utilisent toutes des méthodes magiques.
Lorsque la classe env accédée n'existe pas, la méthode make sera exécutée.
La méthode make est si détaillée dans le chapitre sur les conteneurs qu'elle ne peut pas être expliquée en détail.
Cette méthode make renverra éventuellement une instance de la classe et la stockera dans le conteneur.
Mettez ici uniquement le code d'une méthode make. Si vous ne savez pas comment faire, vous pouvez lire l'article précédent.
La dernière étape consiste à charger une série de données. Veuillez consulter la carte mentale dans la préface pour les détails du chargement.
Exécuter le chargement
2. Comment vérifier où une méthode est exécutée
Dans le processus de lecture du code source, un problème difficile à contrôler est qu'une méthode est appelée à différents endroits, mais on ne la connaît pas du tout pendant un moment . Où s'appelle-t-il.
Voici une démonstration utilisant la méthode init.
La méthode init est une méthode pour initialiser une application ou un module, mais le paramètre module ici a une valeur nulle.
Créez d'abord un point d'arrêt pour vérifier les informations de données pertinentes.
Le résultat imprimé est vide. C'est une erreur que feront certains nouveaux partenaires d'apprentissage, car cette méthode ne peut pas être appelée une seule fois.
Si les modules d'initialisation sont tous vides, alors cette méthode n'a pas besoin d'exister.
Alors la méthode de point d'arrêt correcte devrait être comme ceci.
Il y aura un problème à ce moment-là. Cette méthode init est évidemment appelée deux fois, alors où est l'autre appel !
Si vous ne connaissez pas la nouvelle technique, vous imprimerez une série de points d'arrêt pour voir où l'exécution est effectuée, comme l'impression au niveau supérieur de l'initialisation.
C'est-à-dire imprimer des points d'arrêt dans la méthode d'initialisation, mais cela est très gênant, et cela risque de perdre beaucoup de temps et de ne toujours pas trouver le bon endroit.
Conseils : debug_backtrace()
Cette méthode générera une trace arrière, qui affichera tous les emplacements d'appel d'une méthode.
L'utilisation est celle indiquée ci-dessous. Il vous suffit d'imprimer la méthode debug_backtrace.
Sur la base des informations obtenues sur les données, le positionnement peut être effectué très rapidement.
La première fois, c'est sur la ligne 215 de la classe app.
La première fois que init est appelé
La deuxième fois est à la ligne 60 de la thinkphp/library/think/route/dispatch/Module.phpclasse
Le deuxième lieu d'appel
Vous pouvez faire une impression ici pour voir si ce module est index
Nous avons donc cette méthode pour localiser le lieu d'appel très rapidement.
3. Analyse initiale de l'application d'initialisation du processus d'exécution du framework
Ce qui précède vous fournit une petite astucedebug_backtraceUne démonstration pratique de la façon de vérifier où une méthode est exécutée.
Et le cas utilise également la méthode init pour démontrer, car la prochaine étape consiste à avoir une compréhension approfondie de la méthode init.
Les principales choses effectuées dans la méthode init ont été clairement décrites dans la carte mentale ci-dessus.
Le positionnement du module depuis le début est l'appel à la méthode init dans la deuxième section, qui passera dans le module correspondant
à charger Le fichier de balises dans le répertoire de l'application contient des fichiers qui définissent des comportements étendus. L'exécution du hook définie dans l'article de façade précédent est définie dans ce fichier.
Chargez les fichiers communs, qui sont des fichiers publics, donc les fichiers publics sont chargés ici.
Charger le fichier de fonction d'assistance helper Il existe une méthode que tout le monde connaît très bien dans la fonction d'assistance, à savoir le dump. C'est pourquoi une erreur sera signalée lors de l'utilisation du dump à certains endroits.
Charger le fichier middleware. Ce qui est donné ici est de charger directement le fichier middleware dans le répertoire de l'application, mais dans le framework nous devons définir un répertoire comme http Dans ce répertoire Définir. le fichier middleware ci-dessous.
Enregistrez l'instance d'objet conteneur du service. L'enregistrement ici utilise la méthode bindTo dans la classe conteneur pour l'enregistrement de liaison.
Lire le fichier de configuration. Cela a été expliqué en profondeur dans la section sur le chargement du fichier de configuration et ne sera pas mentionné ici. Le fichier de configuration sera lu à deux endroits : l'un est le fichier de configuration sous le module de première étape et l'autre est le fichier de configuration sous le répertoire de configuration.
Définissez le chemin du module, et le module obtenu dans la première étape sera configuré envConfiguration des variables d'environnement
La dernière étape est pour configurer le conteneur L'instance d'objet dans la configuration est mise à jour. Les mises à jour spécifiques seront expliquées en détail plus tard.
Une copie du code précédent est jointe ici. Vous pouvez consulter le code pour voir le flux d'exécution, et chaque étape est brièvement expliquée.
L'avis personnel de Kaka optimise le code source
Kaka ne se sent pas très rigoureux dans l'étape de mise en place du module, car la méthode init sera réalisée en deux lieux mettre en œuvre.
La première fois que le module est vide, cela n'a aucun sens d'exécuter ce code.
Ce qui suit est un jugement lors de la mise à jour de la configuration de l'instance d'objet du conteneur pour déterminer si ce paramètre du module est vide. S'il n'est pas vide, il sera exécuté.
Pour la même raison, KaKa estime que la définition du chemin du module devrait également être incluse dans ce jugement.
Bien que la deuxième exécution écrasera le premier résultat, Kaka pense qu'il serait préférable de l'utiliser comme l'image ci-dessous.
Suggestions de Kaka pour les modifications du code source
4. Instances d'objets dans les conteneurs Mettre à jour le configuration
Ceci est le contenu final de la section précédente Ainsi, lors de la mise à jour de la configuration de l'instance, il n'y a aucune explication sur ce qui est mis à jour et comment le mettre à jour.
Des explications seront faites dans cette section, qui peut également être lue avec la carte mentale en préface.
Tout d'abord, toutes les informations de configuration dans le répertoire de configuration seront obtenues
La classe de gestion des exceptions sera enregistrée à partir du fichier de configuration de l'application
Le troisième bloc consiste à enregistrer et configurer toutes les informations de configuration obtenues lors de la première étape dans la classe correspondante.
La quatrième étape consiste à charger le pack de langue correspondant après avoir déterminé le module. La fonction du pack de langue peut réaliser des fonctions multilingues. Kaka a écrit un article avant de réaliser des fonctions multilingues. . , si vous êtes intéressé, vous pouvez le consulter.
La dernière étape consiste à mettre en cache selon les trois attributs du fichier de configuration de l'application
Dans cette section, la sensation de clic est la plus important Le contenu est tel qu'indiqué dans l'image ci-dessous.
On peut tracer une ou deux méthodes à volonté pour voir quelles méthodes y sont exécutées.
Méthode de suivi Db::init()
Après avoir suivi la méthode, vous pouvez voir qu'elle attribue la valeur à l'attribut config dans la classe Db et attribue le valeur dans la base de données Donnez l'attribut config dans la classe Db.
Méthode de suivi $this->middleware->setConfig()
Quand vous arrivez à la classe middleware, vous pouvez voir que cette classe la configuration est fusionnée avec la classe de paramètres transmise et la valeur de l'attribut config est également attribuée.
L'effet obtenu par la méthode init de la classe Db dans le cas ci-dessus est cohérent.
Ce que je tiens à mentionner ici, c'est que 对容器中的对象实例进行更新配置Sur cette photo, vous pouvez voir que la partie violette n'est pas référencée dans cette classe.
Alors, comment cela peut-il être exécuté ! C'est parce que la classe App hérite de la classe conteneur. Il existe quatre méthodes magiques dans la classe conteneur, dont la méthode __get, qui est la méthode qui sera exécutée lors de l'obtention d'attributs inexistants.
Une méthode make est exécutée dans la méthode magique __get. Cette méthode make a été mentionnée à plusieurs reprises. Cette méthode renverra éventuellement une instance de l'application, puis utilisera cette instance pour appeler la méthode correspondante. classe d'instance.
Cela doit être bien compris. La lecture du code source est comme ça. Ce n'est qu'ainsi que nous pourrons améliorer nos capacités de programmation et de réflexion.
Paramètres et configuration du middleware
5. Brève discussion sur le mode débogage Et la redondance du code
Cette section donnera une brève explication du mode de débogage et soulèvera brièvement la redondance du code-cadre.
Aucun code écrit par qui que ce soit n'est sans failles. S'il y en a, alors vous n'avez pas atteint un certain niveau de réussite.
Mode débogage
Seule la première moitié de la méthode d'initialisation est mentionnée dans la première section, car avant cette section, tout le discours portait sur le contenu d'initialisation de l'application.
Le contenu de cette section sera brièvement expliqué ensuite.
Récupérez l'élément de configuration app_debug à partir du fichier de configuration de l'application
Définissez le niveau de débogage sur la variable d'environnement
Lorsque le débogage dans le framework est désactivé, la méthode ini_set sera exécutée. Cette méthode consiste à attribuer une valeur à une option de configuration.
Le contenu suivant n'est probablement pas très facile à comprendre, car il n'est pas du tout utilisé au travail.
ob_get_level : renvoie le niveau d'imbrication du mécanisme de mise en mémoire tampon de sortie, alors comment le comprendre ! En fait, il renverra 0 lorsque la zone tampon est inactive.
ob_get_clean : Cette fonction renverra le contenu du tampon de sortie et terminera le tampon de sortie. Renvoie false si le tampon n'a pas de contenu valide. Essentiellement, cela équivaut à exécuter ob_getcontens() et ob_end_clean() en même temps.
ob_start : Activez le tampon de contrôle de sortie
Il suffit de connaître les trois ci-dessus pour l'instant. J'écrirai un article expliqué plus tard.
À propos de la redondance du code-cadre
Cela ne représente que l'opinion personnelle de Kaka.
Vous pouvez d'abord jeter un œil à cette partie du code. Ces deux codes sont-ils très familiers Oui, vous l'avez vu dans la mise à jour de la configuration de l'instance d'objet conteneur dans la méthode init ci-dessus ?
Comme le montre l'image
Ceci est l'opinion personnelle de Kaka En raison de l'interprétation du code source de Kaka pour la 5.1, je ne sais pas si la nouvelle version a réussi. . changé.
6. Résumé
Cette section traite principalement de l'application d'initialisation dans le processus d'exécution du framework.
En ce qui concerne les nombreux processus d'exécution sous la méthode run de la classe app, il n'y a pas beaucoup d'explications dans cette section.
En train de lire le code source, je vous ai donné un bon conseil, c'est-à-dire comment vérifier où une méthode est exécutée.
Cette méthode est debug_backtrace. Cette méthode nécessite de l'utiliser plusieurs fois avant de savoir comment l'utiliser, car il y a aussi beaucoup d'informations inutiles dans les résultats imprimés.
Cette méthode est très efficace dans le processus de débogage du code source. Assurez-vous de faire bon usage de cette méthode.
Voici maintenant une introduction particulièrement détaillée à la méthode init d'initialisation de l'application.
Parmi eux, Kaka estime que la meilleure partie de cette conception est celle où l'instance d'objet dans le conteneur est mise à jour et configurée. Tout d'abord, toutes les configurations sont lues, puis la configuration est définie via les méthodes de chaque classe. .
Ce type d'idées de planification et de conception de code mérite d'être appris.
Enfin, nous avons parlé du problème de redondance du code du mode de débogage et du framework Concernant le mode de débogage, je voudrais rappeler à tous que le mode de débogage du projet en ligne doit être désactivé.
Sinon, votre projet sera comme courir nu sans aucune sécurité.
Ce qui est un peu difficile à comprendre, c'est la zone tampon. Kaka estime qu'il n'est pas nécessaire d'approfondir les détails de ce contenu pour le moment. Nous devrions d'abord le comprendre, puis mener des recherches approfondies. .
On estime que ce contenu dans la zone tampon est rarement utilisé par les personnes qui travaillent depuis trois ou quatre ans, alors apprenez d'abord à le connaître et sachez de quoi il s'agit. Après que Kaka l'ait appris plus tard, je l'ai appris plus tard. le complétera pour tout le monde.
Jusqu'à présent, l'application initiale du processus d'exécution du framework est terminée. Il n'y a pas grand chose à apprendre dans cette section, principalement les modèles de conception de code et les idées d'implémentation.
Pour cette dernière photo, vous devez suivre le code source et jeter un oeil !
Insérer la description de l'image ici
«
Continuez à apprendre, continuez à bloguer, continuez à partager, c'est la conviction à laquelle Kaka a toujours adhéré dans l'immense Internet, je suis Kaka, à bientôt dans le prochain numéro
.
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!
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
 "160463360950264Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
 "160463362378649Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
 "160463363545271Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
 "160463364488738Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
 "160463365180548Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
 "160463365835328Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
 "160463366569914Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
 "160463367499130Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
 "160463368125877Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
Créez d'abord un point d'arrêt pour vérifier les informations de données pertinentes.  "160463368736194Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
 "160463369340337Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
Alors la méthode de point d'arrêt correcte devrait être comme ceci.  "160463369891327Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
 "160463370389435Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
Il y aura un problème à ce moment-là. Cette méthode init est évidemment appelée deux fois, alors où est l'autre appel !  "160463370961455Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
 "160463371695791Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
 "160463372283736Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
 "160463377084257Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
 "160463378245754Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
 "160463378929845Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
 "160463379412934Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
Nous avons donc cette méthode pour localiser le lieu d'appel très rapidement.  "160463383327404Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
 "160463383927154Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
On peut tracer une ou deux méthodes à volonté pour voir quelles méthodes y sont exécutées.  "160463384556578Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
 "160463386635330Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
 "160463387240689Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
 "160463387847376Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
Comme le montre l'image "160463388323117Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
Ceci est l'opinion personnelle de Kaka En raison de l'interprétation du code source de Kaka pour la 5.1, je ne sais pas si la nouvelle version a réussi. . changé.  "160463389788297Processus dexécution du framework ThinkPHP (avec carte cérébrale)")
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
