Explain it to me clearly. We already have CALayer, why do we need UIView?

[[147557]]

"Please explain it to me clearly. Since we already have CALayer, why do we still need UIView?" Are you stunned when you hear this kind of question?

[[147558]]

WTF! What a mess of questions. UIView inherits from UIResponder, and its main feature is that it can respond to touch events. CALayer actually manages layer content. They do different things, and they are two different things. It is natural that they do not affect each other.

But think about it carefully, is it really a BBK reading machine, so easy? When you carefully consider the intention behind it, you will find OMG!!!

[[147559]]

UILayer

What if UIKit was not created by Apple but by us? Yes, UIView and CALayer might be combined into something called "UILayer". This UILayer is an all-powerful layer that can manage display content and handle touch events. Cool, right?

[[147560]]

OK! Let’s say UILayer has been awesome for a long time, it’s been around since iOS 2, how clever of them to design it awesome from the beginning.

Now, your product manager comes over with a smile. You need to add gesture recognition in iOS 3.2. This is easy to do. Just change the UILayer and add a gesture recognition.

Your product manager comes over again and pats you on the shoulder. He really trusts you, doesn't he? Since iOS 4 introduces the Block syntax, why not add a Block version to the previous animation? You think it's easy, just modify the source code of UILayer.

Your product manager comes over again, and he brings two product girls with him. They surround you. They are all popular people in the company, and you are trusted by everyone. You are a little shy.

[[147561]]

This time, you are asked to add a Big Feature called AutoLayout to iOS6. This is really a big feature, and it requires many changes, which also brings a lot of difficulties to testing. Now the UILayer class has become larger and larger, and its functions are so powerful that it will cost you 3000 lives. The release cannot be delayed. This is such an important class, and you have to be worthy of the girl's affectionate expectations for you, so you have to modify it carefully. In the end, you still got it done, haha, you are the outstanding employee at the end of the year.

Your product manager comes over again, hugs your neck, tells you jokes, and invites you to dinner. Oh, the product girl is still praising you behind you. Yes, it is a historic moment again. iOS has ushered in the seventh major version with a facelift. iOS7 has become fresher, and physical effects and even parallax have been added. The product manager is trying to subvert the product design concept and change the world again. It is really amazing. Then, you click on the huge UILayer class. It seems that you have to change it from beginning to end, but there is limited time to change so many things. It seems that there is not enough time to test after the changes. What should I do? Refactoring is even more impossible. The annual release cannot be postponed, otherwise how can the company save face in front of the whole world. But time waits for no one. Even if the programmer encourager encourages you every day, it can't save you. You can't control the code. At the historical juncture of iOS7, your myth fell.

[[147562]]

analyze

Therefore, behind this SDK, there are decades of design wisdom from the experts. You can see a lot of tricks in it. This time, we can analyze UIView and CALayer to get some conclusions.

• Separation of mechanism and strategy
• More immutable
• Each one has his own job
• Less leakage

Separation of mechanism and strategy

One of the main ideas in the design of the Unix kernel is to provide mechanisms rather than policies. Programming problems can be separated into mechanisms and policies. Once a mechanism is implemented, it will rarely change, but the policy will be frequently optimized. For example, atoms can be regarded as mechanisms, and the composition of various atoms is a policy. CALayer can also be regarded as a mechanism that provides layer drawing. You can open the header file of CALayer and see that it has basically not changed much, while UIView can be regarded as a policy that has changed a lot. The lower the level, the more mechanism, and the more stable the mechanism. Separating the mechanism from the policy can reduce the code that needs to be modified, especially the underlying code, which can improve the stability of the system.

More immutable

What does stability feel like to you? Solid? Unchangeable? Stability is actually immutability. The more immutable things a system has, the more stable it is. So the mechanism is just to satisfy this immutability factor. One guiding principle of building a system is to separate immutable things from mutable things as much as possible. Water cannot build a towering building, only solid concrete can. Fewer modifications means fewer chances of bugs.

Each one has his own job

Even if you have great abilities, you cannot do everything. What if one day you are no longer capable? Suddenly, you can't do anything. Therefore, just based on the principle of risk diversification, there should not be an all-rounder. Everyone should perform their duties, cooperate with each other, and reduce the controllable granularity to the minimum. This can also make the system more stable and easier to modify.

Less leakage

The interface should be open to the public. According to the 80/20 principle, 20% of the interface can meet 80% of the needs, and the remaining 80% should be hidden behind. Because less leakage is always safe, right? The remaining 80% of the expert interface can be hidden in depth. For example, UIView covers most of the CALayer interface, extracting and constructing a more user-friendly frame and animation implementation, which makes it easier to get started.

END