iOS resolves upload 100 images memory crash problem

Recent project requirements, extract 100 images from the album and upload them to the server. The premise is that the picture cannot be compressed. Because the image information to be collected to create a 3D model. So it must be a high-definition picture.

• Look at the code first.

[NetWorking uploadWithUrl:@"xxx" parameters:nil constructingBodyWithBlock:^(id<AFMultipartFormData> formData) {                for (int i = 0; i<imageArr.count; i++) {                            UIImage *image = imageArr[i];                NSData *data = UIImageJPEGRepresentation(image, 1.0);                [formData appendPartWithFileData:data name:@"files" fileName:@"xxxx" mimeType:@"image/jpeg"];                    }            } withProgress:^(NSProgress *uploadProgress) {            } success:^(id responseObject) {            } failure:^(NSError *error) {           }]

• If the Imagearr is 100 or greater, it can cause a crash.

• This is what the simulator pops up to say.

  
  3be4ee0e-5a0f-408e-b3ee-da9d0bcfdbae.png

• It means that the memory warning Carsh out the app directly.

Screen shot 2017-03-11 a.m. 9.52.23.png

• The moment I snapped, the memory soared.

Cause: Because the local variables of the Image,data are not released in memory in time, the memory is too large, causing the program to be killed. Workaround. Releasing local variables in a timely manner is possible. Join the auto-release pool in the middle of the local variable.

[NetWorking uploadWithUrl:@"xxx" parameters:nil constructingBodyWithBlock:^(id<AFMultipartFormData> formData) {                for (int i = 0; i<imageArr.count; i++) {                     @autoreleasepool {                UIImage *image = imageArr[i];                NSData *data = UIImageJPEGRepresentation(image, 1.0);                [formData appendPartWithFileData:data name:@"files" fileName:@"xxxx" mimeType:@"image/jpeg"];         }                    }            } withProgress:^(NSProgress *uploadProgress) {            } success:^(id responseObject) {            } failure:^(NSError *error) {           }]

Auto-Free Pool overview

The auto-release pools are placed on a stack, although they are often referred to as "nested". When you create a new auto-free pool, it is added to the top of the stack. When the auto-free pool is reclaimed, they are removed from the stack. When an object receives a send Autorelease message, it is added to the current thread's auto-free pool at the top of the stack. You cannot send autorelease or retain messages to the auto-free pool. Application kit will start at the beginning of an event cycle (or event loop iteration)-such as a mouse down event-to automatically create an auto-free pool and release it at the end of the event cycle, so your code usually doesn't have to care. There are three scenarios in which you should use your own automatic release pool:

If you are writing a program that is not based on application kit, such as a command-line tool, there is no built-in support for the auto-free pool; You must create them yourself.

If you generate a dependent thread, you must immediately create your own auto-free pool Once the thread starts executing, otherwise you will leak the object.

If you write a loop that creates a number of temporary objects, you can create an auto-free pool inside the loop to destroy them before the next iteration
Object. This can help reduce your application's maximum memory footprint.

Wang Banbo
Links: http://www.jianshu.com/p/9e84fe63d5c0
Source: Pinterest
Copyright belongs to the author. Commercial reprint please contact the author for authorization, non-commercial reprint please specify the source.

iOS resolves upload 100 images memory crash problem