Here's the ULTIMATE tip to find memory leaks in Xcode!
HTML-код
- Опубликовано: 28 мар 2022
- #iOS #swift #softwaredeveloper #iosdeveloper
Thank you for watching this video 🙌
➜ Leave a tip: www.buymeacoffee.com/v.pradei...
➜ Website: www.swiftwithvincent.com
➜ Twitter: / v_pradeilles
➜ GitHub: github.com/vincent-pradeilles/
➜ LinkedIn: / vincentpradeilles 
Наука
Did you find this tip useful? Are you already using it in your apps? Let me know in the comments 🚀
Very useful tip. Thanks a lot!
Merci, Vincent! Great tip!
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.
This could work for a small app but big ass app is a headache
Love the tutorials buddy 🔥
Thank you for this amazing video
Amazing trick! Thanks :)
another interesting feature I learned from you, thanks💥
Thanks so much
Nice trick! Thx 👌
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.
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. 😂
You amazing, thanks very much ☺️
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
Great man
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 😂)
SwiftUI views are structs so they won't have a retain cycle. You should keep an eye on view models though.
great!
In very big code how we identify which object is cause of memory leak. Is thr any way to find it?
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]@"
what about Model & ViewModel classes? can we monitor dealloc for those custom classes?
@hydro1337x thank you for reply, I have tested and it works with custom classes (e.g. Model, ViewModel etc)
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]@"
Just like in WWDC
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
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
ruclips.net/video/GIy-qnGLpHU/видео.html I think this video will give your more details about it. Please check this
This is so not working.
🤯
it's waste of time for 2 reasons: too hard to understand and it doesn't always work well.
?