CODEWITHSUNDEEP
iosswiftuitableviewmemory-managementmemcached
kitchen800
kitchen800

Reputation: 227

Solving raising memory from presented UITableViews

The problem of my app is that the memory usage keeps rising. I have an app that uses multiple UITableView how it is set up is as follows:

All the Cells in UITableView 2,3,4,5 and 6 all have contain images. When I enter UITableView 2,3,4,5 and 6 the memory usage raises as expected as the app loads the images. When I then dismiss the UITableview that I am in and enter another UITableview the memory usage continues to rise.

What I want to do is clear the memory when I dismiss a UITableview 2,3,4,5 or 6. This will mean that the memory usage wont keep on building.

I am currently dismissing the UITableView using the following: 

@IBAction func Back(_ sender: Any) {

    NotificationCenter.default.removeObserver(self)

    self.dismiss(animated: true, completion: nil)
}

Images are stored in a folder in the app. The names of the images are stored in an array this array in my case is called foodImageArray. The UItableView images populated in order, by reading the array and linking each cell to its corresponding image. 

cell.foodImage.image = UIImage(named: foodImageArray[indexPath.row] + ".jpg")

Upvotes: 0

Views: 183

Answers (1)

Rob
Rob

Reputation: 437622

There are three classes of memory problems that result in memory growth:

  1. Cached memory:

    This is when the app holds resources in memory in case you might use those resources again. Examples include image caching and URLCache. When you go from view controller 1 to view controllers 2-6 and then back again, you should not expect the memory to drop down to what it was before you presented the latter view controllers.

    That having been said, if you go through view controllers 2-6 again, repeatedly, and the memory continues to spike up at the same rate, then it might not be a cache issue, and instead, it is likely “abandoned” memory, discussed below. But if memory doesn’t continue to grow, it might not be a problem. When the device starts to run low in memory, it will purge caches for you.

  2. Abandoned memory:

    This is when it’s not a matter of caches, but rather your app fails to release large swaths of memory every time you go through view controllers 2-6. A common source of this problem would be “strong reference cycles” or circular storyboard segues.

    You can detect this by going through all the view controllers multiple times and then tapping on the “debug memory graph” button (see https://stackoverflow.com/a/30993476/1271826). If you see your dismissed view controllers still sitting in the panel on the left side (meaning that they’re still in memory even though you’ve dismissed them), then you probably have a strong reference cycle or some similar problem.

  3. Leaked memory:

    While many use the term “leak” loosely, it actually refers to a very specific problem where you have no strong references to the memory anywhere in your app (i.e. no reference cycles), but it is still leaking. This is is a problem that plagued us with manual reference counting and Objective-C code, but is relatively uncommon with Swift. If you profile your app and use the “Leaks” tool, it will help you identify these cases.

Bottom line, you must identify the nature of the problem by exercising the app many times (don’t worry too much about the first time) and seeing if memory continues to grow. If it still grows on subsequent iterations as you exercise the app, then use the “debug memory graph” to find strong reference cycles (or, less likely, the “Leaks” tool to find actual leaks).

Upvotes: 1

Related Questions