Here's the ULTIMATE tip to find memory leaks in Xcode!

Поділитися
Вставка
  • Опубліковано 22 сер 2024
  • #iOS #swift #softwaredeveloper #iosdeveloper
    Thank you for watching this video 🙌
    ➜ Leave a tip: www.buymeacoff...
    ➜ Website: www.swiftwithv...
    ➜ Twitter: / v_pradeilles
    ➜ GitHub: github.com/vin...
    ➜ LinkedIn: / vincentpradeilles

КОМЕНТАРІ • 32

  • @v_pradeilles
    @v_pradeilles  2 роки тому +13

    Did you find this tip useful? Are you already using it in your apps? Let me know in the comments 🚀

  • @poluxsaurus1454
    @poluxsaurus1454 2 роки тому +2

    Yup it's useful. What I do to look for memory leaks is, instead of launching Instruments, I pause the app with the memory debugger and look at the number of instances for each class, not just the view controllers. It's easy to spot when there are more than expected. Sometimes the expectation may be wrong and there is a good reason for some instances to be alive, so it also helps me understand what the app does in case I've forgotten of some design decision.

    • @jack666hack
      @jack666hack 2 роки тому

      This could work for a small app but big ass app is a headache

  • @mistymu8154
    @mistymu8154 2 роки тому +2

    I always put a log statement in the deinit of all my ViewControllers and ViewModels and any other classes that shouldn't be hanging around. For example, there is one scenario for an app I work in that pushes about 5 screens deep and then on the final screen there is a button to pop to root, so I check that I see logs for the deinit of all 5 of those screens and corresponding view models. It would be difficult to listen out for 10 different bloops and find the offending class if there was less than 10 bloops lol.

  • @michaelbrown
    @michaelbrown 2 роки тому +2

    Similarly I usually will have base classes (BaseViewController that contains common items) and will have dealloc (objc) or deinit (swift) methods and just wrap a print statement saying self.description + “ deallocated” in an if debug check. It helps if you’re a breakpoint hoarder like myself. 😂

  • @vaibhavbansod3528
    @vaibhavbansod3528 4 місяці тому

    There would be dancing music if we put symbolic breakpoint in a call where multiple instances are created and only few of them are released

  • @natgenesis5038
    @natgenesis5038 Місяць тому

    Thanks so much

  • @shalinibhat2339
    @shalinibhat2339 2 роки тому +1

    Thank you for this amazing video

  • @jack666hack
    @jack666hack 2 роки тому +1

    Love the tutorials buddy 🔥

  • @bravehearted1010
    @bravehearted1010 Рік тому

    Very useful tip. Thanks a lot!

  • @mykytakhlamov
    @mykytakhlamov Рік тому

    another interesting feature I learned from you, thanks💥

  • @byaruhaf
    @byaruhaf 2 роки тому +2

    Thanks, i use this breakpoint as well except instead of sound I use the action log message to consol with "--- dealloc @(id)[$arg1 description]@ @(id)[$arg1 title]@"

  • @richardrubin2192
    @richardrubin2192 Рік тому

    Merci, Vincent! Great tip!

  • @alexcupra9682
    @alexcupra9682 2 роки тому

    Amazing trick! Thanks :)

  • @Jaroshevskii
    @Jaroshevskii Рік тому

    You amazing, thanks very much ☺️

  • @Mani-xx4fz
    @Mani-xx4fz 2 роки тому

    Nice trick! Thx 👌

  • @mohammadmnasrabadi6837
    @mohammadmnasrabadi6837 2 роки тому

    This is not my choice. Because the problem is with all the references and you only understand the controls. Of course, the sound is not good and can be printed with the following code, which shows its efficiency in deleting several pages at the same time. . in symbol : use the action log message to consol with "--- dealloc @(id)[$arg1 description]@ @(id)[$arg1 title]@"

  • @rasheshbosamiya1482
    @rasheshbosamiya1482 2 роки тому +1

    what about Model & ViewModel classes? can we monitor dealloc for those custom classes?

    • @rasheshbosamiya1482
      @rasheshbosamiya1482 2 роки тому

      @hydro1337x thank you for reply, I have tested and it works with custom classes (e.g. Model, ViewModel etc)

  • @rahuljamba5846
    @rahuljamba5846 Рік тому

    Great man

  • @shilpagade1913
    @shilpagade1913 Рік тому

    In very big code how we identify which object is cause of memory leak. Is thr any way to find it?

  • @alexandergavrilov8019
    @alexandergavrilov8019 2 роки тому +1

    great!

  • @user-jl8xe2df4d
    @user-jl8xe2df4d Рік тому

    Just like in WWDC

  • @marekszymanski2375
    @marekszymanski2375 2 роки тому

    This trick always amazes me, great video!
    Is it possible to do something similar for SwiftUI? I guess everything is a View so it might be hard (and loud 😂)

    • @mistymu8154
      @mistymu8154 2 роки тому +3

      SwiftUI views are structs so they won't have a retain cycle. You should keep an eye on view models though.

  • @AnLaXGaminG
    @AnLaXGaminG 2 роки тому

    Why that clousure make a memory leak? I know that there is no weak self but I dont get the point why that happens :( thanks

    • @addisonfrancisco9007
      @addisonfrancisco9007 2 роки тому +2

      The closure is causing an increase to the reference count because it is capturing self. So, ARC is not going to clean up that view controller during dealloc because the ref count is greater than 0.
      You can read more about it here under “Strong Reference Cycles for Closures”
      docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html

    • @abymathew575
      @abymathew575 2 роки тому

      ua-cam.com/video/GIy-qnGLpHU/v-deo.html I think this video will give your more details about it. Please check this

  • @followerOfJesus723
    @followerOfJesus723 Рік тому

    This is so not working.

  • @rickywitherspoon2861
    @rickywitherspoon2861 2 роки тому

    🤯

  • @alexeykhomych1743
    @alexeykhomych1743 2 роки тому

    it's waste of time for 2 reasons: too hard to understand and it doesn't always work well.