I have problem with embedded bitcode term.
What is embedded bitcode?
When to enable, ENABLE_BITCODE
in new Xcode?
What happens to the binary when enabled, ENABLE_BITCODE
in Xcode 7 ?
相关问题
- CALayer - backgroundColor flipped?
- Core Data lightweight migration crashes after App
- Core Data lightweight migration crashes after App
- How can I implement password recovery in an iPhone
- State preservation and restoration strategies with
相关文章
- 现在使用swift开发ios应用好还是swift?
- UITableView dragging distance with UIRefreshContro
- Could I create “Call” button in HTML 5 IPhone appl
- TCC __TCCAccessRequest_block_invoke
- Where does a host app handle NSExtensionContext#co
- Unable to process app at this time due to a genera
- Swift - hide pickerView after value selected
- How do you detect key up / key down events from a
Bitcode refers to to the type of code: "LLVM Bitcode" that is sent to iTunes Connect. This allows Apple to use certain calculations to re-optimize apps further (e.g: possibly downsize executable sizes). If Apple needs to alter your executable then they can do this without a new build being uploaded.
This differs from: Slicing which is the process of Apple optimizing your app for a user's device based on the device's resolution and architecture. Slicing does not require Bitcode. (Ex: only including @2x images on a 5s)
App Thinning is the combination of slicing, bitcode, and on-demand resources
Apple Documentation on App Thinning
Since the exact question is "what does enable bitcode do", I'd like to give a few thin technical details I've figured out thus far. Most of this is practically impossible to figure out with 100% certainty until Apple releases the source code for this compiler
First, Apple's bitcode does not appear to be the same thing as LLVM bytecode. At least, I've not been able to figure out any resemblance between them. It appears to have a proprietary header (always starts with "xar!") and probably some link-time reference magic that prevents data duplications. If you write out a hardcoded string, this string will only be put into the data once, rather than twice as would be expected if it was normal LLVM bytecode.
Second, bitcode is not really shipped in the binary archive as a separate architecture as might be expected. It is not shipped in the same way as say x86 and ARM are put into one binary (FAT archive). Instead, they use a special section in the architecture specific MachO binary named "__LLVM" which is shipped with every architecture supported (ie, duplicated). I assume this is a short coming with their compiler system and may be fixed in the future to avoid the duplication.
C code (compiled with
clang -fembed-bitcode hi.c -S -emit-llvm
):LLVM IR output:
The data array that is in the IR also changes depending on the optimization and other code generation settings of clang. It's completely unknown to me what format or anything that this is in.
EDIT:
Following the hint on Twitter, I decided to revisit this and to confirm it. I followed this blog post and used his bitcode extractor tool to get the Apple Archive binary out of the MachO executable. And after extracting the Apple Archive with the xar utility, I got this (converted to text with llvm-dis of course)
The only notable difference really between the non-bitcode IR and the bitcode IR is that filenames have been stripped to just 1, 2, etc for each architecture.
I also confirmed that the bitcode embedded in a binary is generated after optimizations. If you compile with -O3 and extract out the bitcode, it'll be different than if you compile with -O0.
And just to get extra credit, I also confirmed that Apple does not ship bitcode to devices when you download an iOS 9 app. They include a number of other strange sections that I don't recognized like __LINKEDIT, but they do not include __LLVM.__bundle, and thus do not appear to include bitcode in the final binary that runs on a device. Oddly enough, Apple still ships fat binaries with separate 32/64bit code to iOS 8 devices though.
Basically this concept is somewhat similar to java where byte code is run on different JVM's and in this case the bitcode is placed on iTune store and instead of giving the intermediate code to different platforms(devices) it provides the compiled code which don't need any virtual machine to run.
Thus we need to create the bitcode once and it will be available for existing or coming devices. It's the Apple's headache to compile an make it compatible with each platform they have.
Devs don't have to make changes and submit the app again to support new platforms.
Let's take the example of iPhone 5s when apple introduced
x64
chip in it. Althoughx86
apps were totally compatible withx64
architecture but to fully utilise thex64
platform the developer has to change the architecture or some code. Once s/he's done the app is submitted to the app store for the review.If this bitcode concept was launched earlier then we the developers doesn't have to make any changes to support the
x64
bit architecture.As far as Bit code and enabling bit code is concerned, the first thing which is required to understand is the story from where all this started.
So, basically if I talk of ENABLE_BITCODE which is introduced in iOS 9, is a part of App Thinning process.
And it is a part of problem which answers "How did Apple manage to reduce the storage size of iOS 9 to 1GB from 5 GB in iOS 8?"
This is due to a new technology called 'App Thinning'
& what exactly is App Thinning ?
App Thinning brings down the iOS 9 OTA update from 4.6GB to 1.3GB, a 71% size reduction. Not only will this help with future OTA updates, but the technology will be available for developers to reduce the storage required by third party apps.
App thinning has basically three components namely- slicing, bitcode, and on-demand resources.
App Slicing: iOS apps are developed to run on a variety of devices, so they come with code to support all them, whether or not your particular device requires it. App Slicing will allow your device to download only those files required by our device. Example: you don't need the 3x iPhone 6 Plus assets if you're running a 4-inch model.
On-Demand Resources (ODRs): It works on the idea that an app probably doesn't need its entire library of resources at any given time, so parts of it can be downloaded or deleted as needed. Developers will be able to specify what code is needed at what times by tagging sections of code as ODRs. These portions will be automatically downloaded from the App Store when they are required and deleted when they won't be needed again.
Bitcode: It refers to an "intermediate representation" of an app that developers will upload to the App Store rather than a pre-compiled binary. This works hand-in-hand with App Slicing, allowing the bitcode to be compiled on demand as 32-bit or 64-bit, depending on the downloading device. This will also allow any compiler improvements made by Apple to be implemented automatically, rather than having developers resubmit their apps.
Update
Apple has clarified that slicing occurs independent of enabling bitcode. I've observed this in practice as well where a non-bitcode enabled app will only be downloaded as the architecture appropriate for the target device.
Original
More specifically:
The way I read this, if you support bitcode, downloaders of your app will only get the compiled architecture needed for their own device.
What is embedded bitcode?
According to docs:
Update: This phrase in "New Features in Xcode 7" made me to think for a long time that Bitcode is needed for Slicing to reduce app size:
However that's not true, Bitcode and Slicing work independently: Slicing is about reducing app size and generating app bundle variants, and Bitcode is about certain binary optimizations. I've verified this by checking included architectures in executables of non-bitcode apps and founding that they only include necessary ones.
Bitcode allows other App Thinning component called Slicing to generate app bundle variants with particular executables for particular architectures, e.g. iPhone 5S variant will include only arm64 executable, iPad Mini armv7 and so on.When to enable ENABLE_BITCODE in new Xcode?
What happens to the binary when ENABLE_BITCODE is enabled in the new Xcode?
From Xcode 7 reference:
Here's a couple of links that will help in deeper understanding of Bitcode: