Practical Instruments - Part 5: Memory | Ray Wenderlich

🎓 Courses & Articles
1

Learn how to track down and fix memory leaks using the Debug Memory Graph and the Leaks Template.

This is a companion discussion topic for the original entry at https://www.raywenderlich.com/4065-practical-instruments/lessons/5
2

Hi Luke,

your tutorials helped me learning few good things. Whatever we are seeing now in videos is already available in tutorials. Please add more examples in memory leaks and Zombies. We appreciate the hardwork.

Thank you

3

Hi Luke,

Just another mention of thanks. Instruments and I have always had an annoy-annoy relationship and this one clearly helped me find a vicious memory leak in a feature.

Thanks again!
-Andrei

1 Like
4

@lordandrei That’s awesome, glad to hear it!

5

Hi Luke

In my current project I am using RxCocoa and RxSwift and I want to optimize the launch time of app but I am not able to make static class for RxSwift and RxCocoa because these are not objective c classes so Please guide me on this.

Thanks

~

6

Hi @luke_parham, in this video you showed how making pods to static lib reduced the launch time of application.

I wanted to know if we can use static instead of dynamic libraries in production?

Also I found a link → Broadcom Blogs
stating that,

“Using dynamic libraries instead of static libraries reduces the executable file size of an app. They also allow apps to delay loading libraries with special functionality only when they’re needed instead of at launch time. This feature contributes further to reduced launch times and efficient memory use.”

Could you please help me understand this concept of static vs dynamic, and clear my confusion regarding what is better and advisable ? static lib or dynamic

7

@luke_parham Do you have any feedback regarding this? Thank you - much appreciated! :]

8

@mausam Ok so first thing is yep you can definitely use static libs in production. Secondly, I’ll admit that I could be confused here, but as far as I can tell, the benefits of dynamically loading frameworks is really only useful for Apple. While UIKit.framework can benefit from being shared on iOS, I don’t think multiple apps using AFNetworking will benefit from a faster launch even if they’re all built with a dylib version of the framework.

It is also technically true that frameworks can be selectively loaded later, but this doesn’t happen for free. The default is that your libraries will load more slowly at launch if you choose to link them like you normally would in the Xcode project. I think you could technically choose to instead add the .framework to your app’s bundle and then call the dlopen() function to dynamically load it yourself later. As far as I can tell this strategy isn’t recommended and is more trouble than its worth.

9

Okay @luke_parham thanks :smile: