只有有一个NSURLProtocol的canInitWithRequest返回YES，那其他的protocol就不会考虑了
canInitWithRequest 不能老是返回YES,会引发很多的额外开销，以下是原文
Think again about the URL Loading System and protocol registration, and you might have a notion about why this is happening. When the UIWebView wants to load the URL, the URL Loading System asks MyURLProtocol if it can handle that specific request. Your class says YES, it can handle it.
So the URL Loading System will create an instance of your protocol and call startLoading. Your implementation then creates and fires its NSURLConnection. But this also calls the URL Loading System. Guess what? Since you’re always returning YES in the +canInitWithRequest: method, it creates another MyURLProtocol instance.
This new instance will lead to a creation of one more, and then one more and then an ifinite number of instances. That’s why you app doesn’t load anything! It just keeps allocating more memory, and shows only one URL in the console. The poor browser is stuck in an infinite loop! Your users could be frustrated to the point of inflicting damage on their devices.
另一段原文
Review what you’ve done and then move on to how you can fix it. Obviously you can’t just always return YES in the +canInitWithRequest: method. You need to have some sort of control to tell the URL Loading System to handle that request only once. The solution is in the NSURLProtocol interface. Look for the class method called +setProperty:forKey:inRequest: that allows you to add custom properties to a given URL request. This way, you can ‘tag’ it by attaching a property to it, and the browser will know if it’s already seen it before.
在appdelegate这么写后，我们发现跟视图控制器里面获取configuration，发现里面的protocolClasses还是没有变化。
难道只有在用的时候，临时添加才有效，目前来看是的？光注册是没用的，还需要再用的时候，将这个类SBLogURLProtocol加进来，这样网络请求的时候才会走