第26月第23天 nsobject 单例 CFAbsoluteTimeGetCurrent

1.nsobject 单例

 

sudo chmod 666 /Applications/Xcode.app/Contents/Frameworks/IDEKit.framework/Resources/IDETextKeyBindingSet.plist

sudo chmod 777 /Applications/Xcode.app/Contents/Frameworks/IDEKit.framework/Resources/

 

https://www.jianshu.com/p/09cfecfb1ab7

 

2.nsobject 单例

 

+(id)allocWithZone:(struct _NSZone *)zone
{
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        sharedLoginViewController = [super allocWithZone:zone];
    });
    return sharedLoginViewController;
}

 

https://www.jianshu.com/p/0772490e2c03

 

allocWithZone
首先我们知道，我们需要保证单例类只有一个唯一的实例，而平时我们在初始化一个对象的时候， [[Class alloc] init]，其实是做了两件事。 alloc 给对象分配内存空间，init是对对象的初始化，包括设置成员变量初值这些工作。而给对象分配空间，除了alloc方法之外，还有另一个方法： allocWithZone.
在NSObject 这个类的官方文档里面，allocWithZone方法介绍说，该方法的参数是被忽略的，正确的做法是传nil或者NULL参数给它。而这个方法之所以存在，是历史遗留原因。

Do not override allocWithZone: to include any initialization code. Instead, class-specific versions of init… methods.
This method exists for historical reasons; memory zones are no longer used by Objective-C.

文档里面提到，memory zone已经被弃用了，只是历史原因才保留这个接口。详细是什么历史原因我没找到，不过后面介绍的内容会稍微涉及到。
而实践证明，使用alloc方法初始化一个类的实例的时候，默认是调用了 allocWithZone 的方法。于是覆盖allocWithZone方法的原因已经很明显了：为了保持单例类实例的唯一性，需要覆盖所有会生成新的实例的方法，如果有人初始化这个单例类的时候不走[[Class alloc] init] ，而是直接 allocWithZone， 那么这个单例就不再是单例了，所以必须把这个方法也堵上。allocWithZone的答案到此算是解决了，但是，问题是无止境的。
这里引出了另外一个问题： What the hell is Memory Zone?

 

http://www.cocoachina.com/bbs/read.php?tid=116873&fpage=33 

https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/CocoaObjects.html#//apple_ref/doc/uid/TP40002974-CH4-SW32

 

https://blog.csdn.net/sbvfhp/article/details/47858469

 

3.mvc

MVC as a Compound Design Pattern

Model-View-Controller is a design pattern that is composed of several more basic design patterns. These basic patterns work together to define the functional separation and paths of communication that are characteristic of an MVC application. However, the traditional notion of MVC assigns a set of basic patterns different from those that Cocoa assigns. The difference primarily lies in the roles given to the controller and view objects of an application.

In the original (Smalltalk) conception, MVC is made up of the Composite, Strategy, and Observer patterns.

• Composite—The view objects in an application are actually a composite of nested views that work together in a coordinated fashion (that is, the view hierarchy). These display components range from a window to compound views, such as a table view, to individual views, such as buttons. User input and display can take place at any level of the composite structure.

• Strategy—A controller object implements the strategy for one or more view objects. The view object confines itself to maintaining its visual aspects, and it delegates to the controller all decisions about the application-specific meaning of the interface behavior.

• Observer—A model object keeps interested objects in an application—usually view objects—advised of changes in its state.

The traditional way the Composite, Strategy, and Observer patterns work together is depicted by Figure 4-6: The user manipulates a view at some level of the composite structure and, as a result, an event is generated. A controller object receives the event and interprets it in an application-specific way—that is, it applies a strategy. This strategy can be to request (via message) a model object to change its state or to request a view object (at some level of the composite structure) to change its behavior or appearance. The model object, in turn, notifies all objects who have registered as observers when its state changes; if the observer is a view object, it may update its appearance accordingly.

Figure 4-6  Traditional version of MVC as a compound pattern

The Cocoa version of MVC as a compound pattern has some similarities to the traditional version, and in fact it is quite possible to construct a working application based on the diagram in Figure 4-6. By using the bindings technology, you can easily create a Cocoa MVC application whose views directly observe model objects to receive notifications of state changes. However, there is a theoretical problem with this design. View objects and model objects should be the most reusable objects in an application. View objects represent the "look and feel" of an operating system and the applications that system supports; consistency in appearance and behavior is essential, and that requires highly reusable objects. Model objects by definition encapsulate the data associated with a problem domain and perform operations on that data. Design-wise, it's best to keep model and view objects separate from each other, because that enhances their reusability.

In most Cocoa applications, notifications of state changes in model objects are communicated to view objects through controller objects. Figure 4-7 shows this different configuration, which appears much cleaner despite the involvement of two more basic design patterns.

Figure 4-7  Cocoa version of MVC as a compound design pattern

 

 

 

4.

 

 

CFAbsoluteTime start = CFAbsoluteTimeGetCurrent();
// do something
 CFAbsoluteTime end = CFAbsoluteTimeGetCurrent();
 NSLog(@"time cost: %0.3f", end - start);