Composer autoload的示例分析

小編給大家分享一下Composer autoload的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

眾所周知 composer 是現代 PHP 項目的基石， 與古老的 pear 不同， composer 并不是一款專注于系統級別 php 管理的包管理系統，而是基于項目的一個庫管理系統。這就好比 npm install -g 和 npm install 的區別。而且最主要的是 pear 不太能跟上時代的潮流，在大家都在用 psr-* 的時候 pear 依然我行我素自成一體。

好吧，可能這是好事，但是也是壞事。好事是很多優秀的包都從 pear 發家致富，比如 PHP_CodeSniffer, PHP_Unit 等等。但是隨著時代的發展，php社區也漸漸地從其他社區汲取到了一些精華，慢慢地向前發展。最近的 laravel 就是直接扔進了 composer。因為 psr-4 這個規范真是不能再爽更多。這真的是我用各種包用得最順手的一套命名規范了。

扯遠了，扯回 vendor/composer/autoload_real.php 這個核心 composer 文件。

自動加載的類型

總體來說 composer 提供了幾種自動加載類型

1. classmap

2. psr-0

3. psr-4

4. files

這幾種自動加載都會用到，理論上來說，項目代碼用 psr-4 自動加載， helper 用 files 自動加載，development 相關用 classmap 自動加載。 psr-0 已經被拋棄了，不過有些歷史遺留依然在用，所以偶爾也會看到。

classmap

這應該是最最簡單的 autoload 模式了。大概的意思就是這樣的：

{
  "classmap": ["src/"]
}

然后 composer 在背后就會讀取這個文件夾中所有的文件 然后再 vendor/composer/autoload_classmap.php 中怒將所有的 class  的 namespace + classname 生成成一個 key => value 的 php 數組

<?php
return [ 
  'App\\Console\\Kernel' => $baseDir . '/app/Console/Kernel.php'
];
?>

然后就可以光明正大地用 spl_autoload_register 這個函數來怒做自動加載了。

好吧 上面的例子其實有點 tricky 就是上面這個 autoload 實際上是根據 prs-4 來生成出來的。不過這不重要，了解底層重要點，我們可以看到所有的所謂的 autoloading 其實可以理解為生成了這么一個 classmap，這是 composer dump-autoload -o 做的事兒。不然的話compoesr 會吭哧吭哧地去動態讀取 psr-4 和 prs-0 的內容。

psr-0

現在這個標準已經過時了。當初制定這個標準的時候主要是在 php 從 5.2 剛剛躍遷到 5.3+ 有了命名空間的概念。所以這個時候 psr-0 的標準主要考慮到了 <5.2 的 php 中 類似 Acme_Util_ClassName 這樣的寫法。

{
  "name": "acme/util",
  "auto" : {
    "psr-0": {
      "Acme\\Util\\": "src/"
    }
  }
}

文檔結構是這樣的

vendor/
  acme/
    util/
      composer.json
      src/
        Acme/
          Util/
            ClassName.php

ClassName.php 中是這樣的

<?php
class Acme_Util_ClassName{}
?>

我們可以看到由于舊版本的 php 沒有 namespace 所以必須通過 _ 將類區分開。

這樣稍微有點麻煩。指向一個文件夾之后 src 還要在 src 中分成好幾層文檔樹。這樣太深了。沒有辦法，但是似乎想要兼容 _ 的寫法仔細想想這是唯一的辦法了。（psr-0 要求 autoloading 的時候將 類中的 _ 轉義為 '\'）

所以在 php5.2 版本已經徹底被拋棄的今天， FIG 就怒推出了 psr-4

psr-4

這個標準出來的時候一片噴聲，大概的意思就是 FIG 都是傻逼么，剛剛出了 psr-0 然后緊跟著進推翻了自己。不過 FIG 也有自己的苦衷，幫沒有 namespace 支持的 php5.2 擦了那么久的屁股，在2014年10月21日的早晨，終于丟失了睡眠。

拋棄了 psr-0 的 composer 從此變得非常清爽。

最簡單來講就是可以把 prs-4 的 namespace 直接想想成 file structure

{
  "name": "acme/util",
  "auto" : {
    "psr-4": {
      "Acme\\Util\\": "src/"
    }
  }
}

vendor/
  acme/
    util/
      composer.json
      src/
        ClassName.php

可以看到將 Acme\Util 指向了 src 之后 psr-4 就會默認所有的 src 下面的 class 都已經有了 Acme\Util 的 基本 namespace，而 psr-4 中不會將 _ 轉義成 \ 所以就沒有必要有 psr-0 那么深得文檔結構了。

<?php
namespace Acme\Util;
class ClassName {}
?>

file

然而這還是不夠。因為可能會有一些全局的 helper function 的存在。

這個寫法很簡單就不多看了。

{
  "files": [
    "path/to/file.php"
  ]
}

autoload_real.php

好了看了所有的 autoload 類型那么直接怒看一發實現。

首先映入眼簾的就是一坨，我的是這樣的

ComposerAutoloaderInit64c47026c93126586e44d036738c0862

為啥？

因為這個類是全局的啊少年。

作為模塊化大行其道的今天，全局的類總是有那么點奇怪。為了不讓這個 autoload 的 helper 污染全局，composer 的仁兄們還是絞盡腦汁怒弄了這么一個奇怪的 hash。這直接就逼迫廣大二筆程序員們不要跟這個撞衫。

好吧，接著往下看。

主要只有這么一個方法  getLoader

<?php
// autoload_real.php @generated by Composer

class ComposerAutoloaderInit64c47026c93126586e44d036738c0862
{
    private static $loader;

    public static function loadClassLoader($class)
    {
        if ('Composer\Autoload\ClassLoader' === $class) {
            require __DIR__ . '/ClassLoader.php';
        }
    }

    public static function getLoader()
    {
        if (null !== self::$loader) {
            return self::$loader;
        }

        spl_autoload_register(array('ComposerAutoloaderInit64c47026c93126586e44d036738c0862', 'loadClassLoader'), true, true);
        self::$loader = $loader = new \Composer\Autoload\ClassLoader();
        spl_autoload_unregister(array('ComposerAutoloaderInit64c47026c93126586e44d036738c0862', 'loadClassLoader'));

        $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);

        $includeFiles = require __DIR__ . '/autoload_files.php';
        foreach ($includeFiles as $file) {
            composerRequire64c47026c93126586e44d036738c0862($file);
        }

        return $loader;
    }
}

function composerRequire64c47026c93126586e44d036738c0862($file)
{
    require $file;
}

?>

在講什么？其實很簡單。

1. 找 Composer\ClassLoader 如果不存在就是生成一個實例放在 ComposerAutoloaderInit64c47026c93126586e44d036738c0862 中

2. 然后將 composer cli 生成的各種 autoload_psr4, autoload_classmap, autoload_namespaces(psr-0) 全都注冊到 Composer\ClassLoader 中。

3. 直接 require 所有在 autoload_files 中的文件

其中 composerRequire64c47026c93126586e44d036738c0862 要解釋下。 為什么這個不直接用 require 而是定義在了類的外邊？

調查 Composer\ClassLoader 發現了這么一個注釋

Scope isolated include. Prevents access to $this/self from included files.

好吧還是怕二筆程序員犯渾。想想一下，如果有人在 autoload_files 中的文件中寫了 $this 或者 self 那就屎了。所以當require 一個file的時候我們希望解釋器能夠成功報錯。

不容易，終于快要勝利了。

為什么總是要 composer dump-autoload ?

剛開始接觸用 composer 的時候一直被這個問題蠱惑。很不理解為什么總是要打這句命令才能不報錯，現在終于知道根結了。

因為 database 文件夾使用 classmap 來做加載的。所以只有在打了 composer dumpautoload 之后 composer 才會更新 autoload_classmap 的內容。

怎樣可以避免一直打 composer dump-autoload ?

可以怒用 psr-4 注冊一個文件夾這樣增減文件就不用再管了。Composer\ClassLoader 會自動檢查 composer.json 中注冊的 psr-4 入口然后根據 psr-4 去自動查找文件。

生產環境為什么要 composer dump-atoload -o ?

因為 psr-4 自動加載會再背后跑一些邏輯。具體可以調查 Composer\ClassLoader 去看。

<?php
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 (is_file($file = $dir . DIRECTORY_SEPARATOR . substr($logicalPathPsr4, $length))) {
                        return $file;
                    }
                }
            }
        }
    }

    // PSR-4 fallback dirs
    foreach ($this->fallbackDirsPsr4 as $dir) {
        if (is_file($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 (is_file($file = $dir . DIRECTORY_SEPARATOR . $logicalPathPsr0)) {
                        return $file;
                    }
                }
            }
        }
    }

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

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

可以看到 psr-4 或者 psr-0 的自動加載都是一件很累人的事兒。基本是個 O(n2) 的復雜度。另外有一大堆 is_file 之類的 IO 操作所以性能堪憂。

所以給出的解決方案就是空間換時間。

Compsoer\ClassLoader 會優先查看 autoload_classmap 中所有生成的注冊類。如果在classmap 中沒有發現再 fallback 到 psr-4 然后 psr-0

所以當打了 composer dump-autoload -o 之后，composer 就會提前加載需要的類并提前返回。這樣大大減少了 IO 和深層次的 loop。

以上是“Composer autoload的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！