Composer的Autoload源碼實現——注冊與運行

wanghui 發布于2019-06-27 16:27 / 851人閱讀

前言

在開始之前，歡迎關注我自己的博客：www.leoyang90.cn
上一篇文章我們講到了 Composer 自動加載功能的啟動與初始化，經過啟動與初始化，自動加載核心類對象已經獲得了頂級命名空間與相應目錄的映射，換句話說，如果有命名空間 "AppConsoleKernel，我們已經知道了 App 對應的目錄，接下來我們就要解決下面的就是 ConsoleKernel這一段。

注冊

我們先回顧一下自動加載引導類：

public static function getLoader()
{
        /***************************經典單例模式********************/
        if (null !== self::$loader) {
            return self::$loader;
        }
        
        /***********************獲得自動加載核心類對象********************/
        spl_autoload_register(array("ComposerAutoloaderInit
        832ea71bfb9a4128da8660baedaac82e", "loadClassLoader"), true, true);
        
        self::$loader = $loader = new ComposerAutoloadClassLoader();
        
        spl_autoload_unregister(array("ComposerAutoloaderInit
        832ea71bfb9a4128da8660baedaac82e", "loadClassLoader"));

        /***********************初始化自動加載核心類對象********************/
        $useStaticLoader = PHP_VERSION_ID >= 50600 && 
        !defined("HHVM_VERSION");
        
        if ($useStaticLoader) {
            require_once __DIR__ . "/autoload_static.php";

            call_user_func(ComposerAutoloadComposerStaticInit
            832ea71bfb9a4128da8660baedaac82e::getInitializer($loader));
      
        } else {
            $map = require __DIR__ . "/autoload_namespaces.php";
            foreach ($map as $namespace => $path) {
                $loader->set($namespace, $path);
            }

            $map = require __DIR__ . "/autoload_psr4.php";
            foreach ($map as $namespace => $path) {
                $loader->setPsr4($namespace, $path);
            }

            $classMap = require __DIR__ . "/autoload_classmap.php";
            if ($classMap) {
                $loader->addClassMap($classMap);
            }
        }

        /***********************注冊自動加載核心類對象********************/
        $loader->register(true);

        /***********************自動加載全局函數********************/
        if ($useStaticLoader) {
            $includeFiles = ComposerAutoloadComposerStaticInit
            832ea71bfb9a4128da8660baedaac82e::$files;
        } else {
            $includeFiles = require __DIR__ . "/autoload_files.php";
        }
        
        foreach ($includeFiles as $fileIdentifier => $file) {
            composerRequire
            832ea71bfb9a4128da8660baedaac82e($fileIdentifier, $file);
        }

        return $loader;
    }

現在我們開始引導類的第四部分：注冊自動加載核心類對象。我們來看看核心類的 register() 函數：

public function register($prepend = false)
{
    spl_autoload_register(array($this, "loadClass"), true, $prepend);
}

簡單到爆炸啊！一行代碼實現自動加載有木有！其實奧秘都在自動加載核心類 ClassLoader 的 loadClass() 函數上，這個函數負責按照 PSR 標準將頂層命名空間以下的內容轉為對應的目錄，也就是上面所說的將 "AppConsoleKernel中"ConsoleKernel 這一段轉為目錄，至于怎么轉的我們在下面“Composer 自動加載源碼分析——運行”講。核心類 ClassLoader 將 loadClass() 函數注冊到 PHP SPL 中的spl_autoload_register() 里面去，這個函數的來龍去脈我們之前文章講過。這樣，每當 PHP 遇到一個不認識的命名空間的時候，PHP 會自動調用注冊到 spl_autoload_register 里面的函數堆棧，運行其中的每個函數，直到找到命名空間對應的文件。

全局函數的自動加載

Composer 不止可以自動加載命名空間，還可以加載全局函數。怎么實現的呢？很簡單，把全局函數寫到特定的文件里面去，在程序運行前挨個 require 就行了。這個就是 composer 自動加載的第五步，加載全局函數。

if ($useStaticLoader) {
    $includeFiles = ComposerAutoloadComposerStaticInit832ea71bfb9a4128da8660baedaac82e::$files;
} else {
    $includeFiles = require __DIR__ . "/autoload_files.php";
}

foreach ($includeFiles as $fileIdentifier => $file) {
    composerRequire832ea71bfb9a4128da8660baedaac82e($fileIdentifier, $file);
}

跟核心類的初始化一樣，全局函數自動加載也分為兩種：靜態初始化和普通初始化，靜態加載只支持 PHP5.6 以上并且不支持 HHVM。

靜態初始化：

ComposerStaticInit832ea71bfb9a4128da8660baedaac82e::$files：

public static $files = array (
      "0e6d7bf4a5811bfa5cf40c5ccd6fae6a" => __DIR__ . "/.." . "/symfony/polyfill-mbstring/bootstrap.php",
      "667aeda72477189d0494fecd327c3641" => __DIR__ . "/.." . "/symfony/var-dumper/Resources/functions/dump.php",
      ...
    );

看到這里我們可能又要有疑問了，為什么不直接放文件路徑名，還要一個 hash 干什么呢？這個我們一會兒講，我們這里先了解一下這個數組的結構。

普通初始化

autoload_files:

$vendorDir = dirname(dirname(__FILE__));
$baseDir = dirname($vendorDir);
    
return array(
    "0e6d7bf4a5811bfa5cf40c5ccd6fae6a" => $vendorDir . "/symfony/polyfill-mbstring/bootstrap.php",
    "667aeda72477189d0494fecd327c3641" => $vendorDir . "/symfony/var-dumper/Resources/functions/dump.php",
     ....
);

其實跟靜態初始化區別不大。

加載全局函數

class ComposerAutoloaderInit832ea71bfb9a4128da8660baedaac82e{
    public static function getLoader(){
        ...
        foreach ($includeFiles as $fileIdentifier => $file) {
            composerRequire832ea71bfb9a4128da8660baedaac82e($fileIdentifier, $file);
        }
        ...
    }
}

function composerRequire832ea71bfb9a4128da8660baedaac82e($fileIdentifier, $file)
{
      if (empty($GLOBALS["__composer_autoload_files"][$fileIdentifier])) {
          require $file;

          $GLOBALS["__composer_autoload_files"][$fileIdentifier] = true;
      }
}

這一段很有講究，
第一個問題：為什么自動加載引導類的 getLoader() 函數不直接 require includeFiles 里面的每個文件名，而要用類外面的函數composerRequire832ea71bfb9a4128da8660baedaac82e0？(順便說下這個函數名 hash 仍然為了避免和用戶定義函數沖突)因為怕有人在全局函數所在的文件寫 this 或者self。
假如 includeFiles 有個 app/helper.php 文件，這個 helper.php 文件的函數外有一行代碼：this->foo()，如果引導類在 getLoader() 函數直接 require(file)，那么引導類就會運行這句代碼，調用自己的 foo() 函數，這顯然是錯的。事實上 helper.php 就不應該出現 this 或 self 這樣的代碼，這樣寫一般都是用戶寫錯了的，一旦這樣的事情發生，第一種情況：引導類恰好有 foo() 函數，那么就會莫名其妙執行了引導類的 foo();第二種情況：引導類沒有 foo() 函數，但是卻甩出來引導類沒有 foo() 方法這樣的錯誤提示，用戶不知道自己哪里錯了。把 require 語句放到引導類的外面，遇到 this 或者 self，程序就會告訴用戶根本沒有類，this 或 self 無效，錯誤信息更加明朗。

第二個問題，為什么要用 hash 作為 fileIdentifier，上面的代碼明顯可以看出來這個變量是用來控制全局函數只被 require 一次的，那為什么不用 require_once 呢？事實上require_once 比 require 效率低很多，使用全局變量 GLOBALS 這樣控制加載會更快。

但是其實也帶來了一些問題，如果存在兩個自動加載，而且全局函數的相對路徑不一致，很容易造成 hash 不相同，但是文件相同的情況，導致重復定義函數。所以在使用 composer 的時候最好要統一自動加載和依賴機制，最好不要多重自動加載。

運行

我們終于來到了核心的核心——composer 自動加載的真相，命名空間如何通過 composer 轉為對應目錄文件的奧秘就在這一章。
前面說過，ClassLoader的register() 函數將 loadClass() 函數注冊到 PHP 的 SPL 函數堆棧中，每當 PHP 遇到不認識的命名空間時就會調用函數堆棧的每個函數，直到加載命名空間成功。所以 loadClass() 函數就是自動加載的關鍵了。
loadClass():

public function loadClass($class)
{
if ($file = $this->findFile($class)) {
    includeFile($file);

    return true;
}
}

public function findFile($class)
{
// work around for PHP 5.3.0 - 5.3.2 https://bugs.php.net/50731
if ("" == $class[0]) {
    $class = substr($class, 1);
}

// class map lookup
if (isset($this->classMap[$class])) {
    return $this->classMap[$class];
}
if ($this->classMapAuthoritative) {
    return false;
}

$file = $this->findFileWithExtension($class, ".php");

// Search for Hack files if we are running on HHVM
if ($file === null && defined("HHVM_VERSION")) {
    $file = $this->findFileWithExtension($class, ".hh");
}

if ($file === null) {
    // Remember that this class does not exist.
    return $this->classMap[$class] = false;
}

return $file;
}

我們看到 loadClass()，主要調用 findFile() 函數。findFile() 在解析命名空間的時候主要分為兩部分：classMap 和 findFileWithExtension() 函數。classMap 很簡單，直接看命名空間是否在映射數組中即可。麻煩的是 findFileWithExtension() 函數，這個函數包含了 PSR0 和 PSR4 標準的實現。還有個值得我們注意的是查找路徑成功后 includeFile() 仍然類外面的函數，并不是 ClassLoader 的成員函數，原理跟上面一樣，防止有用戶寫 $this 或 self。還有就是如果命名空間是以開頭的，要去掉然后再匹配。
findFileWithExtension：

private function findFileWithExtension($class, $ext)
{
      // PSR-4 lookup
      $logicalPathPsr4 = strtr($class, "", DIRECTORY_SEPARATOR) . $ext;

      $first = $class[0];
      if (isset($this->prefixLengthsPsr4[$first])) {
          foreach ($this->prefixLengthsPsr4[$first] as $prefix => $length) {
              if (0 === strpos($class, $prefix)) {
                  foreach ($this->prefixDirsPsr4[$prefix] as $dir) {
                      if (file_exists($file = $dir . DIRECTORY_SEPARATOR . substr($logicalPathPsr4, $length))) {
                          return $file;
                      }
                  }
              }
          }
      }

      // PSR-4 fallback dirs
      foreach ($this->fallbackDirsPsr4 as $dir) {
          if (file_exists($file = $dir . DIRECTORY_SEPARATOR . $logicalPathPsr4)) {
              return $file;
          }
      }

      // PSR-0 lookup
      if (false !== $pos = strrpos($class, "")) {
          // namespaced class name
          $logicalPathPsr0 = substr($logicalPathPsr4, 0, $pos + 1)
                . strtr(substr($logicalPathPsr4, $pos + 1), "_", DIRECTORY_SEPARATOR);
      } else {
          // PEAR-like class name
          $logicalPathPsr0 = strtr($class, "_", DIRECTORY_SEPARATOR) . $ext;
      }

      if (isset($this->prefixesPsr0[$first])) {
          foreach ($this->prefixesPsr0[$first] as $prefix => $dirs) {
              if (0 === strpos($class, $prefix)) {
                  foreach ($dirs as $dir) {
                      if (file_exists($file = $dir . DIRECTORY_SEPARATOR . $logicalPathPsr0)) {
                          return $file;
                      }
                  }
              }
          }
      }

      // PSR-0 fallback dirs
      foreach ($this->fallbackDirsPsr0 as $dir) {
          if (file_exists($file = $dir . DIRECTORY_SEPARATOR . $logicalPathPsr0)) {
              return $file;
          }
      }

      // PSR-0 include paths.
      if ($this->useIncludePath && $file = stream_resolve_include_path($logicalPathPsr0)) {
          return $file;
      }
}

下面我們通過舉例來說下上面代碼的流程：
如果我們在代碼中寫下 "phpDocumentorReflectionexample"，PHP 會通過 SPL 調用 loadClass->findFile->findFileWithExtension。首先默認用 php 作為文件后綴名調用 findFileWithExtension 函數里，利用 PSR4 標準嘗試解析目錄文件，如果文件不存在則繼續用 PSR0 標準解析，如果解析出來的目錄文件仍然不存在，但是環境是 HHVM 虛擬機，繼續用后綴名為 hh 再次調用 findFileWithExtension 函數，如果不存在，說明此命名空間無法加載，放到 classMap 中設為 false，以便以后更快地加載。
對于 phpDocumentorReflectionexample，當嘗試利用 PSR4 標準映射目錄時，步驟如下：

PSR4 標準加載

將轉為文件分隔符 /，加上后綴 php 或 hh，得到 $logicalPathPsr4 即 phpDocumentor//Reflection//example.php(hh);

利用命名空間第一個字母 p 作為前綴索引搜索 prefixLengthsPsr4 數組，查到下面這個數組：

p" => 
    array (
       "phpDocumentorReflection" => 25,
       "phpDocumentorFake" => 19,
    )

遍歷這個數組，得到兩個頂層命名空間 phpDocumentorReflection 和 phpDocumentorFake

用這兩個頂層命名空間與 phpDocumentorReflectionexample_e 相比較，可以得到 phpDocumentorReflection 這個頂層命名空間

在 prefixLengthsPsr4 映射數組中得到 phpDocumentorReflection 長度為25。

在 prefixDirsPsr4 映射數組中得到 phpDocumentorReflection 的目錄映射為：

"phpDocumentorReflection" => 
    array (
        0 => __DIR__ . "/.." . "/phpdocumentor/reflection-common/src",
        1 => __DIR__ . "/.." . "/phpdocumentor/type-resolver/src",
        2 => __DIR__ . "/.." . "/phpdocumentor/reflection-docblock/src",
),

遍歷這個映射數組，得到三個目錄映射；

查看 “目錄+文件分隔符 //+substr($logicalPathPsr4, $length)” 文件是否存在，存在即返回。這里就是 "__DIR__/../phpdocumentor/reflection-common/src + /+ substr(phpDocumentor/Reflection/example_e.php(hh),25)"

如果失敗，則利用 fallbackDirsPsr4 數組里面的目錄繼續判斷是否存在文件，具體方法是“目錄+文件分隔符//+$logicalPathPsr4”

PSR0 標準加載

如果 PSR4 標準加載失敗，則要進行 PSR0 標準加載：

找到 phpDocumentorReflectionexample_e 最后“”的位置，將其后面文件名中’‘_’‘字符轉為文件分隔符“/”,得到 logicalPathPsr0 即 phpDocumentor/Reflection/example/e.php(hh)
利用命名空間第一個字母 p 作為前綴索引搜索 prefixLengthsPsr4 數組，查到下面這個數組：

    "P" => 
        array (
            "Prophecy" => 
            array (
                0 => __DIR__ . "/.." . "/phpspec/prophecy/src",
            ),
            "phpDocumentor" => 
            array (
                0 => __DIR__ . "/.." . "/erusev/parsedown",
            ),
        ),

遍歷這個數組，得到兩個頂層命名空間phpDocumentor和Prophecy

用這兩個頂層命名空間與 phpDocumentorReflectionexample_e 相比較，可以得到 phpDocumentor 這個頂層命名空間

在映射數組中得到 phpDocumentor 目錄映射為 "_DIR_ . "/.." . "/erusev/parsedown"

查看 “目錄+文件分隔符//+logicalPathPsr0”文件是否存在，存在即返回。這里就是
“_DIR_ . "/.." . "/erusev/parsedown + //+ phpDocumentor//Reflection//example/e.php(hh)”

如果失敗，則利用 fallbackDirsPsr0 數組里面的目錄繼續判斷是否存在文件，具體方法是“目錄+文件分隔符//+logicalPathPsr0”

如果仍然找不到，則利用 stream_resolve_include_path()，在當前 include 目錄尋找該文件，如果找到返回絕對路徑。

結語

經過三篇文章，終于寫完了 PHP Composer 自動加載的原理與實現，結下來我們開始講解 laravel 框架下的門面 Facade,這個門面功能和自動加載有著一些聯系.

GPU云服務器云服務器 Flutter的搭建與運行主要更新了工具鏈、運行時和庫的實現棧的實現與應用回調的原理、實現與應用

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/22927.html

Composer的Autoload源碼實現——啟動與初始化

摘要：任務是加載類的初始化頂級命名空間與文件路徑映射初始化和注冊。在實際情況下可能會出現這樣的情況。值得注意的是這個函數返回的是一個匿名函數，為什么呢原因就是類中的等等都是的。。。關于匿名函數的綁定功能。前言在開始之前，歡迎關注我自己的博客：www.leoyang90.cn 上一篇文章，我們討論了 PHP 的自動加載原理、PHP 的命名空間、PHP 的 PSR0 與 PSR4 標準，有...

MarvinZhang 2019-06-27 16:27 評論0 收藏0
thinkphp源碼分析（三）—自動加載篇（Loader的分析）

摘要：源碼分析自動加載系統會調用方法注冊自動加載，在這一步完成后，所有符合規范的類庫包括依賴加載的第三方類庫都將自動加載。是通過加載對應的文件進行注冊加載的。源碼分析自動加載系統會調用 Loader::register()方法注冊自動加載，在這一步完成后，所有符合規范的類庫（包括Composer依賴加載的第三方類庫）都將自動加載。系統的自動加載由下面主要部分組成： 1. 注冊系統的自...

Pandaaa 2019-07-01 11:22 評論0 收藏0
Symfony2.8 源碼分析之類的加載

摘要：今天來寫寫這個框架的類加載機制版本原理在項目啟動時，通過注冊了要使用的類的自動加載處理方法，在類第一次被使用的時候，類文件通過該方法被引入，然后類才得以使用源碼分析在的入口文件，我們找到我們隨著這個路徑我們找打了這個主要內容如下其中是為了注今天來寫寫Symfony2.8 這個框架的類加載機制版本 Symfony 2.8 原理在項目啟動時，Symfony 通過spl_autoloa...

Blackjun 2019-06-27 14:06 評論0 收藏0
ThinkPHP5.1 源碼淺析（二）自動加載機制

摘要：如果遍歷后沒有找到，則加載失敗。在之后碰到了之后直接拿來用，提高系統自動加載的性能。這里我們就講完了注冊自動加載。使用自動加載我們在中定義了我們自動加載函數式方法。繼生命周期的第二篇，大家盡可放心，不會隨便鴿文章的第一篇中，我們提到了入口腳本，也說了，里面注冊了自動加載的功能本文默認你有自動加載和命名空間的基礎。如果沒有請看此篇文章 php 類的自動加載與命名空間自動加載...

mudiyouyou 2019-07-01 12:49 評論0 收藏0
解讀 thinkphp5 源碼（一）：自動加載

摘要：索性讀一下它的源碼。行載入類載入類，這個類比較重要，實現了自動加載。注冊錯誤和異常處理機制加載慣例配置文件接下來我們看一下自動加載的實現方法。所以借助此函數可以達到自動加載。博客鏈接解讀源碼一自動加載聽說 TP5 已經 RC4 了，曾經在 RC3 的時候用它寫過一個小東西。官方說從 RC4 以后改動不是太大。索性讀一下它的源碼。然后順便記錄一下，如有錯漏，請路過大神多多指正！入口 ...

stormzhang 2019-07-01 12:16 評論0 收藏0