iOS: NSFileHandle vs NSOutputStream for large file download

Question

On iOS, our application is downloading a zip file that's approximately 400MB. We're getting intermittent crashing while the file is downloading.

Current I'm using [NSFileHandle writeData:] to write the data as it comes in, and is not being stored in memory. But I'm wondering if the operating system is somehow storing it in memory?

Would NSOutputStream be a better solution to downloading large file? Or possibly standard unix file descriptors?

Our file handle is setup like this:

NSFileManager * fileManager = [NSFileManager defaultManager];
[fileManager createFileAtPath:tmpFilePath.path contents:nil attributes:nil]; 
_zipFile = [NSFileHandle fileHandleForWritingAtPath:tmpFilePath.path];

Currently my NSURLConnection delegate method looks like this:

- (void) connection:(NSURLConnection *) connection didReceiveData:(NSData *) data {
   [_zipFile writeData:data];
}

So the data that comes in from the request is not stored or appended to any other data objects. Shouldn't this just write to disk and not effect memory?

Thanks

Answer 1

I don't think there's anything wrong with your use of NSFileHandle. I confess that I've always used NSOutputStream, but I just tried it both ways (NSFileHandle and NSOutputStream), and both appear to be quite respectful in terms of the memory consumed. Downloading a 40mb file, the allocations spiked to 3mb at the start of the download but quickly leveled off at 1mb):

So, I'd run your app through "Allocations" and "Leaks" (if you choose "Leaks", you get both) and see what it looks like.

If you haven't already, run your code through the static analyzer ("Analyze" on the "Product" menu), to make sure you don't have any issues. (You should have a clean bill of health there; if there are any issues reported, you must fix those.) I'd also make sure that zombies are turned off (because in the process of keeping track of all of those released objects, it creates a zombie object for each ... small, but it will consume memory.