初步了解一下Laravel中的生命周期

下面由laravel教程欄目帶大家初步了解一下laravel中的生命周期,希望對需要的朋友有所幫助!

初步了解一下Laravel中的生命周期

php 的生命周期

PHP運行模式

PHP兩種運行模式是WEB模式、CLI模式。

  • 當我們在終端敲入php這個命令的時候,使用的是CLI模式。

  • 當使用nginx或者別web服務器作為宿主處理一個到來的請求時,使用的是WEB模式。

生命周期

當我們請求一個php文件時,PHP 為了完成這次請求,會發生5個階段的生命周期切換:

模塊初始化(MINIT),即調用 php.ini 中指明的擴展的初始化函數進行初始化工作,如 mysql 擴展。

請求初始化(RINIT),即初始化為執行本次腳本所需要的變量名稱和變量值內容的符號表,如 $_SESSION變量。

執行該PHP腳本。

請求處理完成(Request Shutdown),按順序調用各個模塊的 RSHUTDOWN 方法,對每個變量調用 unset函數,如 unset $_SESSION 變量。

關閉模塊(Module Shutdown) , PHP調用每個擴展的 MSHUTDOWN 方法,這是各個模塊最后一次釋放內存的機會。這意味著沒有下一個請求了。

WEB模式和CLI(命令行)模式很相似,區別是:

CLI 模式會在每次腳本執行經歷完整的5個周期,因為你腳本執行完不會有下一個請求; WEB模式為了應對并發,可能采用線程,因此生命周期1和5有可能只執行一次,下次請求到來時重復2-4的生命周期,這樣就節省了系統模塊初始化所帶來的開銷。 可以看出PHP生命周期是很對稱的。說了這么多,就是為了定位laravel運行在哪里,沒錯,Laravel僅僅運行再 第三個階段:

初步了解一下Laravel中的生命周期

作用

理解這些,你就可以優化你的 Laravel 代碼,可以更加深入的了解 Laravel 的singleton(單例)。至少你知道了,每一次請求結束,PHP 的變量都會 unset,Laravel 的 singleton 只是在某一次請求過程中的singleton;你在 Laravel 中的靜態變量也不能在多個請求之間共享,因為每一次請求結束都會 unset。理解這些概念,是寫高質量代碼的第一步,也是最關鍵的一步。因此記住,PHP是一種腳本語言,所有的變量只會在這一次請求中生效,下次請求之時已被重置,而不像Java靜態變量擁有全局作用。

Laravel 的生命周期

概述

Laravel 的生命周期從publicindex.php開始,從publicindex.php結束。

初步了解一下Laravel中的生命周期

下面是 publicindex.php的全部源碼,更具體來說可以分為四步:

1.?require?__DIR__.'/../bootstrap/autoload.php';  2.?$app?=?require_once?__DIR__.'/../bootstrap/app.php'; ???$kernel?=?$app->make(IlluminateContractshttpKernel::class);  3.?$response?=?$kernel->handle( ??????$request?=?IlluminateHttpRequest::capture() ???); ???$response->send();  4.?$kernel->terminate($request,?$response);

以下是四步詳細的解釋是: composer自動加載需要的類

文件載入composer生成的自動加載設置,包括所有你 composer require的依賴。

生成容器Container,Application實例,并向容器注冊核心組件(HttpKernel,consoleKernel ,ExceptionHandler)(對應代碼2,容器很重要,后面詳細講解)。

處理請求,生成并發送響應(對應代碼3,毫不夸張的說,你99%的代碼都運行在這個小小的handle 方法里面)。

請求結束,進行回調(對應代碼4,還記得可終止中間件嗎?沒錯,就是在這里回調的)。

初步了解一下Laravel中的生命周期

我們不妨在詳細一點:

第一步:注冊加載composer自動生成的class loader 就是加載初始化第三方依賴。

第二步:生成容器 Container 并向容器注冊核心組件,是從 bootstrap/app.php 腳本獲取 Laravel 應用實例,

第三步:這一步是重點,處理請求,并生成發送響應。 請求被發送到 HTTP 內核或 Console 內核,這取決于進入應用的請求類型。

取決于是通過瀏覽器請求還是通過控制臺請求。這里我們主要是通過瀏覽器請求。HTTP 內核的標志性方法 handle處理的邏輯相當簡單:獲取一個 Request,返回一個 Response,把該內核想象作一個代表整個應用的大黑盒子,輸入 HTTP 請求,返回 HTTP 響應。

首先 Bootstrap 檢測環境,加載 bootstrapper數組中的一些配置

HTTP 內核繼承自 IlluminateFoundationHttpKernel 類,該類定義了一個 bootstrappers 數組,這個數組中的類在請求被執行前運行,這些 bootstrappers 配置了錯誤處理、日志、檢測應用環境以及其它在請求被處理前需要執行的任務。

protected?$bootstrappers?=?[ ????//注冊系統環境配置?(.env) ????'IlluminateFoundationBootstrapDetectEnvironment', ????//注冊系統配置(config) ????'IlluminateFoundationBootstrapLoadConfiguration', ????//注冊日志配置 ????'IlluminateFoundationBootstrapConfigureLogging', ????//注冊異常處理 ????'IlluminateFoundationBootstrapHandleExceptions', ????//注冊服務容器的門面,Facade?是個提供從容器訪問對象的類。 ????'IlluminateFoundationBootstrapregisterFacades', ????//注冊服務提供者 ????'IlluminateFoundationBootstrapRegisterProviders', ????//注冊服務提供者?`boot` ????'IlluminateFoundationBootstrapBootProviders', ];

注意順序:

Facades 先于ServiceProviders,Facades也是重點,后面說,這里簡單提一下,注冊 Facades 就是注冊 configapp.php中的aliases 數組,你使用的很多類,如Auth,Cache,DB等等都是Facades;而ServiceProviders的register方法永遠先于boot方法執行,以免產生boot方法依賴某個實例而該實例還未注冊的現象。HTTP 內核還定義了一系列所有請求在處理前需要經過的 HTTP 中間件,這些中間件處理 HTTP 會話的讀寫、判斷應用是否處于維護模式、驗證 csrf 令牌等等。

第一堵墻,全局中間件,默認為 CheckForMaintenanceMode

在Laravel基礎的服務啟動之后,就要把請求傳遞給路由了。路由器將會分發請求到路由或控制器,同時運行所有路由指定的中間件。

傳遞方式: 傳遞給路由是通過 Pipeline(管道)來傳遞的,但是Pipeline有一堵墻,在傳遞給路由之前所有請求都要經過,這堵墻定義在appHttpKernel.php中的$middleware數組中,沒錯就是中間件,默認只有一個CheckForMaintenanceMode中間件,用來檢測你的網站是否暫時關閉。這是一個全局中間件,所有請求都要經過,你也可以添加自己的全局中間件。

然后遍歷所有注冊的路由,找到最先符合的第一個路由

然后遍歷所有注冊的路由,找到最先符合的第一個路由,

第二堵墻,通過該路由的中間件(組)

經過該路由中間件,進入到控制器或者閉包函數,執行你的具體邏輯代碼。

所以,當請求到達你寫的代碼之前,Laravel已經做了大量工作,請求也經過了千難萬險,那些不符合或者惡意的的請求已被Laravel隔離在外。

初步了解一下Laravel中的生命周期

原文地址:https://juejin.cn/post/6992208648575385607

作者:卡二條

相關推薦:laravel

? 版權聲明
THE END
喜歡就支持一下吧
點贊10 分享