laravel中facade serviceprovider的理解

一个serviceprovider就是一个解决某个功能的公用模块，实际上可以直接用在di里注册然后从di中取出，为啥还要搞个facade呢？
有几个方面的原因
1、把实例化移入到serviceprovider，自己负责自己的初始化，这样简化代码，di注册的地方更加简洁

class SomeServiceProvider extends ServiceProvider {

  public function register() {

      $this->app->bind('some', new Some());

  }

}

在register里直接实例化对象

2、使用facade可以方便更换serviceprovider，只要它们提供的方法一致。
比如我们有个日志服务，如采用facade的方式，那么当觉得这个日志服务性能不够好时，想更换更好的日志服务，直接在getFacadeAccessor里更换对应的服务类名即可，而不用大改项目里的代码
如redis的Facade

protected static function getFacadeAccessor()
    {
        return 'redis';
    }

3、方便调用函数，可以直接用静态方法调用，因为facade实际调用的是serviceprovider对象

这是facade的中__callStatic函数，可见实际是调用serviceprovider实例

 /**
     * Handle dynamic, static calls to the object.
     *
     * @param  string  $method
     * @param  array   $args
     * @return mixed
     */
    public static function __callStatic($method, $args)
    {
        $instance = static::getFacadeRoot();

        if (! $instance) {
            throw new RuntimeException('A facade root has not been set.');
        }

        switch (count($args)) {
            case 0:
                return $instance->$method();

            case 1:
                return $instance->$method($args[0]);

            case 2:
                return $instance->$method($args[0], $args[1]);

            case 3:
                return $instance->$method($args[0], $args[1], $args[2]);

            case 4:
                return $instance->$method($args[0], $args[1], $args[2], $args[3]);

            default:
                return call_user_func_array([$instance, $method], $args);
        }
    }
    

有一利则有一弊，调用嵌套太多，理解起来复杂，而且我觉得速度上也会减慢，当然现在的大型网站速度瓶颈都在数据库io上，这点效率损失还是可以接受的。

4、调用流程为Facade--> serviceprovider --
Facade会加载serviceprovider 实例化register 返回的对象 SomeObject
调用时SomeCalss::method，会Facade::__callStatic ，即 object->menthod
facade 相当于把di调用的di->get("some")->method()简化了
serviceprovider 则相当于简化di的配置 ，即di->add(someComeponent,config)
会读取config目录下的所有