Facebook's iOS Memory Leak Detection Automation Practice

Memory is a shared resource on mobile devices. If an app cannot manage memory properly, it will cause memory exhaustion, flashback and serious performance degradation.

Many functional modules of Facebook's iOS version share the same memory space. If one of the modules consumes a lot of memory resources, it will have a serious impact on the entire app. For example, when a function module accidentally causes a memory leak, this situation is likely to happen.

At Facebook, we have a lot of engineers working on a code repository in parallel. Memory leaks are unavoidable problems encountered during development. When a memory leak occurs, we need to find it quickly and fix it.

There are some developer tools out there to aid in finding memory leaks, but what they all have in common is that they require a lot of manual work:

open Xcode and select build for profiling to compile your project
open Instruments tool
try to put as much as possible on your app More scenarios and behaviors can be reproduced easily
Observe the graph of the memory tool
Find the source of the memory leak
Fix it!
Such manual inspection and repair works have to be repeated every time. Because of this, it is difficult to locate and fix memory issues early in the iteration phase.

Automating the memory leak troubleshooting process as much as possible and reducing the manual intervention of developers can help us find memory leaks faster. To address this, we have developed a set of tools internally to help us automate this troubleshooting process, and have helped us resolve memory leaks in many of our code. Today, we are happy to announce that we have officially open sourced this set of memory leak detection tools: FBRetainCycleDetector, FBAllocationTracker and FBMemoryProfiler.

Circular references
Objective-C uses reference counting to manage memory and free unreferenced objects. Object A in memory can increase the reference count of object B by one, that is, retain, to keep object B in memory as long as possible (as long as object A does not "decrement it by one", that is, release). That is: object A holds object B.

In most cases, reference counting works well. However, when two objects hold each other directly, or more often indirectly through some object, there is a deadlock. This phenomenon of holding each other's references is called circular references.



Circular references can cause a series of problems. In the best case, the leaked object itself will occupy memory space for a long time, which generally does not cause too much memory consumption. If the leaked objects keep increasing and accumulating, the memory that other functional modules in the app can use will decrease. In the worst case, the memory leak causes the memory that the app needs to use to exceed the limit, and the app will crash.

To read the full text, please click: http://click.aliyun.com/m/9168/