Good day, here's what i am trying to do:
i have a photo processing app that takes images using AVFoundation
i have a DeviceMotion queue that is processing device position at 60Hz
when image is taken, it needs to be cropped and saved. DeviceMotion needs to keep running and interface updated without delays
what i am seeing is: updates to interface from DeviceMotion queue are being frozen for the duration of image crop.
this is how i start updates for DeviceMotion:
self.motionManager.deviceMotionUpdateInterval = 1.0f/60.0f;
gyroQueue = [[NSOperationQueue alloc] init];
[self.motionManager startDeviceMotionUpdatesToQueue:gyroQueue withHandler:^(CMDeviceMotion *motion, NSError *error){
[NSThread setThreadPriority:1.0];
[self processMotion:motion withError:error];
}];
when images is returned from AVFoundation it is added to the queue for processing:
imageProcessingQueue = [[NSOperationQueue alloc] init];
[imageProcessingQueue setName:#"ImageProcessingQueue"];
[imageProcessingQueue setMaxConcurrentOperationCount:1];
//[imageProcessingQueue addOperationWithBlock:^{
//[self processImage:[UIImage imageWithData:imageData]];
//}];
NSInvocationOperation *operation = [[NSInvocationOperation alloc] initWithTarget:self selector:#selector(processImage:) object:[UIImage imageWithData:imageData]];
[operation setThreadPriority:0.0];
[operation setQueuePriority:NSOperationQueuePriorityVeryLow];
[imageProcessingQueue addOperation:operation];
and the method for processing the image:
- (void)processImage:(UIImage*)image {
CGSize cropImageSize = CGSizeMake(640,960);
UIImage *croppedImage = [image resizedImageWithContentMode:UIViewContentModeScaleAspectFit bounds:cropImageSize interpolationQuality:kImageCropInterpolationQuality];
NSData *compressedImageData = UIImageJPEGRepresentation(croppedImage, kJpegCompression);
[self.doc addPhoto:compressedImageData];
}
the issue is:
devicemotion updates are blocked for the duration of image crop when image is processed using the NSOperationQueue
if i process the image using performSelectorInBackground - it works as desired (no delays to DeviceMotion queue)
[self performSelectorInBackground:#selector(processImage:) withObject:[UIImage imageWithData:imageData]];
any ideas on where my understanding of background threading needs an update? :)
PS. I have asked this question earlier but it got nowhere, so this is a re-post
i have found a solution (or solid workaround) for this issue:
instead of routing deviceMotion updates to the queue using startDeviceMotionUpdatesToQueue, i have created a CADisplayLink timer and it is not interfering with other background queues - while it is matching screen refresh rate it's given highest priority by it's nature:
[self.motionManager startDeviceMotionUpdates];
gyroTimer = [CADisplayLink displayLinkWithTarget:self selector:#selector(processMotion)];
[gyroTimer addToRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
Related
I have a piece of code that on a timer callback dispatches blocks to a serial queue. For testing the block is empty meaning it doesn't have any code in it. Nevertheless, I'm seeing the memory allocation of my app increasing. Is it because gcd is not deallocating fast enough the submitted blocks? Or is it something to do with the number of threads that gcd is spawning (like indicated by Memory usage for global GCD queue) ?
I also tried changing the serial queue with a concurrent queue and does solve the memory growth but I was wondering if anyone has a good explanation and recommendation on how to solve the problem other than using a concurrent queue.
UPDATE
Here is the sample code I'm using to debug this problem:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
self.httpRequestOperationManager = [[AFHTTPRequestOperationManager alloc] init];
self.httpRequestOperationManager.operationQueue.maxConcurrentOperationCount = 1;
self.queue = dispatch_queue_create("my_queue", DISPATCH_QUEUE_SERIAL);
NSString *urlString = #"<URL>";
NSURL *url = [NSURL URLWithString:urlString];
self.request = [[NSURLRequest alloc] initWithURL:url cachePolicy:NSURLRequestReloadIgnoringCacheData timeoutInterval:5];
[NSTimer scheduledTimerWithTimeInterval:0.5f
target:self
selector:#selector(fetch)
userInfo:nil
repeats:YES];
return YES;
}
- (void)fetch
{
AFHTTPRequestOperation *op = [self.httpRequestOperationManager
HTTPRequestOperationWithRequest:self.request
success:^(AFHTTPRequestOperation *operation, id responseObject) {
dispatch_async(self.queue, ^{
NSLog(#"DISPATCHING ASYNC CAUSES MEMORY TO GROWTH");
});
} failure:^(AFHTTPRequestOperation *operation, NSError *error) {
}];
[self.httpRequestOperationManager.operationQueue addOperation:op];
}
NOTES
The problem doesn't occur if self.queue is the main queue. Is it because blocks dispatched on the main queue are drained a lot faster??
The problem doesn't occur if self.queue is a concurrent queue (dispatch_get_global_queue(QOS_CLASS_DEFAULT, 0))
My problem is similar to Calling AFNetworking in NSTimer causes serious memory leak and I tried what is recommended there but didn't help.
I'm using iOS9.0 with AF v2.6.1
The image below shows the memory growth after 12 minutes..and the memory allocation continues to growth!
I have a video decoder playing H264 using AVSampleBufferDisplayLayer and all works well until I scroll a UICollectionViewController on the same View Controller. This appears to block the main thread causing the app to crash. I have tried putting this code in a block on a separate queue using dispatch_async but still have the same blocking problem along with further performance issues on the decoder.
dispatch_async(sampleQueue, ^{
[sampleBufferQueue addObject:(__bridge id)(sampleBuffer)];
if ([avLayer isReadyForMoreMediaData]) {
CMSampleBufferRef buffer = (__bridge CMSampleBufferRef)([sampleBufferQueue objectAtIndex:0]);
[sampleBufferQueue removeObjectAtIndex:0];
[avLayer enqueueSampleBuffer:buffer];
buffer = NULL;
NSLog(#"I Frame");
[avLayer setNeedsDisplay];
while ([sampleBufferQueue count] > 0 && [avLayer isReadyForMoreMediaData]) {
CMSampleBufferRef buffer = (__bridge CMSampleBufferRef)([sampleBufferQueue objectAtIndex:0]);
[sampleBufferQueue removeObjectAtIndex:0];
[avLayer enqueueSampleBuffer:buffer];
buffer = NULL;
NSLog(#"I Frame from buffer");
[avLayer setNeedsDisplay];
}
}
else {
NSLog(#"AVlayer Not Accepting Data (I)");
}
});
Is there a way to give this task priority over User Interface actions like scrolling a Collection View etc? Apologies for lack of understanding I am reasonably new to IOS.
Turns out the UICollectionView was blocking the delegate calls for NSURLConnection on the main thread. This solved the problem:
NSURLConnection *connection = [[NSURLConnection alloc] initWithRequest:request
delegate:self];
changed to
NSURLConnection *connection = [[NSURLConnection alloc] initWithRequest:request
delegate:self
startImmediately:NO];
[connection scheduleInRunLoop:[NSRunLoop currentRunLoop]
forMode:NSRunLoopCommonModes];
[connection start];
I have problem with NSOperations. Everything works fine but sometimes (I don't know why) Operation block is simply skipped. Am I missing something? How is it possible that operation is not even NSLogging "operation entered"? Here is some code from viewDidLoad:
//I'm using weakOperation in order to make [self.queue cancelAllOperation] method when viewWillDisappear
NSBlockOperation* operation = [[NSBlockOperation alloc] init];
__weak NSBlockOperation* weakOperation = operation;
NSString *session=#"";
#try{
session = [self getSessionId];//getting data from CoreData
}#catch(NSException *e)
{
NSLog(#"EXCEPTION WITH SESSION");
}
weakOperation = [NSBlockOperation blockOperationWithBlock:^{
NSLog(#"operation entered");
[self downloadJSONArray]; //doing some connection downloading and using session
[self downloadImages]; //downloading images from urls from JSONs
[[NSOperationQueue mainQueue] addOperationWithBlock:^{
[self refresh]; //update mainThread
}
}
[self.queue addOperation:weakOperation];
What could be scenario that coul make skip this block ?
Is there max number of threads created in iOS?
EDIT: Hey, I'have found why this happends - when a lot of applications run in the background and iOS does not have resources to queue another thread it simply skips that, how to behave in this situation?
You are assigning a new NSBlockOperation to a weak variable. Whenever you assign a new object to a weak variable, you risk having it released immediately.
If you needed a weak reference to the operation, you'd assign the object to some local variable first, and then get the weak reference for that object:
NSBlockOperation* operation = [NSBlockOperation blockOperationWithBlock:^{
NSLog(#"operation entered");
[self downloadJSONArray]; //doing some connection downloading and using session
[self downloadImages]; //downloading images from urls from JSONs
[[NSOperationQueue mainQueue] addOperationWithBlock:^{
[self refresh]; //update mainThread
}
}
__weak NSBlockOperation* weakOperation = operation;
[self.queue addOperation:weakOperation];
But, as the method stands, the weakOperation is unnecessary. You generally only need weak references to avoid strong reference cycles. But no such cycle is present currently, so you can just do:
NSBlockOperation* operation = [NSBlockOperation blockOperationWithBlock:^{
NSLog(#"operation entered");
[self downloadJSONArray]; //doing some connection downloading and using session
[self downloadImages]; //downloading images from urls from JSONs
[[NSOperationQueue mainQueue] addOperationWithBlock:^{
[self refresh]; //update mainThread
}
}
[self.queue addOperation:operation];
Looking at your code comment, you say "I'm using weakOperation in order to make [self.queue cancelAllOperation] method when viewWillDisappear". Using weakOperation like this will not accomplish what you want because your operation is not checking to see if it was canceled and thus it will not respond when the NSOperationQueue tries to cancel it.
If you wanted to do that, then a variation on your weakOperation pattern can be useful, but rather than using this weakOperation to add it to the queue, you can use the weak reference within the block to check to see if the operation was canceled (and you want the weak reference in the block to avoid the block from retaining the operation, itself, causing a strong reference cycle). The other key observation is that rather than creating a new NSBlockOperation, simply add an execution block to the original operation you created:
NSBlockOperation* operation = [[NSBlockOperation alloc] init];
__weak NSBlockOperation* weakOperation = operation;
[operation addExecutionBlock:^{
NSLog(#"operation entered");
if ([weakOperation isCancelled]) return;
[self downloadJSONArray]; //doing some connection downloading and using session
if ([weakOperation isCancelled]) return;
[self downloadImages]; //downloading images from urls from JSONs
if ([weakOperation isCancelled]) return;
[[NSOperationQueue mainQueue] addOperationWithBlock:^{
[self refresh]; //update mainThread
}];
}];
[self.queue addOperation:operation];
Clearly, if the operation is tied up in downloadJSONArray or downloadImages, it won't respond to the cancelation event until it returns from those methods. You'd have to check the cancelation status with those methods, too, if you want this operation to respond reasonably quickly to the cancellation event.
In answer to your second question, yes, there is a maximum number of threads, but it's a reasonably large number and there are other factors that come into play before the number of threads becomes an issue. The constraining factor is likely to be the downloadImages method (as you can only have 5 concurrent download requests). And even if that wasn't an issue, you'd want to constrain the number of concurrent operations, anyway, to mitigate the app's peak memory usage. If there are any network operations involved, you generally want to do something like:
self.queue.maxConcurrentOperationCount = 4; // or 5
That way, you minimize how much of the limited system resources (including threads) you are using.
By the way, I assume that downloadJSONArray and downloadImages are synchronous methods. If those are performing asynchronous network requests, you might want to consider further refactoring of the code to ensure the operation doesn't complete prematurely (e.g. wrap this in a concurrent NSOperation subclass or change those methods to run synchronously).
i have written code to downloading data from server using NSOperationQueue and NSOperation. and now i want to show progress on UserInterface. i used UITableView and used NSOpeartionQueue as a datasource in tableview delegate
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
return [[[Downloadmanager sharedInstance] downloadOperationQueue] count];
}
and bind NSOperation`s properties to UITableViewCell.
1) Is this a fisible solution to sending NSOperationQueue as a datasource to tableview delegate ?
2) How to implement notification to reload tableview when NSOperation's state changes?
Thanks.
I don't think it's the proper way of showing progress using NSOperationQueue as a datasource to tableview. You can use networking library like AFNetworking for downloading data and use setDownloadProgressBlock: method for showing progress. Refer this link for the code download progress.
It's easy to reload tableview when the download completes, just call [tableView reloadData] in completionblock.
Here is the code which shows image downloading using AFNetworking which you can easily change for data download.(refer this gist)
- (void)downloadMultiAFN {
// Basic Activity Indicator to indicate download
UIActivityIndicatorView *loading = [[UIActivityIndicatorView alloc] initWithActivityIndicatorStyle:UIActivityIndicatorViewStyleWhiteLarge];
[loading startAnimating];
[self.imageView.superview addSubview:loading];
loading.center = self.imageView.center;
// Create a request from the url, make an AFImageRequestOperation initialized with that request
NSURLRequest *request = [NSURLRequest requestWithURL:[NSURL URLWithString:self.picUrl]];
AFImageRequestOperation *op = [[AFImageRequestOperation alloc] initWithRequest:request];
// Set a download progress block for the operation
[op setDownloadProgressBlock:^(NSUInteger bytesRead, long long totalBytesRead, long long totalBytesExpectedToRead) {
if ([op.request.URL.absoluteString isEqualToString:#"http://www.pleiade.org/images/hubble-m45_large.jpg"]) {
self.progressBar.progress = (float) totalBytesRead/totalBytesExpectedToRead;
} else self.progressBar2.progress = (float) totalBytesRead/totalBytesExpectedToRead;
}];
// Set a completion block for the operation
[op setCompletionBlockWithSuccess:^(AFHTTPRequestOperation *operation, id responseObject) {
self.imageView.image = responseObject;
self.image = responseObject;
if ([op.request.URL.absoluteString isEqualToString:#"http://www.pleiade.org/images/hubble-m45_large.jpg"]) {
self.progressBar.progress = 0;
} else self.progressBar2.progress = 0;
} failure:^(AFHTTPRequestOperation *operation, NSError *error) {}];
// Start the image download operation
[op start];
// Remove the activity indicator
[loading stopAnimating];
[loading removeFromSuperview];
}
That is an interesting idea, but I don't think it's a good practice make such a "high coupling" - linking model so tightly to the view.
I'd approach it as - download the data on the background thread as you already do - with NSOperationQueue but save it to some kind of an object; say NSMutableArray that serves as the data source for the table view.
Every time a single operation ends (use completion handlers or KVO to get informed) - update the table view. The update can be done two ways - reloading or updating. I'll leave the choice up to you - you can read further discussion about that in this question.
I'm using the CMMotionManager to gather accelerometer data. I am trying to set the update interval to every half second with the following:
[_motionManager setDeviceMotionUpdateInterval:.5];
[_motionManager startAccelerometerUpdatesToQueue:[[NSOperationQueue alloc] init]
withHandler:^(CMAccelerometerData *accelerometerData, NSError *error) {
dispatch_async(dispatch_get_main_queue(), ^{
[self performSelectorOnMainThread:#selector(update:) withObject:accelerometerData waitUntilDone:NO];
});}];
yet I receive updates far more frequently than every half second. Any idea why?
Wasn't setting the update interval for accelerometer itself.
[_motionManager setAccelerometerUpdateInterval:.5];