composer autoload 自動加載性能優化指南

composer 提供的 autoload 機制使得咱們組織代碼和引入新類庫很是方便，可是也使項目的性能降低了很多 。

composer autoload 慢的主要緣由在於來自對 PSR-0 和 PSR-4 的支持，加載器獲得一個類名時須要到文件系統裏查找對應的類文件位置，這致使了很大的性能損耗，固然這在咱們開發時仍是有用的，這樣咱們添加的新的類文件就能即時生效。 可是在生產模式下，咱們想要最快的找到這些類文件，並加載他們。

所以 composer 提供了幾種優化策略，下面說明下這些優化策略。

第一層級(Level-1)優化： 生成 classmap

如何運行：

執行命令 composer dump-autoload -o （-o 等同於 --optimize）

原理：

這個命令的本質是將 PSR-4/PSR-0 的規則轉化爲了 classmap 的規則， 由於 classmap 中包含了全部類名與類文件路徑的對應關係，因此加載器再也不須要到文件系統中查找文件了。能夠從 classmap 中直接找到類文件的路徑。

注意事項

建議開啓 opcache , 這樣會極大的加速類的加載。
php5.5 之後的版本中默認自帶了 opcache 。

這個命令並無考慮到當在 classmap 中找不到目標類時的狀況，當加載器找不到目標類時，仍舊會根據PSR-4/PSR-0 的規則去文件系統中查找

第二層級(Level-2/A)優化：權威的（Authoritative）classmap

執行命令：

執行命令 composer dump-autoload -a （-a 等同於 --classmap-authoritative）

原理

執行這個命令隱含的也執行了 Level-1 的命令， 即一樣也是生成了 classmap，區別在於當加載器在 classmap 中找不到目標類時，不會再去文件系統中查找（即隱含的認爲 classmap 中就是全部合法的類，不會有其餘的類了，除非法調用）

注意事項

若是你的項目在運行時會生成類，使用這個優化策略會找不到這些新生成的類。

第二層級(Level-2/B)優化：使用 APCu cache

執行命令：

執行命令 composer dump-autoload --apcu

原理：

使用這個策略須要安裝 apcu 擴展。
apcu 能夠理解爲一塊內存，而且能夠在多進程中共享。
這種策略是爲了在 Level-1 中 classmap 中找不到目標類時，將在文件系統中找到的結果存儲到共享內存中， 當下次再查找時就能夠從內存中直接返回，不用再去文件系統中再次查找。

在生產環境下，這個策略通常也會與 Level-1 一塊兒使用， 執行composer dump-autoload -o --apcu, 這樣，即便生產環境下生成了新的類，只須要文件系統中查找一次便可被緩存 ， 彌補了Level-2/A 的缺陷。

如何選擇優化策略？

要根據本身項目的實際狀況來選擇策略，若是你的項目在運行時不會生成類文件而且須要 composer 的 autoload 去加載，那麼使用 Level-2/A 便可，不然使用 Level-1 及 Level-2/B是比較好的選擇。

幾個提示

• Level-2的優化基本都是 Level-1 優化的補充，Level-2/A 主要是決定在 classmap 中找不到目標類時是否繼續找下去的問題，Level-2/B 主要是在提供了一個緩存機制，將在 classmap 中找不到時，將從文件系統中找到的文件路徑緩存起來，加速後續查找的速度。
• 在執行了 Level-2/A 時，表示在 classmap 中找不到不會繼續找，此時 Level-2/B 是不會生效的。
• 不論那種狀況都建議要開啓 opcache， 這會極大的提升類的加載速度，我目測有性能提高至少 10倍。