7

I'm newbie(ish) iOS developer using Alamofire for the first time to make multiple GET requests for an iOS 9.3 app:

    var i = 0
    while i < 100{
        var url = String("https://itunes.apple.com/search?term=" + "somequery")

        Alamofire.request(.GET, url).responseJSON {[weak self] response in
            switch response.result {
            case .Success:
                break


            case .Failure(let error):
                print(error)
            }

        }
       i++

    }

Every request made increases the app's memory usage, and then never releases it. I've used Instruments to try to get a better idea of what is happening and it seems like this is an issue related to CFNetwork.

Screenshot of Instruments + Memory Leak

Things I have tried to resolve the issue:

  • cancel each task in the session as described here
  • use dispatch groups as described here
  • clear NSURLCache using NSURLCache.sharedURLCache().removeAllCachedResponses()
  • invalidate and cancel the session using session.invalidateAndCancel()
  • change the requestCachePolicy to .ReloadIgnoringLocalCacheData

Why does this occur and how can I release the memory after the requests are complete?

Community
  • 1
  • 1
mr. sudo
  • 347
  • 1
  • 13
  • Do you have zombies turned on? Is this a debug build or release build? – Rob May 26 '16 at 05:07
  • It doesn't look like I have zombies turned on and I'm currently running a debugging build. (I checked under Scheme > Edit Scheme) – mr. sudo May 26 '16 at 05:23
  • 1
    I'm unable to reproduce the behavior you describe. I did 100 Alamofire requests like you have above and my memory went from 19.6mb to 22.3mb relatively quickly and then stayed there until the requests finished. When I added some logging messages (logging the `print(response.result.value)`), memory did grow while the queries were running, but was largely released when the query finished. The problem probably rests in what you're doing with the results, or something strange about your project/environment configuration. – Rob May 26 '16 at 05:44
  • Perhaps you can look at the allocations statistics rather than the call tree and see what type of objects account for most of this memory. Also, it would be helpful to let the app reach quiescence (e.g. let memory level to some flat line level before triggering memory-consuming action) so we can differentiate your stead-state from the result of the queries. – Rob May 26 '16 at 05:58
  • Very interesting, thank you for helping me narrow the problem down to a more manageable scale. I'll try reimplementing other sections of the project and update the page if I discover the culprit. I'm pretty new to Instruments but I'll try the allocations statistics section as a starting point. – mr. sudo May 26 '16 at 06:03
  • did you ever found what happened? – Albert Jan 12 '22 at 00:25

0 Answers0