Facebook's IOS memory leak monitoring Automation practice

Memory is a shared resource on a mobile device, and if an App fails to manage memory correctly, it can result in memory exhaustion, flash-back, and a severe drop in performance.

Many of the features in the IOS version of Facebook share the same memory space, and if one of the modules consumes a particularly large amount of memory resources, it can have a serious impact on the entire App. For a chestnut, this situation is likely to occur when a function module accidentally causes a memory leak.

On Facebook, we have a lot of engineers doing parallel development in a single code repository. A memory leak is a problem that is difficult to avoid during the development process. When a memory leak occurs, we need to quickly discover and fix it.

There are now some developer tools to aid in the discovery of memory leaks, but what they have in common is that they require a lot of manual action:

1. Open Xcode and choose build for profiling to compile your project

2. Open the Instruments tool

3. Try to reproduce as many scenes and behaviors as possible on your app

4. Watch the chart of the Memory tool

5. Find the source of the memory leak

6. Fix It!

This kind of manual and repair work has to be repeated every time. Because of this, it is difficult to locate and fix memory problems early in the iterative phase.

Automating the troubleshooting of memory leaks and reducing developer human intervention can help us to find memory leaks more quickly. In order to solve this problem, we have developed a set of tools in-house to help us automate this troubleshooting process, and have helped us solve the memory leaks in many of our code. Today, we are pleased to announce our official Open source Memory Leak Troubleshooter: Fbretaincycledetector,fballocationtracker and Fbmemoryprofiler.

Circular references

Objective-c uses reference counting to manage memory and to dispose of unreferenced objects. Object A in memory can have the reference count of object B plus one, that is, retain, so that object B exists in memory as long as possible (as long as object A does not "subtract one" from it, that is, release). In other words: Object a Holds object B.

In most cases, the set of reference counts can work well. However, when two objects are directly, or more often than not, indirectly through certain objects, they hold each other, and this time they are deadlocked. This phenomenon of holding each other's references is called circular referencing.

650) this.width=650; "src=" http://ww2.sinaimg.cn/large/006y8lVagw1fb9i4hj7nmj30kg0cngm0.jpg "title=" "style=" Border:0px;vertical-align:middle; "/>

Circular references can cause a series of problems. In the best case, the leaking object itself will always occupy memory space for a long time, which generally does not cause too much memory consumption. If the leaking objects are constantly increasing and accumulating, the memory used by other functional modules in the APP will be reduced. The worst case scenario is that the memory leak causes the app to use more memory than the limit, and the app will flash back.

To continue reading please click: http://click.aliyun.com/m/9168/

This article is from the "12466150" blog, please be sure to keep this source http://12476150.blog.51cto.com/12466150/1890757

Facebook's IOS memory leak monitoring Automation practice