Using the array from Swift to see OBJECTIVE-C

 State maintenance is a topic that is not enough, after all, the status of processing is the core of our entire app, but also the most prone to bugs. Before writing a functional programming point of view of State maintenance of the article, this time from the swift language level of improvement, see how objective c how reasonable to handle the maintenance of the array.

Objective memory layout for C arrays

To understand how nsarray,nsset,nsdictionary these collection classes are used, we need to figure out their corresponding memory layouts, taking a Nsmutablearray property as an example:

12345

//declare@property (nonatomic, strong) NSMutableArray*                 arr;//initself.arr = @[@1, @2, @3].mutableCopy;

After arr initializes, for example, a 64-bit system, its actual memory layout is divided into three blocks:

The first block is the position of the pointer nsmutablearray* arr, which is 8 bytes. The second block is where the actual memory area of the array is located, which is 3 consecutive pointer addresses, each accounting for 8 bytes and a total of 24 bytes. The third block is the real memory space of @1,@2,@3 these NSNumber objects. When we invoke different APIs to operate on ARR, we need to be clear about which part of the memory is actually being manipulated.

Like what:

1	self.arr = @[@4];

is to assign a value to the first area of memory.

1	self.arr[0] = @4;

is to assign values to the second area of memory.

1	[self.arr[0] integerValue];

is to access the third area of memory.

Before writing a multi-thread-safe article, we know that even in multi-threaded scenarios, it is safe to read and write to the first area of memory, while the second and third areas of memory are unsafe.

Why is Nsmutablearray dangerous?

In the world of objective C, those with mutable are dangerous molecules. Let's look at the following code:

12345678910111213141516

//main threadself.arr = @[@1, @2, @3].mutableCopy;for(int i = 0; i < _arr.count; i ++) {    NSLog(@"element: %@", _arr[i]);}//thread 2NSMutableArray* localArr = self.arr;//get result from serverNSArray* results = @[@8, @9, @10];//refresh local arr[localArr removeAllObjects];[localArr addObjectsFromArray:results];

nsmutablearray* Localarr = Self.arr; After execution, our memory model is this:

This line of code is actually just a new 8-byte first memory space for Localarr,localarr to actually share the second and third memory areas with ARR when executed on thread 2 [Localarr removeallobjects]; When cleaning up the second area of memory, if the main thread is accessing the second memory area _arr[1] at the same time, it will cause crash. The root cause of such problems is the simultaneous reading and writing of the same area of memory.

Swift's change

Swift has fundamentally changed the language level for the above array assignment operations.

All operations for the collection class in swift conform to a mechanism called copy on Write (COW), such as the following code:

12345678910

var  arr = [1, 2, 3] var  localarr = arr  print ( ) Code class= "JS Plain" >print (  arr += [4];  print ( ) print ( "localarr: \ ( Localarr) " )

When executing to var Localarr = arr, the memory layout of ARR and Localarr is consistent with objective C, and Arr and Localarr share the second third block of memory, but once a write operation (write), such as arr + = [4]; , Swift will generate a new copy (copy) for the second memory area of ARR, which is called copy on write, and after executing cow, arr and Localarr point to different second memory areas as shown in:

Once the write operation for ARR occurs, the system copies the memory region 2 to a new memory area of 4, and the pointer to arr points to the newly opened area 4, then the array changes, and arr and Localarr point to different regions, even in the multi-threaded environment at the same time read and write, It also does not cause access to the crash in the same memory area.

The above code, the final printed result, the elements contained in ARR and Localarr are also inconsistent, after all, they have pointed to the respective second type of memory area.

That's why Swift is a more secure language, with language-level modifications that help developers avoid difficult-to-debug bugs, all of which are transparent to developers, free of charge, and developers don't need to make a special fit. is still a simple = operation, but what happens behind the scenes is not the same.

The comprehension of Objective C

Objective C has not yet exited the historical stage and is still playing a lot of heat in many projects. Understand the things behind Swift, Objective C can be used to learn, but to write a bit more code.

Objective C Since there is no cow, we can copy it ourselves.

For example, to iterate over an array, copy before traversing:

1234	NSMutableArray* iterateArr = [self.arr copy];for(int i = 0; i < iterateArr.count; i ++) {    NSLog(@"element: %@", iterateArr[i]);}

For example, when we need to modify the elements in the array, copy before starting the modification:

1234567

self.arr = @[@1, @2, @3].mutableCopy;   NSMutableArray* modifyArr = [self.arr mutableCopy];[modifyArr removeAllObjects];[modifyArr addObjectsFromArray:@[@4, @5, @6]];self.arr = modifyArr;

For example, when we need to return a mutable array, we return an array of copy:

1234567

- (NSMutableArray*)createSamples{        [_samples addObject:@1];    [_samples addObject:@2];        return[_samples mutableCopy];}

As long as it is for the operation of the shared array, always remember to copy a new memory area, you can achieve the effect of manual cow, so that objective C can also be maintained in the state of the time, is multithreaded security.

Copy more healthy

In addition to Nsarray, there are other collection classes Nsset,nsdictionary and so on, NSString is essentially a collection, and for the handling of these states, copy can make them more secure.

The purpose is to avoid shared state, which is not only due to the multi-threaded scenario, even if the state is maintained in the UI thread, the state may be unexpectedly changed over a longer span of time, and copy can isolate the side effects of this change.

Copy, of course, is not without cost, the most obvious cost is the memory overhead, an array containing 100 elements, if copy, under the 64-bit system, there will be more than 800 bytes of space. This is why swift only writes when it is write, and if it is read only, it does not incur the additional memory overhead of the copy. But overall, this memory overhead is almost negligible compared to the stability of our program. Using copy more when maintaining the state, allowing our functions to conform to the pure function standard in functional programming, will make our code more stable.

Summarize

When learning swift, if you look carefully, you can find many other places, as well as the syntax features of Swift to avoid sharing the same block of memory. To really understand the mechanisms behind these languages, it is still our understanding of memory layout.

Using the array from Swift to see OBJECTIVE-C