Different ways to implement locks in Objective-C (Part 2)

Different ways to implement locks in Objective-C (Part 2)

NSHashTable

When looking at the code of KVOController, I saw the NSHashTable class, so I sorted it out.

NSHashTable imitates NSSet (NSMutableSet), but provides more operation options than NSSet, especially in the support of weak reference relationships. NSHashTable is more flexible in object/memory processing. Compared with NSSet, NSHashTable has the following features:

NSSet (NSMutableSet) holds strong references to its elements, and these elements use hash values ​​and the isEqual: method to perform hash checks and determine whether they are equal.

NSHashTable is mutable, it has no immutable version.

It can hold weak references to elements and remove them correctly when the object is destroyed, which is not possible with NSSet.

Its members can be copied when added.

Its members can use pointers to indicate equality and perform hash checks.

It can contain arbitrary pointers, and its members are not restricted to objects. We can configure an NSHashTable instance to operate on arbitrary pointers, not just objects.

When initializing NSHashTable, we can set an initial option, which determines all subsequent behaviors of this NSHashTable object. This option is defined by the NSHashTableOptions enumeration, as shown below:

 enum { 
 
 //Default behavior, strong reference to objects in the collection, equivalent to NSSet  
 NSHashTableStrongMemory = 0 , 
 
 // Before adding the object to the collection, the object is copied  
 NSHashTableCopyIn = NSPointerFunctionsCopyIn, 
 
 // Use shifted pointer to do hash check and determine whether two objects are equal;  
 // Also use the description method to make a description string  
 NSHashTableObjectPointerPersonality = NSPointerFunctionsObjectPointerPersonality, 
 
 // Objects in the weak reference collection will be removed correctly after the object is released.  
 NSHashTableWeakMemory = NSPointerFunctionsWeakMemory
 };
 typedef NSUInteger NSHashTableOptions;

Of course, we can also use NSPointerFunctions to initialize, but only by using the values ​​defined by NSHashTableOptions can we ensure that the various APIs of NSHashTable can work correctly—including copying, archiving, and fast enumeration.

I think NSHashTable is attractive because it can hold weak references to elements and correctly remove them after the object is destroyed. Let's write an example:

 // The specific calls are as follows  
 @implementation TestHashAndMapTableClass { 
 
 NSMutableDictionary *_dic;
 NSSet *_set; 
 
 NSHashTable *_hashTable;
 } 
 
 - (instancetype)init { 
 
 self = [ super init]; 
 
 if (self) { 
 
 [self testWeakMemory]; 
 
 NSLog(@ "hash table [init]: %@" , _hashTable);
 } 
 
 return self;
 } 
 
 - ( void )testWeakMemory { 
 
 if (!_hashTable) {
 _hashTable = [NSHashTable weakObjectsHashTable];
 } 
 
 NSObject *obj = [[NSObject alloc] init]; 
 
 [_hashTable addObject:obj]; 
 
 NSLog(@ "hash table [testWeakMemory] : %@" , _hashTable);
 } 
 
 The output of this code is as follows: 
 
 hash table [testWeakMemory] : NSHashTable {
 [ 6 ] <NSObject: 0x7fa2b1562670 >
 }
 hash table [init]: NSHashTable {
 }

As you can see, after leaving the testWeakMemory method, the obj object is released and the reference to the object in the collection is safely deleted.

It seems that NSHashTable is better than NSSet (NSMutableSet). Should we use NSHashTable in all applications? Peter Steinberger gave us a set of data in The Foundation Collection Classes, showing that in the operation of adding objects, NSHashTable takes almost twice as long as NSMutableSet, while in other operations, the performance is roughly the same. So, if we only need the features of NSSet, try to use NSSet.

In addition, Mattt Thompson also wrote a very interesting paragraph at the end of NSHash​Table & NSMap​Table, which I will quote directly here:

As always, it's important to remember that programming is not about being clever: always approach a problem from the highest viable level of abstraction. NSSet and NSDictionary are great classes. For 99% of problems, they are undoubtedly the correct tool for the job. If, however, your problem has any of the particular memory management constraints described above, then NSHashTable & NSMapTable may be worth a look.

refer to

NSHashTable Class Reference

NSHash​Table & NSMap​Table

NSHashTable & NSMapTable

The Foundation Collection Classes

Odds and Ends

(I) “Unknown class XXViewController in Interface Builder file.”

I recently wrote a XXViewController class in a static library, and then specified the xib class as XXViewController in the main project's xib. When the program was running, the following error was reported:

 Unknown class XXViewController in Interface Builder file.

I encountered this problem before, but I don’t remember it clearly, so I started looking for the answer on stackoverflow again.

In fact, this problem has nothing to do with Interface Builder. The most direct reason is that the related symbols are not loaded from the static library. The solution to this problem is to add the two flags "-all_load -ObjC" in the "Build Setting" -> "Other Link Flags" of the Target, and it will be OK.

(II) Dealing with Unbalanced calls to begin/end appearance transitions for …

One of our businesses has a requirement that after entering a list, a web page needs to be pushed immediately to promote some activities. On iOS 8, our implementation is OK; but on iOS 7, we found that this web page could not be pushed, and the console gave a warning message, as follows:

 Unbalanced calls to begin/end appearance transitions for ...

In this case, when you click the back button in the navigation bar, a black screen is displayed directly.

We checked on stackoverflow and found this tip:

 occurs when you try and display a new viewcontroller before the current view controller is finished displaying.

This means that an attempt is made to display a new view controller before the current view controller has finished displaying it.

So we checked the code and found that a network request was made in viewDidLoad, and after the request returned, the web event promotion page was pushed. At this time, the current view controller may not show completion (that is, the push operation was not completed).

 Basically you are trying to push two view controllers onto the stack at almost the same time.

When two view controllers are pushed to the current navigation controller stack almost at the same time, or two different view controllers are popped at the same time, uncertain results will occur. Therefore, we should ensure that there is only one operation on the same navigation controller stack at the same time, and we should not push or pop a new view controller even if the current view controller is animating.

So *** we put the data request of the web activity into viewDidAppear and did some processing, so the problem was solved.