Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

Tags:

var

let

swift

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 and guides I've seen so far don't use Lazy Var very often, so I'm feeling suspicious that it is bad practice and that I'm overlooking something.

I did a little research and learned that Lazy isn't "thread safe," but I don't understand what this means. I've seen a lot of pros and cons, but I can't draw any conclusions especially because I have very limited knowledge.

When is it ok (or better) to use Lazy Var vs. Let when creating a UIView?

lazy var profileImageView: UIImageView = {

    let imageView = UIImageView(image: #imageLiteral(resourceName: "page1"))
    imageView.translatesAutoresizingMaskIntoConstraints = false
    imageView.contentMode = .scaleAspectFit
    return imageView

}()
like image 469
Jazure Avatar asked Nov 18 '17 15:11

Jazure


People also ask

When should I use lazy var Swift?

Lazy variables allow you to delay the initialisation of stored properties. This can be useful to only perform expensive work when it's actually needed. The different between lazy- and computed properties is important in cases you need to have calculations based on the current state of values.

Is Lazy stored properties thread safe?

No, it means if two threads try to access it at the same time, the second thread might receive a partially initialized object. And since NSManagedObjectContext isn't thread safe, you shouldn't access it from different threads.

Is Lazy var thread safe Swift?

Another problem is that lazy var is not thread-safe which means the closure can get executed multiple times due to accesses from different threads.

How is lazy stored property useful in Swift?

Lazy properties are useful when the initial value for a property is dependent on outside factors whose values aren't known until after an instance's initialization is complete.


3 Answers

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

like image 165
Dalija Prasnikar Avatar answered Oct 19 '22 03:10

Dalija Prasnikar


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.

like image 42
nathangitter Avatar answered Oct 19 '22 02:10

nathangitter


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)
like image 39
Oscar Avatar answered Oct 19 '22 02:10

Oscar