iOS face questions

1. What is the difference between using the weak keyword and comparing assign?

(1) What is the use of weak keywords?

<a> in Arc, when a circular reference is possible, it is often done by letting one end use weak, such as the delegate proxy property.

<b> has already made a strong reference to it, there is no need to strongly reference it again, weak is used, and custom Iboutlet control properties generally use weak.

　　(2) different points:

<a> weak This trait indicates that the attribute defines a "non-owning relationship" (nonowning relationship). When you set a new value for this property, the set (getter) method neither preserves the new value nor releases the old value. This trait is similar to assign, but the attribute value is also emptied (nil out) when the object referred to by the attribute is destroyed. Assign's "Setup method" only performs simple assignment for the scalar type, such as CGFloat or Nslnteger.

<b> Assigin can be used with non-OC objects, while weak must be used for OC objects

2. How do I use the Copy keyword?

(1) Use:

<a> NSString, Nsarray, Nsdictionary, and so on often use the Copy keyword because they have a corresponding mutable type: nsmutablestring, Nsmutablearray, Nsmutabledictionary.

<b> block also often uses the Copy keyword, block using copy is the "legacy" from the MRC, in the MRC, the method inside the block is in the stack area, using copy can put it into the heap area, Writing in the arc does not write: for block using copy or strong effect is the same, but it is harmless to write copy, but also always remind us: The compiler automatically copy the block.

　　(2) The following explanation:

Copy of this trait expresses a relationship similar to strong. However, the set method does not retain the new value, but instead copies it. When the property type is nsstring, this trait is often used to protect its encapsulation, because the new value passed to the set method may point to an instance of the Nsmutablestring class. This class is a subclass of NSString, which represents a string that modifies its value, and if you do not copy the string, the value of the string may be changed without the object's knowledge when the property is set. Therefore, a copy of the "Immutable" (immutable) string is necessary to ensure that the string values in the object are not inadvertently changed. As long as the object used to implement the property is "mutable" (mutable), a copy should be made when setting the new property value.

Using @property to declare NSString, Nsarray, and nsdictionary often use the Copy keyword because they have a corresponding mutable type: nsmutablestring, Nsmutablearray, Nsmutabledictionary, they may perform assignment operations to ensure that the string values in the object are not inadvertently changed, and that a copy should be made when setting a new property value.

3. What is the problem with this notation: @property (copy) Nsmutablearray *array;

(1) Two questions:

<a> Add, delete, modify the elements in the array, the program will be unable to find the corresponding method and crashes. because copy is a copy of an immutable Nsarray object;

<b> using the Atomic property can severely affect performance.

(2) Workaround:

<a> 1th Why is the Copy keyword frequently used in nsstring (or nsarray,nsdictionary) declared with @property, and why? If you use the strong keyword, what might be causing the problem? "And how to use the Copy keyword above?" "is also discussed.

<b> 2nd reason, as follows:

This property uses a synchronous lock, which generates some extra code to help write multithreaded programs when it is created, which can result in performance problems, and by declaring nonatomic, you save these though small but without additional overhead.

By default, the method synthesized by the compiler ensures its atomicity (atomicity) through the locking mechanism. If the attribute has a nonatomic trait, no synchronization lock is used. Note that although there is no trait named "Atomic" (if a property does not have a nonatomic trait, it is "Atomic" (atomic).

In iOS development, you will find that almost all properties are declared as nonatomic.

In general, it is not required that the attribute must be "atomic" because it does not guarantee "thread-safe" safety, and a deeper locking mechanism is required to implement "thread-safe" operations. For example, when a thread reads a property value several times in a row, another thread overwrites the value at the same time, and even if the property is declared as atomic, a different property value is read.

Therefore, the Nonatomic property is generally used when developing iOS programs. However, when developing a Mac OS X program, using the atomic attribute usually does not have a performance bottleneck.

iOS face questions