ginkgo


生命周期

本篇对 ginkgo 的应用请求的生命周期做大致的介绍,以便于开发者了解整个执行流程。


入口文件

用户发起的请求都会经过应用的入口文件,通常是 public/index.php 文件。当然,也可以更改或者增加新的入口文件。

通常入口文件的代码都比较简单,一个普通的入口文件代码如下:

// 定义应用目录
define('GK_PATH_APP', __DIR__ . '/../app/'); //应用目录

// 加载框架引导文件
require(__DIR__ . '/../ginkgo/boot.php');

一般入口文件以定义一些常量为主,支持的常量请参考后续的内容或者附录部分。

通常,不建议在入口文件中加入过多的代码,尤其是和业务逻辑相关的代码。


引导文件

接下来就是执行框架的引导文件,boot.php 文件就是系统默认的一个引导文件。在引导文件中,会依次执行下面操作:

  • 加载系统常量定义
  • 注册自动加载机制
  • 注册错误和异常处理机制
  • 加载默认配置文件
  • 执行应用

boot.php 文件首先会调用 base.php 初始化文件,某些特殊需求下,可以直接在入口文件中加载初始化文件。

如果在你的入口文件中更改了默认的引导文件,则上述执行流程可能会跟随发生变化。


注册自动加载

系统会调用 Loader::register() 方法注册自动加载,在这一步完成后,所有符合规范的类库(包括 Composer 依赖加载的第三方类库)都将自动加载。

系统的自动加载由下面主要部分组成:

  • 注册系统的自动加载方法 ginkgo\Loader::autoload
  • 如果存在 Composer 安装,则注册 Composer 自动加载
  • 注册 extend 扩展目录

注册错误和异常机制

执行 Error::register() 注册错误和异常处理机制。

由三部分组成:

  • 应用关闭方法:ginkgo\Error::appShutdown
  • 错误处理方法:ginkgo\Error::appError
  • 异常处理方法:ginkgo\Error::appException

注册应用关闭方法是为了便于拦截一些系统错误。

在整个应用请求的生命周期过程中,如果抛出了异常或者严重错误,均会导致应用提前结束,并响应输出异常和错误信息。


应用初始化

执行应用的第一步操作就是对应用进行初始化,包括:

  • 加载应用配置
  • 加载扩展配置文件
  • 加载公共文件
  • 设置默认时区
  • 加载系统语言包

URL 检测

应用初始化完成后,就会进行URL的访问检测,包括 PATH_INFO 检测和 URL 后缀检测。

URL 访问必须是 PATH_INFO 方式(包括兼容方式)的 URL 地址,例如:

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

如果配置了路由规则,会首先进行 URL 的路由检测。如果一旦匹配到路由,根据定义的路由地址会调度到相应的 URL。


分发请求

在完成了 URL 检测和路由检测之后,路由器会分发请求到对应的路由地址,这也是应用请求的生命周期中最重要的一个环节。

在这一步骤中,完成应用的业务逻辑及数据返回。

建议统一使用 return 返回数据,而不是 echo 输出,如非必要,请不要使用 exit 或者 die 中断执行。

直接 echo 输出的数据将无法进行自动转换响应输出的便利。


响应输出

控制器的所有动作都是 return 返回而不是直接输出,系统会调用 Response::send() 方法将最终的应用返回的数据输出到页面或者客户端。


应用结束

事实上,在应用的数据响应输出之后,应用并没真正的结束,系统会在应用输出或者中断后进行日志保存写入操作。

系统的日志包括用户调试输出的和系统自动生成的日志,统一会在应用结束的时候进行写入操作。

而日志的写入操作受日志初始化的影响。