iOS随手记

这部分原本是我笔记本里的内容，现在把有自己观点的部分搬上来：

(1) 为什么在WWDC的Protocol-Oriented Programming in Swift中提到有self-requirement泛型protocol的数组[T]必须是A homogeneous array？
（即假设Ordered协议有self-requirement时
func f(array: [Ordered])是违法的，必须换为
func f<T: Ordered>(array: [T])）

其实有self-requirement的数组的类型必须是该类而不能是父类或者实现的协议，不然编译器该怎么知道self-requirement里那个Self该是哪个类呢~

(2) Layer 和 View 的区别

Layers do not handle events, draw content, participate in the responder chain, or do many other things.

You can change the type of layer used by an iOS view by overriding the view’s layerClass method and returning a different class object. Most iOS views create a CALayer object and use that layer as the backing store for its content. For most of your own views, this default choice is a good one and you should not need to change it. But you might find that a different layer class is more appropriate in certain situations. For example, you might want to change the layer class in the following situations:

Your view draws content using Metal or OpenGL ES, in which case you would use a CAMetalLayer or CAEAGLLayer object.
There is a specialized layer class that offers better performance.
You want to take advantage of some specialized Core Animation layer classes, such as particle emitters or replicators.
Changing the layer class of a view is very straightforward; an example is shown in Listing 2-1. All you have to do is override the layerClass method and return the class object you want to use instead. Prior to display, the view calls the layerClass method and uses the returned class to create a new layer object for itself. Once created, a view’s layer object cannot be changed.

(3) 对value type的观点：
确实非常好，但是要注意的是identity属性是value type所不能拥有的，也就意味着我们日常应用中大多数model本质上是class而不是struct，当然当它们的所有属性都不可变时可以把class转为struct提高效率（个人感觉日常应用差别应该不会很大）

(4) swift runtime 坑
所有computed prop都会被暴露给runtime，连extension里的也不能幸免。导致AutoCoding并不好用。OC的category也是这情况。

----下面都是复制的文档

iOS

RunLoop本身就是一个循环，只不过为了能停止，在外面套了一个循环，内循环一段时间就退出
The whole point of an input source is to put its associated thread to sleep until there is something to do

If you want to apply multiple animations to a layer object simultaneously, you can group them together using a CAAnimationGroup object. Using a group object simplifies the management of multiple animation objects by providing a single configuration point.

Modifying the CTM is a standard technique for drawing content in a view because it allows you to reuse paths, which potentially reduces the amount of computation required while drawing.

Flipping the CTM to align an object with the default coordinate system of UIKit does not affect the object’s shadow

By default, UIKit clears a view’s current context buffer prior to calling its drawRect: method to update that same area. If you are responding to scrolling events in your view, clearing this region repeatedly during scrolling updates can be expensive. To disable the behavior, you can change the value in the clearsContextBeforeDrawing property to NO.

Note: When modifying the transform property of your view, all transformations are performed relative to the center point of the view.

Do Not Customize Controls by Embedding Subviews

Layers do not handle events, draw content, participate in the responder chain, or do many other things.

Storyboards make the process of loading and displaying your view controller’s views very simple. UIKit automatically loads views from your storyboard file when they are needed. As part of the loading process, UIKit performs the following sequence of tasks:

1. Instantiates views using the information in your storyboard file.
2. Connects all outlets and actions.
3. Assigns the root view to the view controller’s view property.
4. Calls the view controller’s awakeFromNib method.
   When this method is called, the view controller’s trait collection is empty and views may not be in their final positions.
5. Calls the view controller’s viewDidLoad method.
   Use this method to add or remove views, modify layout constraints, and load data for your views.
   Before displaying a view controller’s views onscreen, UIKit gives you some additional chances to prepare those views before and after they are onscreen. Specifically, UIKit performs the following sequence of tasks:
6. Calls the view controller’s viewWillAppear: method to let it know that its views are about to appear onscreen.
7. Updates the layout of the views.
8. Displays the views onscreen.
9. Calls the viewDidAppear: method when the views are onscreen.
   When you add, remove, or modify the size or position of views, remember to add and remove any constraints that apply to those views. Making layout-related changes to your view hierarchy causes UIKit to mark the layout as dirty. During the next update cycle, the layout engine computes the size and position of views using the current layout constraints and applies those changes to the view hierarchy.

In the preceding example, notice that you call only the didMoveToParentViewController: method of the child. That is because the addChildViewController: method calls the child’s willMoveToParentViewController: method for you. The reason that you must call the didMoveToParentViewController: method yourself is that the method cannot be called until after you embed the child’s view into your container’s view hierarchy.

When a user touches that view, the gesture recognizer receives a message that a touch occurred before the view object does

1. Updates the trait collections of the view controller and its views, as needed; see When Do Trait and Size Changes Happen?
2. Calls the view controller’s viewWillLayoutSubviews method.
3. Calls the containerViewWillLayoutSubviews method of the current UIPresentationController object.
4. Calls the layoutSubviews method of view controller’s root view.
   The default implementation of this method computes the new layout information using the available constraints. The method then traverses the view hierarchy and calls layoutSubviews for each subview.
5. Applies the computed layout information to the views.
6. Calls the view controller’s viewDidLayoutSubviews method.
7. Calls the containerViewDidLayoutSubviews method of the current UIPresentationController object.

presentation

1. Calls the presentationControllerForPresentedViewController:presentingViewController:sourceViewController: method of the transitioning delegate to retrieve your custom presentation controller
2. Asks the transitioning delegate for the animator and interactive animator objects, if any
3. Calls your presentation controller’s presentationTransitionWillBegin method
   Your implementation of this method should add any custom views to the view hierarchy and configure the animations for those views.
4. Gets the presentedView from your presentation controller
   The view returned by this method is animated into position by the animator objects. Normally, this method returns the root view of the presented view controller. Your presentation controller can replace that view with a custom background view, as needed. If you do specify a different view, you must embed the root view of the presented view controller into your view hierarchy.
5. Performs the transition animations
   The transition animations include the main ones created by the animator objects and any animations you configured to run alongside the main animations. For information on the transition animations, see The Transition Animation Sequence.
   During the animation process, UIKit calls the containerViewWillLayoutSubviews and containerViewDidLayoutSubviews methods of your presentation controller so that you can adjust the layout of your custom views as needed.
6. Calls the presentationTransitionDidEnd: method when the transition animations finish

Transition

1. UIKit calls the transitioning delegate’s interactionControllerForPresentation: method to see if an interactive animator object is available. If that method returns nil, UIKit performs the animations without user interactions.
2. UIKit calls the transitionDuration: method of the animator object to get the animation duration.
3. UIKit calls the appropriate method to start the animations:

   •   For non-interactive animations, UIKit calls the animateTransition: method of the animator object. 
     

   •   For interactive animations, UIKit calls the startInteractiveTransition: method of the interactive animator object. 
     

4. UIKit waits for an animator object to call the completeTransition: method of the context transitioning object.
   Your custom animator calls this method after its animations finish, typically in the animation’s completion block. Calling this method ends the transition and lets UIKit know that it can call the completion handler of the presentViewController:animated:completion: method and call the animator object’s own animationEnded: method.

————
If you delay the start of an animation, you might also want to set the fillMode property to kCAFillModeBackwards. This fill mode causes the layer to display the animation’s start value, even if the layer object in the layer tree contains a different value. Without this fill mode, you would see a jump to the final value before the animation starts executing. Other fill modes are available too.