C + +, Java, objective-c, Swift binary compatibility testing

This is a creation in Article, where the information may have evolved or changed.

Given the growing use of dynamic libraries in iOS apps, binary compatibility issues can be a daunting issue. This article contrasts the binary compatibility issues of C + +, Java, objecive-c, and Swift.

Use of dynamic libraries on the iOS side

IOS 8 starts to support apps using dynamic libraries.

Apple has a limit on the size of the __text__ segment of the app being submitted, and many Big Mac apps tend to exceed this limit. Before IOS9, the __text__ segment of each architecture was smaller and iOS9 zoomed to 500MB. For more information, see: To submit a app for review.

Open Source Library can only be introduced through Podfile source code, source dependencies, compile very slow.

Sustainable building also needs to be based on Apple's environment, such as using Mac Pro/mac Mini to build. Mac Pro is expensive, Mac Mini does not work, and it takes a lot of time to build.

In order to speed up the compilation, the large app can maintain its own private warehouse, compile the dependent library into the framework as much as possible and speed up the compilation speed.

Swift must now be based on Dynamic library development.

Building an app based on a dynamic library, upgrading a dynamic library requires the entire dependency tree to be compiled once. In particular, some frequently changing base components, such as changes in visual components, are reaching.

Test environment

C + +, Java, OC, and Swift implement the base class Foo, and then the bar subclass, and main uses the bar class to print the information of the member variable. Add the member variable MEMBER0 to the Foo class, recompile foo (make Foo &&./main), bar and main unchanged, and observe the execution results.

Code address: Binary_compatibility_test.

Lldb a bit of useful debugging skills. For more debugging functions, see: The Lldb Debugger.

Test results

1.c++ will appear dislocation, but not crash. The binary system is also relatively fragile.

2.Java can work properly.

3.OC can work properly. OC is ideal for component mode based on dynamic libraries.

4.Swift Construction Bar object will crash. The status quo makes us very headache.

Results analysis

The design of C + + does not take into account the problem of binary compatibility, so compatibility is very general.

Java binary compatibility is very perfect, the object member changes, method additions and deletions, will not easily lead to binary compatibility issues. For more information, see: Chapter 13. Binary compatibility.

OC use methods and properties are used to distribute messages, add and delete methods, the order of moving methods will not cause problems, but also to change the member variables to support, so binary compatibility is perfect.

As a brand-new language, Swift's binary compatibility is the worst.

In addition, we also discussed that the C + + virtual function Change Order will not be problematic. In response to this question, I verified that the order of the functions in the C + + virtual function table depends entirely on the order in which the functions are declared in the header file.

For example Foo has func1 and FUNC2 two virtual functions, swap func1 and Func2 order, do not recompile main. Calling Func2 in main will actually call to Func1.

Reference articles

1.c++ ABI Compliance Checker

2.objective-c class member Variable depth analysis

3.Non Fragile Ivars

4.OBJC Source Code

5.Swift Library Binary Interface (ABI) compatibility research

The last of the last:

Golang is also a new language, I am very curious about the binary compatibility of this piece is how to consider, so welcome the vast number of young people to supplement a Golang version.