This is the sixth day of my participation in the August More text Challenge. For details, see:August is more challenging

The lifecycle of PHP

PHP runtime mode

The two operating modes of PHP are WEB mode and CLI mode.

  1. When we type the PHP command at the terminal, we use CLI mode.
  2. Web mode is used when an incoming request is hosted by Nginx or another Web server.

The life cycle

When we request a PHP file,PHP performs a 5-phase lifecycle switch in order to complete the request:

Module initialization (MINIT), which calls the initialization function of the extension specified in php.ini, such as the mysql extension.

Request initialization (RINIT), which is a symbol table initialized with the contents of variable names and variable values needed to execute this script, such as the $_SESSION variable.

Execute the PHP script.

When the Request is Shutdown, call the RSHUTDOWN method of each module in sequence, and call the unset function for each variable, such as unset $_SESSION variable.

To close the Module Shutdown, PHP calls each extended MSHUTDOWN method. This is the last chance for each Module to free memory. This means there is no next request.

The WEB mode is similar to the CLI (command line) mode. The differences are:

The CLI mode takes a full 5 cycles for each script execution, because you don’t get another request after the script is executed; The WEB pattern may be multi-threaded to cope with concurrency, so it is possible for lifecycle 1 and 5 to be executed only once, repeating lifecycle 2-4 when the next request comes, thus saving the overhead of system module initialization. As you can see, the PHP lifecycle is very symmetric. All of this is to locate where Laravel is running. Yes, Laravel is only running in the third stage:

role

By understanding this, you can optimize your Laravel code and get a deeper understanding of Laravel’s Singletons. At least you know that PHP variables are unset at the end of each request, and Laravel’s Singleton is only the singleton that was used during that particular request. Your static variables in Laravel also cannot be shared across multiple requests because they are unset at the end of each request. Understanding these concepts is the first and most critical step in writing high-quality code. So remember, PHP is a scripting language, and all variables are only valid on this request and are reset on the next request, unlike Java static variables that have global effects.

Life cycle of Laravel

An overview of the

The Laravel life cycle starts with public\index.php and ends with public\index.php.

Here is the full source code for public\index. PHP. More specifically, it can be divided into four steps:

1. require __DIR__.'/.. /bootstrap/autoload.php';

2. $app = require_once __DIR__.'/.. /bootstrap/app.php';
   $kernel = $app->make(Illuminate\Contracts\Http\Kernel::class);

3. $response = $kernel->handle(
      $request = Illuminate\Http\Request::capture()
   );
   $response->send();

4. $kernel->terminate($request.$response);
Copy the code

Here are four detailed steps: Composer automatically loads the required classes

Auto-load Settings generated by file loading Composer, including any dependencies that your composer requires.

Generate the Container, Application instance, and register the core components (HttpKernel, ConsoleKernel, ExceptionHandler) with the Container (corresponding to code 2, the Container is important, more on this later).

Handle the request, generate and send the response (corresponding to code 3, literally 99% of your code runs in this little handle method).

The request is finished and the callback is made (corresponding to code 4, remember the terminable middleware? Yes, that’s where the callback is).

Let’s go into more detail:

Step 1: Register the class Loader automatically generated by loading Composer to initialize third-party dependencies.

Step 2: Generate the Container and register the core components with the Container. Get the Laravel application instance from bootstrap/app.php

Step 3: This is the key step, processing the request and generating the send response. The request is sent to either the HTTP kernel or the Console kernel, depending on the type of request that enters the application.

Depends on whether the request is made through the browser or the console. In this case, we are mainly requesting through the browser. The signature HANDLE method in the HTTP kernel works with fairly simple logic: take a Request, return a Response, think of the kernel as a big black box representing the entire application, enter an HTTP Request, and return an HTTP Response.

First, Bootstrap checks the environment and loads some configurations in the Bootstrapper array

The HTTP Kernel inherits from the Illuminate/Foundation/HTTP/Kernel class, which defines an array of bootstrappers classes that run before the request is executed, These Bootstrappers are configured for error handling, logging, detecting the application environment, and other tasks that need to be performed before the request can be processed.

protected $bootstrappers = [
    // Register the system environment configuration (.env)
    'Illuminate\Foundation\Bootstrap\DetectEnvironment'.// Register system configuration (config)
    'Illuminate\Foundation\Bootstrap\LoadConfiguration'.// Register the log configuration
    'Illuminate\Foundation\Bootstrap\ConfigureLogging'.// Register the exception handling
    'Illuminate\Foundation\Bootstrap\HandleExceptions'.// Register the Facade of the service container. The Facade is a class that provides access to objects from the container.
    'Illuminate\Foundation\Bootstrap\RegisterFacades'.// Register the service provider
    'Illuminate\Foundation\Bootstrap\RegisterProviders'.// Register service provider 'boot'
    'Illuminate\Foundation\Bootstrap\BootProviders',];Copy the code

Notice the order:

To register Facades, you need to register the aliases array in config\app.php. Many of the classes you use, such as Auth, Cache,DB, and so on are Facades; The register method of ServiceProviders is always executed before the boot method. This prevents the boot method from relying on an instance that has not been registered. The HTTP kernel also defines a set of HTTP middleware that all requests must pass through before they are processed, which handles reading and writing the HTTP session, determining whether the application is in maintenance mode, validating CSRF tokens, and so on.

The first wall, the global middleware, defaults to CheckForMaintenanceMode

After the Laravel underlying service is started, it is time to pass the request to the route. The router will distribute the request to the route or controller, while running all the routing specified middleware.

Delivery mode: This wall is defined in the $middleware array in app, Http, kernel.php By default there is only one middleware, CheckForMaintenanceMode, to check if your site is temporarily down. This is a global middleware that all requests go through, and you can add your own global middleware as well.

Then, all the registered routes are traversed to find the first route that matches the first one

Then we iterate through all the registered routes to find the first one that matches,

Second wall, middleware (group) through this route

Through the routing middleware, into the controller or closure function, to execute your concrete logic code.

So, by the time the request reaches the code you wrote, Laravel has done a lot of work, the request has gone through a lot of trouble, and the requests that are not conforming or malicious will have been isolated by Laravel.