php request render,laravel5.5框架解析[3]——响应Request的流程

laravel5.5框架解析系列文章属于对laravel5.5框架源码分析,如有需要,建议按顺序阅读该系列文章, 不定期更新,欢迎关注

掌握laravel应用的代码执行流程, 对解决项目构建过程中遇到的一些疑难杂症大有裨益.

index.php

作为一个单入口的应用, 想要了解执行流程当然是去看index.php咯

// 记录一下框架启动时间, 可以看一次请求花了多长时间来响应

define('LARAVEL_START', microtime(true));

// composer自动加载

require __DIR__.'/../vendor/autoload.php';

// 这个bootstrap文件里创建了一个Application实例

$app = require_once __DIR__.'/../bootstrap/app.php';

// 通过容器创建了一个http kernel

$kernel = $app->make(Illuminate\Contracts\Http\Kernel::class);

// Request类通过全局变量创建了一个Request实例,

// 通过调用kernel的handle方法, 就得到了一个response

$response = $kernel->handle(

$request = Illuminate\Http\Request::capture()

);

// 把response内容发送到浏览器

$response->send();

// 执行一些耗时的后续工作

$kernel->terminate($request, $response);

好简单有木有:)

如何启动Application

创建应用实例

创建Application实例的bootstrap.php代码如下

// 传入项目目录,实例化Application, 即容器. Application继承自Container

$app = new Illuminate\Foundation\Application(

realpath(__DIR__.'/../')

);

// 绑定http kernel实现类, 单例模式

$app->singleton(

Illuminate\Contracts\Http\Kernel::class,

App\Http\Kernel::class

);

// 绑定 console kernel 实现类

$app->singleton(

Illuminate\Contracts\Console\Kernel::class,

App\Console\Kernel::class

);

// 绑定异常处理实现类

$app->singleton(

Illuminate\Contracts\Debug\ExceptionHandler::class,

App\Exceptions\Handler::class

);

return $app;

好像没啥步骤啊, 为啥还把创建Application单独写一个文件, 不放在index.php里? 因为index.php是由cgi进程执行的,但是你可能需要在cli环境下运行Application哟, 比如测试, 和artisan. 所以就单独放在文件, 需要的地方再require.

你可能奇怪了怎么没有注册绑定那些service啊? 请继续往下看

Application 初始化

Application代码

public function __construct($basePath = null)

{

// 项目目录, 很多地方要用

if ($basePath) {

$this->setBasePath($basePath);

}

// 基本绑定

$this->registerBaseBindings();

// 基本service绑定

$this->registerBaseServiceProviders();

// 别名

$this->registerCoreContainerAliases();

}

protected function registerBaseBindings()

{

// 把实例存在类里边

static::setInstance($this);

// 把自己放到容器

$this->instance('app', $this);

// 把自己放到容器again, 并绑到Container的实现

$this->instance(Container::class, $this);

// PackageManifest,这个东西是laravel5.5新增的,

// 5.5 安装拓展包, 不需要手动配provider了(如果拓展包支持的话),

// 他会从拓展包的composer.json extra配置中读取.

// 个人认为其实可以通过composer插件的方式安装拓展包,

// 这样可以在安装阶段配置service provider, 而不是运行阶段

$this->instance(PackageManifest::class, new PackageManifest(

new Filesystem, $this->basePath(), $this->getCachedPackagesPath()

));

}

// 加载基本的service provider, 启动模块

protected function registerBaseServiceProviders()

{

// 事件模块

$this->register(new EventServiceProvider($this));

// log模块

$this->register(new LogServiceProvider($this));

// 路由模块

$this->register(new RoutingServiceProvider($this));

}

// 这就把web组件都给绑定到实现类并注册了一个别名, 然后你就可以各种app('config'), $app['config'], $app->make('config')

public function registerCoreContainerAliases()

{

foreach ([

'app' => [\Illuminate\Foundation\Application::class, \Illuminate\Contracts\Container\Container::class, \Illuminate\Contracts\Foundation\Application::class, \Psr\Container\ContainerInterface::class],

'auth' => [\Illuminate\Auth\AuthManager::class, \Illuminate\Contracts\Auth\Factory::class],

'auth.driver' => [\Illuminate\Contracts\Auth\Guard::class],

'blade.compiler' => [\Illuminate\View\Compilers\BladeCompiler::class],

'cache' => [\Illuminate\Cache\CacheManager::class, \Illuminate\Contracts\Cache\Factory::class],

'cache.store' => [\Illuminate\Cache\Repository::class, \Illuminate\Contracts\Cache\Repository::class],

'config' => [\Illuminate\Config\Repository::class, \Illuminate\Contracts\Config\Repository::class],

'cookie' => [\Illuminate\Cookie\CookieJar::class, \Illuminate\Contracts\Cookie\Factory::class, \Illuminate\Contracts\Cookie\QueueingFactory::class],

'encrypter' => [\Illuminate\Encryption\Encrypter::class, \Illuminate\Contracts\Encryption\Encrypter::class],

'db' => [\Illuminate\Database\DatabaseManager::class],

'db.connection' => [\Illuminate\Database\Connection::class, \Illuminate\Database\ConnectionInterface::class],

'events' => [\Illuminate\Events\Dispatcher::class, \Illuminate\Contracts\Events\Dispatcher::class],

'files' => [\Illuminate\Filesystem\Filesystem::class],

'filesystem' => [\Illuminate\Filesystem\FilesystemManager::class, \Illuminate\Contracts\Filesystem\Factory::class],

'filesystem.disk' => [\Illuminate\Contracts\Filesystem\Filesystem::class],

'filesystem.cloud' => [\Illuminate\Contracts\Filesystem\Cloud::class],

'hash' => [\Illuminate\Contracts\Hashing\Hasher::class],

'translator' => [\Illuminate\Translation\Translator::class, \Illuminate\Contracts\Translation\Translator::class],

'log' => [\Illuminate\Log\Writer::class, \Illuminate\Contracts\Logging\Log::class, \Psr\Log\LoggerInterface::class],

'mailer' => [\Illuminate\Mail\Mailer::class, \Illuminate\Contracts\Mail\Mailer::class, \Illuminate\Contracts\Mail\MailQueue::class],

'auth.password' => [\Illuminate\Auth\Passwords\PasswordBrokerManager::class, \Illuminate\Contracts\Auth\PasswordBrokerFactory::class],

'auth.password.broker' => [\Illuminate\Auth\Passwords\PasswordBroker::class, \Illuminate\Contracts\Auth\PasswordBroker::class],

'queue' => [\Illuminate\Queue\QueueManager::class, \Illuminate\Contracts\Queue\Factory::class, \Illuminate\Contracts\Queue\Monitor::class],

'queue.connection' => [\Illuminate\Contracts\Queue\Queue::class],

'queue.failer' => [\Illuminate\Queue\Failed\FailedJobProviderInterface::class],

'redirect' => [\Illuminate\Routing\Redirector::class],

'redis' => [\Illuminate\Redis\RedisManager::class, \Illuminate\Contracts\Redis\Factory::class],

'request' => [\Illuminate\Http\Request::class, \Symfony\Component\HttpFoundation\Request::class],

'router' => [\Illuminate\Routing\Router::class, \Illuminate\Contracts\Routing\Registrar::class, \Illuminate\Contracts\Routing\BindingRegistrar::class],

'session' => [\Illuminate\Session\SessionManager::class],

'session.store' => [\Illuminate\Session\Store::class, \Illuminate\Contracts\Session\Session::class],

'url' => [\Illuminate\Routing\UrlGenerator::class, \Illuminate\Contracts\Routing\UrlGenerator::class],

'validator' => [\Illuminate\Validation\Factory::class, \Illuminate\Contracts\Validation\Factory::class],

'view' => [\Illuminate\View\Factory::class, \Illuminate\Contracts\View\Factory::class],

] as $key => $aliases) {

foreach ($aliases as $alias) {

$this->alias($key, $alias);

}

}

}

Application 貌似启动完成, 看一下这个时候容器里有啥

在index.php里 执行

$app = require_once __DIR__.'/../bootstrap/app.php';

// ------------- 加入下面这些 -----------

$rf = new ReflectionClass(\Illuminate\Container\Container::class);

$p = $rf->getProperty('resolved');

$p->setAccessible(true);

dd($p->getValue($app));

浏览器输出结果

[]

哈哈, 啥都没有. 虽然只是注册了服务,并未resolve, 可是之前不是有注册service provider吗, 难道这个也不需要resolve?

实际上此时service provider都还没有被resolve并执行. 那么真正执行在哪儿呢, 实际上在http kernel的handle 流程里, 请看下节

handle($request)

一个request到底经历了怎样的千难万险,才得以历练出正确的response呢? 来一探究竟

Illuminate\Foundation\Http\Kernel :

public function handle($request)

{

try {

// 开启请求method覆盖, 就是文档里提到的如何在不支持的浏览器里发送delete等请求

$request->enableHttpMethodParameterOverride();

// 把请求发送给路由, 得到response, 详情在下边

$response = $this->sendRequestThroughRouter($request);

} catch (Exception $e) { // Request->Response途中遇到异常, 在这进行处理

// 记录日志

$this->reportException($e);

// 生成异常相应, 以便发送到浏览器

$response = $this->renderException($request, $e);

} catch (Throwable $e) {

// 致命错误

$this->reportException($e = new FatalThrowableError($e));

$response = $this->renderException($request, $e);

}

// 触发相应事件

$this->app['events']->dispatch(

new Events\RequestHandled($request, $response)

);

return $response;

}

// 请求变响应

protected function sendRequestThroughRouter($request)

{

// request 保存到容器

$this->app->instance('request', $request);

// 门面缓存清除, 因为门面会从容器中取实例然后缓存,

// 刚刚刷新了容器中的Request, 为了让facade能更新实例, 就清楚缓存

Facade::clearResolvedInstance('request');

// 这个就是前面提到的会在handle流程里初始化Application的service provider

// 为什么Application 会放在这启动呢? 因为不同情况下Application需要的加载不同的基础service provider,

// 所以就没有放在Application中启动, 而是提供了bootstrapWith的公开方法,

// 供外部按需传入service provider 进行启动, 这里传入了下面这些provider

// 用于加载 .env 配置文件

// \Illuminate\Foundation\Bootstrap\LoadEnvironmentVariables::class,

// 加载config文件夹下配置

// \Illuminate\Foundation\Bootstrap\LoadConfiguration::class,

// 注册异常处理, laravel5.5 用whoops来渲染异常

// \Illuminate\Foundation\Bootstrap\HandleExceptions::class,

// 注册门面服务

// \Illuminate\Foundation\Bootstrap\RegisterFacades::class,

// laravel5.5 新功能, 注册通过composer.json来提供provider类的 provider

// \Illuminate\Foundation\Bootstrap\RegisterProviders::class,

// register 完毕之后, 最后boot注册过的service provider

// \Illuminate\Foundation\Bootstrap\BootProviders::class,

$this->bootstrap();

// 最后通过pipeline, 把Request经过全局中间件, 发送到路由分发过程

// 后面的文章会有pipeline实现原理分析

return (new Pipeline($this->app))

->send($request)

->through($this->app->shouldSkipMiddleware() ? [] : $this->middleware)

->then($this->dispatchToRouter());

}

下面是如何将Request发送到匹配路由 Illuminate\Routing\Router

public function dispatchToRoute(Request $request)

{

// 通过Request匹配到路由, 匹配不到直接抛异常, 而不是返回null.

// 是不是返回null ,在这里在抛 404 更合理呢?

$route = $this->findRoute($request);

// 把route绑到request上, 这样在其他地方, 你可以通过request 获取到匹配的路由

$request->setRouteResolver(function () use ($route) {

return $route;

});

// 触发路由匹配事件

$this->events->dispatch(new Events\RouteMatched($route, $request));

// 执行路由, 得到相应

$response = $this->runRouteWithinStack($route, $request);

// 把控制器或者路由级中间件返回的结果(可能是array,string, int 或其他类型), 转换成Response实例

return $this->prepareResponse($request, $response);

}

// router中执行路由的过程

protected function runRouteWithinStack(Route $route, Request $request)

{

// 是否跳过中间件, 特殊情况下, 或者测试时有可能需要跳过

$shouldSkipMiddleware = $this->container->bound('middleware.disable') &&

$this->container->make('middleware.disable') === true;

//取出路由中间件

$middleware = $shouldSkipMiddleware ? [] : $this->gatherRouteMiddleware($route);

// 把Request过一遍路由中间件, 然后执行路由,

// 这里也调用了prepareResponse, 上面那也调用了, 为什么会调用2次? 有趣吧,哈哈.

// 这里的response其实是返回给全局中间件那里去了, 而全局中间件可能会根据response的内容,

// 决定不予发送给浏览器, 而是自己发送了一个其他响应, 比如返回一个数组[code=>500, msg=>'sth. went wrong'],

// 所以, 经过全局回来的response还要再prepare一遍. 且保证中间件的handle流程里$next()返回的是一个Response实例

return (new Pipeline($this->container))

->send($request)

->through($middleware)

->then(function ($request) use ($route) {

return $this->prepareResponse(

$request, $route->run()

);

});

}

terminate()

pipeline管道是有始有终的, 从哪里进去, 就得从哪里出来, 不过大变活人, Request进去, Response出来了.所以相应最后到了http kernel 的handle方法里,在index.php中,相应被发送到浏览器

最后执行terminal方法 Http\Kernel

public function terminate($request, $response)

{

// 注册的中间件如果有terminate调用terminate方法

// session 存盘就是在中间件terminate中完成的, 所以很多人在controller

// 中使用了dd()函数, 就发现session出问题了. 因为dd()会使程序直接退出,

// 这时候请使用dump()来输出变量

$this->terminateMiddleware($request, $response);

// Application的terminate, 他会调用通过terminating方法注册的回调

$this->app->terminate();

}