0

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:

  • UITableView 1 leads into UITableView 2

  • UITableView 1 leads into UITableView 3

  • UITableView 1 leads into UITableView 4

  • UITableView 1 leads into UITableView 5

  • UITableView 1 leads into UITableView 6

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")
kitchen800
  • 197
  • 1
  • 12
  • 36
  • how are you loading the images files? – Claudio Castro Nov 20 '19 at 00:31
  • add a `deinit()` method to each VC that prints to the console. This will let you see which are/aren't being deinitialised when they are dismissed so you know where to start looking for retain cycles. – flanker Nov 20 '19 at 00:54
  • @ClaudioCastro i have edited the problem to reflect how I do this. – kitchen800 Nov 20 '19 at 01:03
  • I had this problem at the time of objective c,the problem that you are having is that the imageNamed: method caches images which makes your memory footprint grow. In objective c, you could use UIImage initWithContentsOfFile: and your footprint will stay mostly flat. Maybe that will help you: https://medium.com/flawless-app-stories/techniques-to-reduce-memory-footprint-and-oom-terminations-in-ios-a0f6bef38217 – Claudio Castro Nov 20 '19 at 01:49
  • Or this: let path = Bundle.main.path(forResource: image, ofType: nil)! let original = UIImage(contentsOfFile: path)! – Claudio Castro Nov 20 '19 at 01:56
  • @ClaudioCastro I dont understand – kitchen800 Nov 20 '19 at 17:30

1 Answers1

1

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).

Rob
  • 415,655
  • 72
  • 787
  • 1,044