load方法虽然很酷，但一不小心就掉坑

今天上架的应用发现在iOS8.4上无法打开，在其他版本却可以，最后查来查去，却出现在load这个方法里面。
想必大家都会遇到这样的情况，AppDelegate.m里面的代码越来越多，一堆东西，看起来就不爽。我把AppDelegate里面的初始化第三方库方法抽取出来， 放到新建的ThirdPartySteup里面的load方法里面。打开应用，在初始化Bugly里的时候，卡住了，连main方法也不能进入。

原因：因为在初始化Bugly的时候，有些依赖类未能加载进来，导致卡住了。

在《Effect Objective-c》有一个小节说到load与initialize两个方法。

load

对于加入运行期系统中的每个类及分类来说，必定会调用此方法，而且仅调用一次。当包含类或分类的程序库载入系统时，就会执行此方法，而这通常就是指应用程序启动时，若程序是基于iOS程台的，则肯定会在此时执行。如果分类和其所属的类都定义了load方法，则先调用类里的，再调用分类的。

使用load方法要注意以下问题：
1、执行该方法时，运行期系统处于“脆弱状态”（fragile state）。在执行子类的load方法之前，必定会先执行所有超类的load方法，而如果代码还依赖其他程序，那么程序库里相关类的load方法也必定会先执行。然而，根据某个给定的程序库，却无法判断出其中各个类的载入顺序。因此，在load方法中使用其他类是不安全的。

2、load方法不像普通方法那样，它不遵从那套继承规则。如果某个类本身没实现load方法，那么不管其各级超类是否实现此方法，系统都不会调用。此外，分类的其所属的类里，都可能出现load方法。此时两种实现代码都会调用，类的实现要比分类的实现先执行。

3、load方法务必实现得精简一些，也就是要尽量减少其所执行操作，因为整个程序在执行load方法的时候都会阻塞。如果load方法中包含繁杂的代码，那么应用程序在执行期行就会变得无响应。也不要写等待锁，也不要调用可能会加锁的方法。总之我们少点在load做任务。在进入我们程序的main方法之前，会先调用load的方法。不妨做一个实现，在load方法调用[NSThread sleepForTimeInterval:3]，我们将会在launch界面多等待3秒种才会进入主界面。

同时发现一个小Tips：load方法调用顺序跟项目Build Phases里面Compile Source的顺序有关。

initialize

跟load方法相同，对于每个类来说，该方法会在程序首次用该类之前调用，且只调用一次。它是由运行期系统来调用，绝不应该通过代码直接调用。但是它跟load方法有个几个不同之处。

1、它是“惰性调用的”，也就是说，只有当程序用到相关的类时，才会调用。因此，如果某一个类一直没有被使用。那么其initialize方法就一直不会运行。也就是说应用程序无须把所有类的initialize都执行一遍，这与load方法不同。对于load来说，应用程序会把所有类的load方法都执行完毕才会执行程序。

2、**与load方法不同，它在运行系统在执行该方法时，是处于正常状态的。 **
因此，在运行期系统完整角度上来讲，此时也可以安全使用并调用任意类中的做生意方法。而且，运行期系统也能确保initialize方法在“线程安全的环境”中执行，这也是说，只有执行initialize的那个线程可以操作类或类实例。其他线程都要先阻塞，等着initialize执行完。

3、"initialize方法跟其他方法一样，如果某个类未实现它，而超类实现了，就会运行超类的代码"。这跟load方法不一样，它也遵循通常的继承规则。所以一般来说都会在调用的时候判断是否是当前类

     +(void)initialize{
         if(self == [XXClass class]){
                //doSomething
          }
      }

总结

总的来说，在这两个方法实现的代码尽量要精简。
可以设置一些简单的状态，不要执行那种耗时或者加锁的任务。在load方法里顾，上面已经说了整个应用在执行load方法的时候都会阻塞。而initialize也是阻塞当前线程的，如果线程碰巧是UI线程，那个就会一直阻塞。
其次，开发者无法控件类初始化的顺序，这是一个隐患，说不定某天发生了bug你都不知道是怎么回事。

参考《Effective Obejctive-C 2.0》中 第51条：精简initialize与load的实现代码