__autoload實作自動載入;但由於多類別函式庫的引入,__autoload維護會複雜,則引入spl_aotoload,spl實作了一個自動載入函數清單的手動註冊和移除,下面我們就來看一看具體的內容。
PHP在魔術函數__autoload()方法出現以前,如果你要在一個程式檔案中實例化100個對象,那麼你必須用include或require包含進來100個類別文件,或者你把這100個類別定義在同一個類別檔案中-相信這個檔案一定會非常大。但是__autoload()方法出來了,以後就不必為此大傷腦筋了,這個類別會在你實例化物件之前自動載入製定的檔案。
在使用PHP的OO模式開發系統時,通常大家習慣上將每個類別的實作存放在一個單獨的檔案裡,這樣會很容易實作對類別進行複用,同時將來維護時也很便利。這也是OO設計的基本想法之一。在PHP5之前,如果需要使用一個類,只需要直接使用include/require將其包含進來即可。以下是一個實際的範例:
/* Person.class.php */ <?php class Person { var $name, $age; function __construct ($name, $age) { $this->name = $name; $this->age = $age; } } ?> /* no_autoload.php */ <?php require_once (”Person.class.php”); $person = new Person(”Altair”, 6); var_dump ($person); ?>
在這個範例中,no-autoload.php檔案需要使用Person類,它使用了require_once將其包含,然後就可以直接使用Person類別來實例化一個對象。
但隨著專案規模的不斷擴大,使用這種方式會帶來一些隱含的問題:如果一個PHP檔案需要使用很多其它類,那麼就需要很多的require/include語句,這樣有可能會造成遺漏或包含進不必要的類別文件。如果大量的文件都需要使用其它的類,那麼要保證每個文件都包含正確的類文件肯定是一個噩夢。
PHP5為這個問題提供了一個解決方案,這就是類別的自動裝載(autoload)機制。 autoload機制可以使得PHP程式有可能在使用類別時才自動包含類別文件,而不是一開始就將所有的類別文件include進來,這種機制也稱為lazy loading。
下面是使用autoload機制載入Person類別的例子:
/* autoload.php */ <?php function __autoload($classname) { $classpath="./".$classname.'.class.php'; if(file_exists($classpath)) { require_once($classpath); } else { echo 'class file'.$classpath.'not found!'; } } $person = new Person(”Altair”, 6); var_dump ($person); ?>
通常PHP5在使用一個類別時,如果發現這個類別沒有加載,就會自動執行__autoload()函數,在這個函數中我們可以載入需要使用的類別。在我們這個簡單的範例中,我們直接將類別名稱加上副檔名”.class.php」構成了類別檔案名,然後使用require_once將其載入。從這個例子中,我們可以看出autoload至少要做三件事情,第一件事是根據類別名稱確定類別檔案名,第二件事是確定類別檔案所在的磁碟路徑(在我們的例子是最簡單的情況,類別與呼叫它們的PHP程式檔案在同一個資料夾下),第三件事是將類別從磁碟檔案載入到系統中。 第三步最簡單,只需要使用include/require即可。要實現第一步,第二步的功能,必須在開發時約定類別名稱與磁碟檔案的映射方法,只有這樣我們才能根據類別名稱找到它對應的磁碟檔案。
因此,當有大量的類別檔案要包含的時候,我們只要確定對應的規則,然後在__autoload()函數中,將類別名稱與實際的磁碟檔案對應起來,就可以實作lazy loading的效果。從這裡我們也可以看出__autoload()函數的實作中最重要的是類別名稱與實際的磁碟檔案映射規則的實作。
但現在問題來了,如果在一個系統的實作中,如果需要使用很多其它的類別庫,這些類別庫可能是由不同的開發人員編寫的,其類別名稱與實際的磁碟文件的映射規則不盡相同。這時如果要實現類別庫檔案的自動加載,就必須在__autoload()函數中將所有的映射規則全部實現,這樣的話__autoload()函數有可能會非常複雜,甚至無法實現。最後可能會導致__autoload()函數十分臃腫,這時即便能夠實現,也會對將來的維護和系統效率帶來很大的負面影響。在這種情況下,難道就沒有更簡單、清楚的解決方法了吧?答案當然是:NO! 在看進一步的解決方法之前,我們先來看看PHP中的autoload機制是如何實現的。
我們知道,PHP檔案的執行分成兩個獨立的過程,第一步就是將PHP檔案編譯成普通稱為OPCODE的字節碼序列(實際上是編譯成一個叫做zend_op_array的位元組數組),第二步是由一個虛擬機器來執行這些OPCODE。 PHP的所有行為都是由這些OPCODE來實現的。因此,為了研究PHP中autoload的實作機制,我們將autoload.php檔案編譯成opcode,然後根據這些OPCODE來研究PHP在這過程中都做了些什麼:
/* autoload.php 编译后的OPCODE列表,是使用作者开发的OPDUMP工具 * 生成的结果,可以到网站 http://www.phpinternals.com/ 下载该软件。 */ 1: <?php 2: // require_once (”Person.php”); 3: 4: function __autoload ($classname) { 0 NOP 0 RECV 1 5: if (!class_exists($classname)) { 1 SEND_VAR !0 2 DO_FCALL ‘class_exists’ [extval:1] 3 BOOL_NOT $0 =>RES[~1] 4 JMPZ ~1, ->8 6: require_once ($classname. “.class.php”); 5 CONCAT !0, ‘.class.php’ =>RES[~2] 6 INCLUDE_OR_EVAL ~2, REQUIRE_ONCE 7: } 7 JMP ->8 8: } 8 RETURN null 9: 10: $p = new Person(’Fred’, 35); 1 FETCH_CLASS ‘Person’ =>RES[:0] 2 NEW :0 =>RES[$1] 3 SEND_VAL ‘Fred’ 4 SEND_VAL 35 5 DO_FCALL_BY_NAME [extval:2] 6 ASSIGN !0, $1 11: 12: var_dump ($p); 7 SEND_VAR !0 8 DO_FCALL ‘var_dump’ [extval:1] 13: ?>
在autoload.php的第10行代码中我们需要为类Person实例化一个对象。因此autoload机制一定会在该行编译后的opcode中有所体现。从上面的第10行代码生成的OPCODE中我们知道,在实例化对象Person时,首先要执行FETCH_CLASS指令。我们就从PHP对FETCH_CLASS指令的处理过程开始我们的探索之旅。
通过查阅PHP的源代码(我使用的是PHP 5.3alpha2版本)可以发现如下的调用序列:
ZEND_VM_HANDLER(109, ZEND_FETCH_CLASS, …) (zend_vm_def.h 1864行) => zend_fetch_class (zend_execute_API.c 1434行) =>zend_lookup_class_ex (zend_execute_API.c 964行) => zend_call_function(&fcall_info, &fcall_cache) (zend_execute_API.c 1040行)
在最后一步的调用之前,我们先看一下调用时的关键参数:
/* 设置autoload_function变量值为”__autoload” */ fcall_info.function_name = &autoload_function; // Ooops, 终于发现”__autoload”了 … fcall_cache.function_handler = EG(autoload_func); // autoload_func !
zend_call_function是Zend Engine中最重要的函数之一,其主要功能是执行用户在PHP程序中自定义的函数或者PHP本身的库函数。zend_call_function有两个重要的指针形参数fcall_info, fcall_cache,它们分别指向两个重要的结构,一个是zend_fcall_info, 另一个是zend_fcall_info_cache。zend_call_function主要工作流程如下:如果fcall_cache.function_handler指针为NULL,则尝试查找函数名为fcall_info.function_name的函数,如果存在的话,则执行之;如果fcall_cache.function_handler不为NULL,则直接执行fcall_cache.function_handler指向的函数。
现在我们清楚了,PHP在实例化一个对象时(实际上在实现接口,使用类常数或类中的静态变量,调用类中的静态方法时都会如此),首先会在系统中查找该类(或接口)是否存在,如果不存在的话就尝试使用autoload机制来加载该类。而autoload机制的主要执行过程为:
检查执行器全局变量函数指针autoload_func是否为NULL。
如果autoload_func==NULL, 则查找系统中是否定义有__autoload()函数,如果没有,则报告错误并退出。
如果定义了__autoload()函数,则执行__autoload()尝试加载类,并返回加载结果。
如果autoload_func不为NULL,则直接执行autoload_func指针指向的函数用来加载类。注意此时并不检查__autoload()函数是否定义。
真相终于大白,PHP提供了两种方法来实现自动装载机制,一种我们前面已经提到过,是使用用户定义的__autoload()函数,这通常在PHP源程序中来实现;另外一种就是设计一个函数,将autoload_func指针指向它,这通常使用C语言在PHP扩展中实现。如果既实现了__autoload()函数,又实现了autoload_func(将autoload_func指向某一PHP函数),那么只执行autoload_func函数。
SPL是Standard PHP Library(标准PHP库)的缩写。它是PHP5引入的一个扩展库,其主要功能包括autoload机制的实现及包括各种Iterator接口或类。SPL autoload机制的实现是通过将函数指针autoload_func指向自己实现的具有自动装载功能的函数来实现的。SPL有两个不同的函数spl_autoload, spl_autoload_call,通过将autoload_func指向这两个不同的函数地址来实现不同的自动加载机制。
spl_autoload是SPL实现的默认的自动加载函数,它的功能比较简单。它可以接收两个参数,第一个参数是$class_name,表示类名,第二个参数$file_extensions是可选的,表示类文件的扩展名,可以在$file_extensions中指定多个扩展名,护展名之间用分号隔开即可;如果不指定的话,它将使用默认的扩展名.inc或.php。spl_autoload首先将$class_name变为小写,然后在所有的include path中搜索$class_name.inc或$class_name.php文件(如果不指定$file_extensions参数的话),如果找到,就加载该类文件。你可以手动使用spl_autoload(”Person”, “.class.php”)来加载Person类。实际上,它跟require/include差不多,不同的它可以指定多个扩展名。
怎样让spl_autoload自动起作用呢,也就是将autoload_func指向spl_autoload?答案是使用spl_autoload_register函数。在PHP脚本中第一次调用spl_autoload_register()时不使用任何参数,就可以将autoload_func指向spl_autoload。
通过上面的说明我们知道,spl_autoload的功能比较简单,而且它是在SPL扩展中实现的,我们无法扩充它的功能。如果想实现自己的更灵活的自动加载机制怎么办呢?这时,spl_autoload_call函数闪亮登场了。
我們先來看看spl_autoload_call的實作有何奇妙之處。在SPL模組內部,有一個全域變數autoload_functions,它本質上是一個HashTable,不過我們可以將其簡單的看作一個鍊錶,鍊錶中的每一個元素都是一個函數指標,指向一個具有自動載入類別功能的函數。 spl_autoload_call本身的實作很簡單,只是簡單的按順序執行這個鍊錶中每個函數,在每個函數執行完成後都判斷一次需要的類別是否已經加載,如果加載成功就直接返回,不再繼續執行鍊錶中的其它函數。如果這個鍊錶中所有的函數都執行完成後類別還沒有加載,spl_autoload_call就直接退出,並且不會向使用者報告錯誤。因此,使用了autoload機制,並不能保證類別就一定能正確的自動加載,關鍵還是要看你的自動加載函數如何實現。
那麼自動載入函數鍊錶autoload_functions是誰來維護呢?就是前面提到的spl_autoload_register函數。它可以將使用者定義的自動載入函數註冊到這個鍊錶中,並將autoload_func函數指標指向spl_autoload_call函數(注意有一種情況例外,具體是哪種情況留給大家思考)。我們也可以透過spl_autoload_unregister函數將已經註冊的函數從autoload_functions鍊錶中刪除。
上節說過,當autoload_func指標非空時,就不會自動執行__autoload()函數了,現在autoload_func已經指向了spl_autoload_call,如果我們還想讓__autoload()函數起作用應該怎麼辦呢?當然還是使用spl_autoload_register(__autoload)呼叫將它註冊到autoload_functions鍊錶中。
現在回到第一節最後的問題,我們有了解決方案:根據每個類別庫不同的命名機制實現各自的自動載入函數,然後使用spl_autoload_register分別將其註冊到SPL自動載入函數隊列中就可了。這樣我們就不用維護一個非常複雜的__autoload函數了。
使用autoload機制時,很多人的第一個反應就是使用autoload會降低系統效率,甚至有人乾脆提議為了效率不要使用autoload。在我們了解了autoload實現的原理後,我們知道autoload機製本身並不是影響系統效率的原因,甚至它還有可能提高系統效率,因為它不會將不需要的類別載入到系統中。
那麼為什麼很多人都有一個使用autoload會降低系統效率的印象呢?實際上,影響autoload機製效率本身恰恰是使用者設計的自動載入函數。如果它不能有效率的將類別名稱與實際的磁碟檔案(注意,這裡指實際的磁碟文件,而不僅僅是檔案名稱)對應起來,系統將不得不做大量的檔案是否存在(需要在每個include path中包含的路徑中去尋找)的判斷,而判斷檔案是否存在需要做磁碟I/O操作,眾所周知磁碟I/O操作的效率很低,因此這才是使得autoload機制效率降低的罪魁禍首!
因此,當我們在系統設計時,我們需要定義一套清晰的將類別名稱與實際磁碟檔案對應的機制。這個規則越簡單越明確,autoload機制的效率就越高。
結論:autoload機制並不是天然的效率低下,只有濫用autoload,設計不好的自動裝載函數才會導致其效率的降低。
相關建議:
PHP之autoload運行機制實例分析,autoload實例分析
以上是php中autoload機制的詳細分析的詳細內容。更多資訊請關注PHP中文網其他相關文章!