thinkphp源碼分析(一)—開門篇

源碼分析—開門篇

thinkphp生命週期

一、入口文件

用戶發起的請求都會通過應用的入口文件,一般是 ==public/index.php==文件。固然,你也能夠更改或者增長新的入口文件。

一般入口文件的代碼都比較簡單,一個普通的入口文件代碼以下:php

// 應用入口文件

// 定義項目路徑
define('APP_PATH', __DIR__ . '/../application/');
// 加載框架引導文件
require __DIR__ . '/../thinkphp/start.php';

通常入口文件以定義一些常量爲主,支持的常量請參考後續的內容或者附錄部分。thinkphp

一般,咱們不建議在應用入口文件中加入過多的代碼,尤爲是和業務邏輯相關的代碼。閉包

二、引導文件

接下來就是執行框架的引導文件,start.php文件就是系統默認的一個引導文件。在引導文件中,會依次執行下面操做:
1. 加載系統常量定義;
2. 加載環境變量定義文件;
3. 註冊自動加載機制;
4. 註冊錯誤和異常處理機制;
5. 加載慣例配置文件;
6. 執行應用;

start.php引導文件首先會調用base.php基礎引導文件,某些特殊需求下面可能直接在入口文件中引入基礎引導文件。app

若是在你的應用入口文件中更改了默認的引導文件,則上述執行流程可能會跟隨發生變化。框架

三、註冊自動加載

系統會調用 Loader::register()方法註冊自動加載,在這一步完成後,全部符合規範的類庫(包括Composer依賴加載的第三方類庫)都將自動加載。函數

系統的自動加載由下面主要部分組成:源碼分析

1. 註冊系統的自動加載方法 \think\Loader::autoload
2. 註冊系統命名空間定義
3. 加載類庫映射文件(若是存在)
4. 若是存在Composer安裝,則註冊**Composer**自動加載
5. 註冊extend擴展目錄

一個類庫的自動加載檢測順序爲:ui

1. 是否認義類庫映射;
2. PSR-4自動加載檢測;
3. PSR-0自動加載檢測;
4. 能夠看到,定義類庫映射的方式是最高效的。

四、註冊錯誤和異常機制

執行Error::register()註冊錯誤和異常處理機制。

由三部分組成:url

1. 應用關閉方法:think\Error::appShutdown
2. 錯誤處理方法:think\Error::appError
3. 異常處理方法:think\Error::appException

註冊應用關閉方法是爲了便於攔截一些系統錯誤。spa

在整個應用請求的生命週期過程當中,若是拋出了異常或者嚴重錯誤,均會致使應用提早結束,並響應輸出異常和錯誤信息。

五、應用初始化

執行應用的第一步操做就是對應用進行初始化,包括:
1. 加載應用(公共)配置;
2. 加載擴展配置文件(由extra_config_list定義);
3. 加載應用狀態配置;
4. 加載別名定義;
5. 加載行爲定義;
6. 加載公共(函數)文件;
7. 註冊應用命名空間;
8. 加載擴展函數文件(由extra_file_list定義);
9. 設置默認時區;
10. 加載系統語言包;

六、URL訪問檢測

應用初始化完成後,就會進行URL的訪問檢測,包括PATH_INFO檢測和URL後綴檢測。

5.0的URL訪問必須是PATH_INFO方式(包括兼容方式)的URL地址,例如:

http://serverName/index.php/index/index/hello/val/value

因此,若是你的環境只能支持普通方式的URL參數訪問,那麼必須使用

http://serverName/index.php?s=/index/index/hello&val=value

若是是命令行下面訪問入口文件的話,則經過

$ php index.php index/index/hello/val/value...

獲取到正常的 ==$_SERVER['PATH_INFO']== 參數後才能繼續。

七、路由檢測

若是開啓了url_route_on參數的話,會首先進行URL的路由檢測。

若是一旦檢測到匹配的路由,根據定義的路由地址會註冊到相應的URL調度。

5.0的路由地址支持以下方式:

1. 路由到模塊/控制器/操做;
2. 路由到外部重定向地址;
3. 路由到控制器方法;
4. 路由到閉包函數;
5. 路由到類的方法;
6. 路由地址可能會受域名綁定的影響。

若是關閉路由或者路由檢測無效則進行默認的模塊/控制器/操做的分析識別。

若是在應用初始化的時候指定了應用調度方式,那麼路由檢測是可選的。

可使用 thinkApp::dispatch() 進行應用調度,例如:

App::dispatch(['type' => 'module', 'module' => 'index/index']);

八、分發請求

在完成了URL檢測和路由檢測以後,路由器會分發請求到對應的路由地址,這也是應用請求的生命週期中最重要的一個環節。

在這一步驟中,完成應用的業務邏輯及數據返回。

建議統一使用return返回數據,而不是echo輸出,如非必要,請不要使用exit或者die中斷執行。

直接echo輸出的數據將沒法進行自動轉換響應輸出的便利。

下面是系統支持的分發請求機制,能夠根據狀況選擇:

模塊/控制器/操做

這是默認的分發請求機制,系統會根據URL或者路由地址來判斷當前請求的模塊、控制器和操做名,並自動調用相應的訪問控制器類,執行操做對應的方法。
該機制下面,首先會判斷當前模塊,並進行模塊的初始化操做(和應用的初始化操做相似),模塊的配置參數會覆蓋應用的還沒有生效的配置參數。

支持模塊映射、URL參數綁定到方法,以及操做綁定到類等一些功能。

控制器方法

和前一種方式相似,只是無需判斷模塊、控制器和操做,直接分發請求到一個指定的控制器類的方法,所以沒有進行模塊的初始化操做。

外部重定向

能夠直接分發請求到一個外部的重定向地址,支持指定重定向代碼,默認爲301重定向。

閉包函數

路由地址定義的時候能夠直接採用閉包函數,完成一些相對簡單的邏輯操做和輸出。

類的方法

除了以上方式外,還支持分發請求到類的方法,包括:

靜態方法: 'blog/:id'=>'\org\util\Blog::read'
類的方法:'blog/:id'=>'\app\index\controller\Blog@read'

九、響應輸出

控制器的全部操做方法都是return返回而不是直接輸出,系統會調用Response::send方法將最終的應用返回的數據輸出到頁面或者客戶端,並自動轉換成default_return_type參數配置的格式。因此,應用執行的數據輸出只須要返回一個正常的PHP數據便可。

十、應用結束

事實上,在應用的數據響應輸出以後,應用並沒真正的結束,系統會在應用輸出或者中斷後進行日誌保存寫入操做。

系統的日誌包括用戶調試輸出的和系統自動生成的日誌,統一會在應用結束的時候進行寫入操做。

而日誌的寫入操做受日誌初始化的影響。

相關文章
相關標籤/搜索