CI框架源码阅读笔记4 引导文件CodeIgniter.php

     到了这里，终于进入CI框架的核心了。既然是“引导”文件，那么就是对用户的请求、参数等做相应的导向，让用户请求和数据流按照正确的线路各就各位。例如，用户的请求url:

   http://you.host.com/usr/reg

　 经过引导文件，实际上会交给Application中的UsrController控制器的reg方法去处理。 这之中，CodeIgniter.php做了哪些工作？我们一步步来看。

1.    导入预定义常量、框架环境初始化

　　之前的一篇博客（CI框架源码阅读笔记2 一切的入口 index.php）中，我们已经看到，Index.php文件中已经对框架的ENVIRONMENT，application,system等做了定义和安全性检查.

(1).   加载预定义常量Constants.

　　如果定义了环境，且针对该环境的预定义常量文件存在，则优先加载环境的常量定义文件，否则加载config目录下的常量定义文件：

if (defined('ENVIRONMENT') AND file_exists(APPPATH.'config/'.ENVIRONMENT.'/constants.php'))
{
    require(APPPATH.'config/'.ENVIRONMENT.'/constants.php');
}
else{
    require(APPPATH.'config/constants.php');
}

　　这么做的原因，我们之前已经介绍过了，可以快速切换环境和相应参数而不必更改应用程序核心代码。

(2).   设置自定义错误处理函数。

　　这里是_exception_handler函数，该函数的定义和解释见上一篇博客（ http://www.cnblogs.com/ohmygirl/p/CIRead-3.html）。再次引用手册中一句话，提醒大家注意：以下级别的错误不能由用户定义的函数来处理： E_ERROR、 E_PARSE、 E_CORE_ERROR、 E_CORE_WARNING、 E_COMPILE_ERROR、 E_COMPILE_WARNING，和在 调用 set_error_handler() 函数所在文件中产生的大多数 E_STRICT。

(3).   检查核心class是否被扩展

if (isset($assign_to_config['subclass_prefix']) AND $assign_to_config['subclass_prefix'] != '')
{
    get_config(array('subclass_prefix' => $assign_to_config['subclass_prefix']));
}

　　其中,$assign_to_config应该是定义在入口文件Index.php中的配置数组. 通常情况下，CI的核心组件的名称均以”CI_”开头，而如果更改了或者扩展CI的核心组件，则应该使用不同的subclass_prefix前缀如MY_ ,这种情况下，应该通过$assign_to_config[‘subclass_prefix’]指定你的扩展核心的前缀名，便于CI的Loader组件加载该类，或者可能出现找不到文件的错误。另外，subclass_prefix配置项默认是位于APPPATH/Config/config.php配置文件中的，这段代码同样告诉我们，index.php文件中的subclass_prefix具有更高的优先权（也就是，如果两处都设置了subclass_prefix,index.php中的配置项会覆盖配置文件Config.php中的配置）。

到这里，CI框架的基本环境配置初始化已经算是完成了，接下来，CodeIgniter会借助一系列的组件，完成更多的需求。

2.    加载核心组件

　　通常，CI框架中不同的功能均由不同的组件来完成（如Log组件主要用于记录日志，Input组件则用于处理用户的GET,POST等数据）这种模块化的方式使得各组件之间的耦合性较低，从而也便于扩展。CI中主要的核心组件如下所示：

 

其中：

　　BM:   指BenchMark，是CI的基准点组件，主要用于mark各种时间点、记录内存使用等参数，便于性能测试和追踪。

　　EXT:  CI的扩展组件，前面已经介绍过，用于在不改变CI核心的基础上改变或者增加系统的核心运行功能。Hook钩子允许你在系统运行的各个挂钩点（hook point）添加自定义的功能和跟踪，如pre_system，pre_controller,post_controller等预定义的挂钩点。以下所有的$EXT->_call_hook("xxx");均是call特定挂钩点的程序（如果有的话）。

　　CFG:  Config配置管理组件。主要用于加载配置文件、获取和设置配置项等。

　　UNI:  用于对UTF-8字符集处理的相关支持。其他组件如INPUT组件，需要改组件的支持。

　　URI:  解析URI（Uniform Rescource Identifier）参数等.这个组件与RTR组件关系紧密。（似乎URI与Router走到哪里都是好基友）。

　　RTR:  路由组件。通过URI组件的参数解析，决定数据流向（路由）。

　　OUT: 最终的输出管理组件，掌管着CI的最终输出（海关啊）。

　　SEC:  安全处理组件。毕竟安全问题永远是一个大问题。

　　以BM组件为例，核心组件的加载方式是：

$BM =& load_class('Benchmark', 'core');

　　调用了load_class函数获取core目录下的相应组件。（load_class的实现和具体介绍见之前的博客：CI框架源码阅读笔记3 全局函数Common.php）

各组件的功能和具体实现之后会有详细的分析， 这里我们只需要知道该组件的基本功能即可。

3.    设置路由。

调用很简单，只有一句话：

$RTR->_set_routing();

　　调用Router组件的_set_routing()函数来设置路由，具体的实现细节，我们这里暂且不管（之后的部分会有详细介绍），我们只需要知道，通过_set_routing的处理，我们可以获得实际请求的Controller，URI的segment参数段等信息。

      值得注意的是，CI允许在index.php中配置routing，且会覆盖默认的routing设置（如共享CI的安装目录的多个应用程序可能有不同的routing）：

if (isset($routing))
{
    $RTR->_set_overrides($routing