Swift - Lazy Var vs. Let when creating views programmatically (saving memory)

Question

I\'m a beginner and I sort of understand Lazy Var vs. Let. I\'ve noticed that it saves a ton of memory usage when using Lazy Var especially with ImageViews. But the tutorials an

Answer 1

Whether you will use lazy var or not depends on your code and its context. It is not bad or good on its own. You have to decide when it is appropriate.

Before you can decide that, you have to know what lazy var is.

What is lazy var?

Lazy initialization is a concept where initialization (construction) of variable content is delayed until its first usage. First access to such variable triggers initialization. Since content is not created until variable is used (needed) using lazy initialized variables can save resources.

That is primary drive behind lazy initialization. You don't create something until you need it. That is also logic you will use when deciding whether something should be lazy var or not.

If you are dealing with views (or anything else) that are always visible (needed) there is little point in using lazy initialization. On the other hand when you are dealing with instances that are not always needed - then using lazy var is justified.

If your view is always visible in presented view controller, you will not accomplish much by making it lazy. If it is visible only under specific circumstances - for instance when user expands some collapsed panel - then making it lazy makes sense. It will make your view controller load faster and use less memory by default.

---

As far as thread safety is concerned, lazy var are not thread safe in Swift.

That means if two different threads try to access the same lazy var at the same time, before such variable has been initialized it is possible that one of the threads will access partially constructed instance.

You can find more about thread safety in:

Swift - is lazy var thread-safe?

Make "lazy var" threadsafe

Answer 2

Another advantage to using a lazy var is improving the readability of your code.

In your example, the code related to the image view is grouped together instead of being spread out to an initializer, setup function, or viewDidLoad. This improves local reasoning by not requiring the reader of the code to venture to various places in the code to understand how your view is configured. To learn about your view, they only need to jump to its declaration.

An initialization closure marked as a lazy var can access self, allowing for more configuration to be done inside the closure, such as adding target actions or referencing other constant properties.

I would consider initializing properties (especially views) with closures as lazy var's to be a good practice, and it seems to be gaining popularity in the Swift community as well.

Depending on the project, saving developer time can be much more valuable than saving system memory.

Answer 3

The use of lazy vars can provide a workaround to a paradoxical problem: You want to create a custom view that has subviews whose initialization refers to the parent view.

For example, if you want to create a subclass of UIView that contains a child UIScrollView of the same size, you can't declare a class containing:

var m_scrollView: UIScrollView

override init(frame: CGRect)
{
    m_scrollView = UIScrollView(frame: self.frame)
    super.init(frame: frame)
}

The compiler will complain that you're referring to self before calling super.init. But... super.init has to be called after all members are initialized.

The solution to this circular problem is making m_scrollView lazy and initalizing it in its declaration:

lazy var m_scrollView = UIScrollView(frame: self.frame)