Xcode 14弃用比特码 - 但是为什么呢？
xcode 14 beta发行笔记感谢年度WWDC。
las，现在对比特码进行了弃用，如果您尝试启用它，您将收到警告消息。
我想知道，为什么会发生这种情况？使用比特码有缺点吗？苹果维持它是否有些痛苦？现在如何运作Per-Iphone模型汇编？
Xcode 14 Beta release notes are out, all thanks to the annual WWDC.
And alas, the Bitcode is now deprecated, and you'll get a warning message if you attempt to enable it.
And I was wondering, why has this happened? Was there any downside to using Bitcode? Was it somehow painful for Apple to maintain it? And how will per-iPhone-model compilation operate now?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Bitccode实际上只是LLVM中间语言。当您使用LLVM工具链编译源代码时，将源代码转换为中间语言，名为BitCode。然后，对此比特码进行分析，优化并最终转换为所需目标CPU的CPU指令。
这样做的优点是，所有基于LLVM的前端（如Clang）只需要将源代码转换为比特代码，从那里则可以使用相同的源语言，无论是LLVM工具链都不关心是否生成了比特码来自C，C ++，OBJ-C，Rust，Swift或任何其他源语言；一旦有比特代码，其余的工作流程始终相同。
比特码的好处是，您稍后可以在另一个CPU的生成指令上，而无需重新编译原始源代码。例如，我可以将C代码编译到比特代码，并使LLVM最后生成X86 CPU的运行二进制文件。但是，如果我保存了比特码，稍后我可以在告诉llvm上从该比特码创建ARM CPU的运行二进制文件，而无需编译任何内容，而无需访问原始C代码。生成的臂法将就像我从一开始就已经编译了臂。
没有比特码，我将不得不将x86代码转换为ARM代码，并且这种翻译会产生更糟糕的代码，因为代码的原始意图通常在CPU代码的最终编译步骤中丢失，这也涉及CPU特定的优化对于其他CPU的感觉，而比特码保留了原始意图，并且仅执行所有CPU都会受益的优化。
拥有所有应用程序的比特代码允许Apple重新编译该特定CPU的比特代码，以使应用程序与其他类型的CPU兼容或完全不同的架构，或者只是从更新的编译器版本的更好优化中受益。例如，如果苹果明天寄出了使用RISC-V而不是ARM CPU的iPhone，那么所有带有比特码的应用程序都可以重新编译为RISC-V，并且尽管该应用程序的作者从未有过，但仍将对新的CPU体系结构进行本地支持。甚至听说过RISC-V。
我认为这就是为什么Apple想要所有以比特码格式的应用程序的想法。但是这种方法首先有问题。一个问题是，比特码不是冷冻格式，LLVM在每个版本中都会对其进行更新，并且不能保证向后兼容。从来没有打算比特码是永久存储或档案的稳定表示。另一个问题是您不能使用汇编代码，因为没有对汇编代码发射任何比特码。另外，您不能使用没有比特码的预先构建的第三方库。
最后但并非最不重要的一点是：到目前为止，Afaik Apple从未使用过任何比特码优势。尽管过去要求所有应用程序都包含比特码，但这些应用程序还必须为所有受支持的CPU和Apple包含前构建脂肪二进制文件，而Apple总是只仅运送该构建前代码。例如，对于以前的iPhone，您曾经有32位ARMV7和64位ARM64版本以及比特码，并且在应用程序稀疏期间，Apple将删除32位或64位版本，以及BitCode，然后运送什么剩下的。很好，但是如果没有比特码，他们也可以这样做。不需要比特码将脂肪二进制的体系结构稀释！
需要比特码重建不同的体系结构，但是Apple从未做到这一点。没有32位应用程序通过重新编译比特码神奇地变为64位。随着Apple按需重新编译Bitsode，No 64位仅在32位系统上神奇地使用。作为开发人员，我可以向您保证，iOS App Store始终交付了您已构建和签名的二进制代码，并且从未通过BitCode创建的任何代码，因此没有任何服务器端得到优化。即使苹果从英特尔切换到M1，也没有MacOS应用神奇地转换为本机ARM，尽管App Store中的所有X86应用程序都可以使用该Apple，但Apple都有该X86应用程序。取而代之的是，Apple仍将X86版本运行并在Rosetta 2中运行。
因此，通过强迫所有代码作为比特代码可用，然后不使用任何优点BitCode会使您有点毫无意义。现在，所有平台都迁移到ARM64，并且在几年后，甚至不再有脂肪的二进制文件（一旦X86对Mac的支持已删除），那么继续使用这些东西有什么意义？我想苹果一劳永逸地埋葬了这个想法。即使有一天他们将RISC-V添加到其平台中，开发人员仍然可以同时运送含有ARM64和RISC-V代码的脂肪二进制文件。该概念运行得足够好，更简单，除了“较大的二进制文件”以外，没有其他缺点，这是服务器端应用程序稀疏可以解决的问题，因为在下载时只需要包括当前平台的代码。
Bitccode is actually just the LLVM intermediate language. When you compile source code using the LLVM toolchain, source code is translated into an intermediate language, named Bitcode. This Bitcode is then analyzed, optimized and finally translated to CPU instructions for the desired target CPU.
The advantage of doing it that way is that all LLVM based frontends (like clang) only need to translate source code to Bitcode, from there on it works the same regardless the source language as the LLVM toolchain doesn't care if the Bitcode was generated from C, C++, Obj-C, Rust, Swift or any other source language; once there is Bitcode, the rest of the workflow is always the same.
One benefit of Bitcode is that you can later on generate instructions for another CPU without having to re-compile the original source code. E.g. I may compile a C code to Bitcode and have LLVM generate a running binary for x86 CPUs in the end. If I save the Bitcode, however, I can later on tell LLVM to also create a running binary for an ARM CPU from that Bitcode, without having to compile anything and without access to the original C code. And the generated ARM code will be as good as if I had compiled to ARM from the very start.
Without the Bitcode, I would have to convert x86 code to ARM code and such a translation produces way worse code as the original intent of the code is often lost in the final compilation step to CPU code, which also involves CPU specific optimizations that make no sense for other CPUs, whereas Bitcode retains the original intent pretty well and only performs optimization that all CPUs will benefit from.
Having the Bitcode of all apps allowed Apple to re-compile that Bitcode for a specific CPU, either to make an App compatible with a different kind of CPU or an entirely different architecture or just to benefit from better optimizations of newer compiler versions. E.g. if Apple had tomorrow shiped an iPhone that uses a RISC-V instead of an ARM CPU, all apps with Bitcode could have been re-compiled to RISC-V and would natively support that new CPU architecture despite the author of the app having never even heard of RISC-V.
I think that was the idea why Apple wanted all Apps in Bitcode format. But that approach had issues to begin with. One issue is that Bitcode is not a frozen format, LLVM updates it with every release and they do not guarantee full backward compatibility. Bitcode has never been intended to be a stable representation for permanent storage or archival. Another problem is that you cannot use assembly code as no Bitcode is emitted for assembly code. Also you cannot use pre-built third party libraries that come without Bitcode.
And last but not least: AFAIK Apple has never used any of the Bitcode advantages so far. Despite requiring all apps to contain Bitcode in the past, the apps also had to contain pre-build fat binaries for all supported CPUs and Apple would always only just ship that pre-build code. E.g. for iPhones you used to once have a 32 Bit ARMv7 and a 64 Bit ARM64 version, as well as the Bitcode and during app thinning, Apple would remove either the 32 Bit or the 64 Bit version, as well as the Bitcode, and then ship whats left over. Fine, but they could have done so also if no Bitcode was there. Bitcode is not required to thin out architectures of a fat binary!
Bitcode would be required to re-build for a different architecture but Apple has never done that. No 32 Bit app magically became 64 bit by Apple re-compiling the Bitcode. And no 64 bit only app was magically available for 32 bit systems as Apple re-compiled the Bitcode on demand. As a developer, I can assure you, the iOS App Store always delivered exactly the binary code that you have built and signed yourself and never any code that Apple has themselves created from the Bitcode, so nothing was server side optimized. Even when Apple switched from Intel to M1, no macOS app magically got converted to native ARM, despite that would have been possible for all x86 apps in the app store for that Apple had the Bitcode. Instead Apple still shipped the x86 version and let it run in Rosetta 2.
So imposing various disadvantages onto developers by forcing all code to be available as Bitcode and then not using any of the advantages Bitcode would give you kinda makes the whole thing pointless. And now that all platforms migrated to ARM64 and in a couple of years there won't even be fat binaries anymore (once x86 support for Mac has been dropped), what's the point of continuing with that stuff? I guess Apple took the chance to bury that idea once and for all. Even if they one day add RISC-V to their platforms, developers can still ship fat binaries containing ARM64 and RISC-V code at the same time. This concept works well enough, is way simpler, and has no downsides other than "bigger binaries" and that's something server side app thinning can fix, as during download only the code for the current platform needs to be included.
Apple Watch Series 3是最后一款不支持64位的设备。 （即i386或ARMV7）
苹果现在已经停止支持Apple Watch系列3。[1]他们很乐意放弃对比特码的支持。
[1] https：//www.xda-- developers.com/watchos-9-not-coming-papple-watch-series-3
Apple Watch Series 3 was the last device to not support 64-bit. (i.e. i386 or armv7)
Apple has now stopped supporting the Apple Watch Series 3. [1] They would have been happy to drop support for bitcode.
[1] https://www.xda-developers.com/watchos-9-not-coming-apple-watch-series-3
比特码始终毫无意义，即使您将比特码编译为另一个体系结构，由于ABI是不同的，它实际上也无法正常工作。例如，当您编译C程序时，LIBC标头实际上都不同于每个体系结构。我很高兴他们终于摆脱了它，因为它造成了比解决的更多问题。他们最多可以做到的是将二进制型重新优化，以便相同的架构或相似的体系结构。还有一个问题的问题是，在比特码构建中泄漏的符号泄漏，因此您要么必须重命名/混淆这些符号，要么被碰撞击中（如果您是库/框架供应商，则大问题）。
Bitcode was always pointless, as even if you compiled bitcode to another architecture, there's high chance it won't actually work because the ABI is different. For example, when you compile C program, the libc headers actually are different for every architecture. I'm glad they are finally getting rid of it, as it caused more problems than solved. At most they could've done is re-optimize the binary for the same architecture, or similar enough architecture. There is also the problem of unwanted symbols leaking in bitcode builds, so you either have to rename/obfuscate those or get hit by collisions (big problem if you are a library/framework vendor).
XCode删除ARMV7/ARMV7S/I386目标支持。比特码用于构建不同的CPU目标。但是现在所有设备都可能是ARM64。现在，不再使用开发人员使用这项技术。如此弃用也许是明智的选择
xcode remove armv7/armv7s/i386 targets support. bitcode use for build different cpu targets. but now all devices might be arm64 . and now no more developer use this tech. so deprecated maybe a wise choice