1494人阅读
Swift（36）
深入理解iOS开发中的BitCode功能前言做iOS开发的朋友们都知道,目前最新的Xcode7,新建项目默认就打开了bitcode设置.而且大部分开发者都被这个突如其来的bitcode功能给坑过导致项目编译失败,而这些因为bitcode而编译失败的的项目都有一个共同点,就是链接了第三方二进制的库或者框架,而这些框架或者库恰好没有包含bitcode的东西(暂且称为东西),从而导致项目编译不成功.所以每当遇到这个情况时候大部分人都是直接设置Xcode关闭bitcode功能,全部不生成bitcode.也不去深究这一开关背后隐藏的原理.中枪的请点个赞.LLVM是目前苹果采用的编译器工具链,Bitcode是LLVM编译器的中间代码的一种编码,LLVM的前端可以理解为C/C++/OC/Swift等编程语言,LLVM的后端可以理解为各个芯片平台上的汇编指令或者可执行机器指令数据,那么,BitCode就是位于这两者直接的中间码. LLVM的编译工作原理是前端负责把项目程序源代码翻译成Bitcode中间码,然后再根据不同目标机器芯片平台转换为相应的汇编指令以及翻译为机器码.这样设计就可以让LLVM成为了一个编译器架构,可以轻而易举的在LLVM架构之上发明新的语言(前端),以及在LLVM架构下面支持新的CPU(后端)指令输出,虽然Bitcode仅仅只是一个中间码不能在任何平台上运行,但是它可以转化为任何被支持的CPU架构,包括现在还没被发明的CPU架构,也就是说现在打开Bitcode功能提交一个App到应用商店,以后如果苹果新出了一款手机并CPU也是全新设计的,在苹果后台服务器一样可以从这个App的Bitcode开始编译转化为新CPU上的可执行程序,可供新手机用户下载运行这个App.历史回顾在iPhone出来之前,苹果主要的编译器技术是用经过稍微改进的GCC工具链来把Objective-C语言编写的代码编译出所指定的机器处理器上原生的可执行程序.编译器产生的可执行程序叫做&Fat Binaries&--类似于Windows下PE格式的exe和Linux下的ELF格式的二进制,不同的是,一个&Fat Binary&可以包含同一个程序的很多版本,所以同一个可执行文件可以在不同的处理器上运行.主要就是这个技术让苹果的硬件很容易的从PowerPC迁移到PowerPC64的处理器,以及后来再迁移到Intel和Intel64处理器.这个方案带来的负面影响就是同一个文件中存了多份可执行代码,除了当前机器可执行的那一份之外其他都是无用的,白占空间. 这个在市场上被称为&Universal Binary&,在苹果从PowerPC迁移到Intel处理器的事情开始存在的(一个二进制文件既包含一份PowerPC版本和一份Intel版本).慢慢的后来又支持同时包含Intel 32bit和Intel 64bit. 在一个Fat binary中,又操作系统运行时根据处理器类型动态选择正确的二进制版本来运行,但是应用程序要支持不同平台的处理器的话,应用程序本身要多占用一些空间.当然也有一些瘦身的工具,比如lipo,可以用来移除fat binary中那些当前机器中不被支持的或者多余的可执行代码达到瘦身目的,lipo不会改变程序执行逻辑,仅仅只是文件的大小瘦身.编译器现状随着移动设备移动互联网的深入发展,现在移动设备中的程序大小变得越来越重要了,主要是因为移动设备中不会有电脑上那么大的一个硬盘驱动器.还有就是苹果早就从原始的ARM处理器迁移到自家设计的A4,A5,A5X,A6,A7,A8,A8X,A9,A9X以及后续的A10处理器,他们的指令集已经发生了改变和原始ARM设计的有所区别,所有的这些变化都被iOS操作系统底层以及Xcode/LLVM编译工具向上层程序员一定程度的透明了,编译出来的程序会包含很多执行代码版本.当面对这个问题后,苹果投入大量成本迁移到LLVM编译器架构并使用bitcode的必要性越来越大.从最开始的把OPENGL编译为特定的GPU指令到把Clang编译器(LLCM的C/OC编译前端)支持Objective-C的改进并作为Xcode的默认编译器.LLVM提供了一个虚拟指令集机制,它可以翻译出指定的所支持的处理器架构的执行代码(机器码).这个就使得为iOS应用程序的编译开发一个完全基于LLVM架构的工具链成为可能.而LLVM的这个虚拟的通用的指令集可以用很多种表示格式:叫做IR的文本表示的汇编格式(像汇编语言);转换为二进制数据表示的格式(像目标代码),这个二进制格式就是我们所说的bitcode.Bitcode和传统的可执行指令集不同,他维护的是函数功能的类型和签名,比如,传统可执行指令集中,一系列(&=8)的布尔值可以压缩存储到单个字节中,但是在bitcode中他们是各自独自表示的.此外,逻辑运算操作(比如寄存器清零操作)也由他们对应的逻辑表示方法($R=0);当这些BitCode要转换为特定机器平台的指令集时,他可以用经过针对特定机器平台优化过的汇编指令来代替:xor eax, eax.(这个汇编指令同样是寄存器&eax&清零操作).然而bitcode他也不是完全独立于处理器平台和调用约定的.寄存器的大小在指令集中是一个相当重要的特性,众所周知,64bit寄存器可以比32bit寄存器存储更多的数据,生成64bit平台的bitcode和32bit平台的bitcode是明显不同的,还有,调用约定可以根据函数定义或者函数调用来定义,这些可以确定函数的参数传递是传寄存器值呢还是压栈. 一些编程语言还有一些像sizeof(long)这样的预处理指令,这些将在bitcode生成之前前被翻译.一般情况下,对于支持fastcc(fast calling convention)调用的64bit平台会生成与其一致的bitcode代码.苹果的要求到此,让我们思考一下,为什么苹果默认要求watchOS和tvOS的App要上传bitcode? 因为把bitcode上传到他自己的中心服务器后,他可以为目标安装App的设备进行优化二进制,减小安装包的下载大小,当然iOS开发者也可以上传多个版本而不是打包到单个包里,但是这样会占用更多的存储空间. 最重要的是允许苹果可以在后台服务器对应用程序进行签名,而不用导出任何密钥到终端开发者那.上传到服务器的bitcode给苹果带来更好处是: 以后新设计了新指令集的新CPU,可以继续从这份bitcode开始编译出新CPU上执行的可执行文件,以供用户下载安装.但是bitcode给开发者带来的不便之处就是: 没用bitcode之前,当应用程序奔溃后,开发者可以根据获取的的奔溃日志再配上上传到苹果服务器的二进制文件的调试符号表信息可以还原程序运行过程到奔溃时后调用栈信息,对问题进行定位排查.但是用了bitcode之后,用户安装的二进制不是开发者这边生成的,而是苹果服务器经过优化后生成的,其对应的调试符号信息丢失了,也就无法进行前面说的还原奔溃现场找原因了.目前,watchOS和tvOS应用发布必须上传带bitcode版本的包.iOS应用发布对bitcode的要求是可选的,用户可以在Xcode的项目设置中关闭. 相当于在编译的时候加一个标记:embed-bitcode-marker(调试构建) embed-bitcode(打包/真机构建).这个在clang编译器的参数是-fembed-bitcode,swift编译器的参数是-embed-bitcode.实践出真知我们还是应该实际弄两个测试代码进行实践和检验一下比较好.做两次测试,第一次准备两个C语言源代码继续测试;第二次把其中一个转变为汇编语言源代码后再一个C代码和一个汇编代码一起重复之前的测试步骤进行对比校验差异.1 . 如下两个全部是Objective-C代码:test.m :#import &Foundation/Foundation.h&
void greeting(void)
NSLog(@&hello world!&);
}demo.m :#import &Foundation/Foundation.h&
void demo(void)
NSLog(@&demo func&);
}用Clang编译成 ARM64 格式且带bitcode的目标文件test.o demo.o:wuqiong:~ apple$ xcrun -sdk iphoneos clang -arch arm64 -fembed-bitcode -c test.m demo.m然后把两个目标文件打包为一个静态库文件:wuqiong:~ apple$ xcrun -sdk iphoneos ar
-r libTest.a test.o demo.o
ar: creating archive libTest.a用Shell命令otool查看目标文件中是否包含bitcode段:wuqiong:~ apple$ otool -l test.o |grep bitcode
sectname __bitcode
sectname __bitcode如果看到输出了2行sectname __bitcode,就是说明这静态库中的两个目标文件包含了bitcode.2.下面把其中一个demo.m换成汇编语言再参与编译:用下面的命令把demo.m的C代码转换为ARM64汇编语言格式demo.s:wuqiong:~ apple$ xcrun -sdk iphoneos clang -arch arm64 -S demo.m
wuqiong:~ apple$ cat demo.s
__TEXT,__text,regular,pure_instructions
.ios_version_min 9, 2
.cfi_startproc
x29, x30, [sp,
.cfi_def_cfa w29, 16
.cfi_offset w30, -8
.cfi_offset w29, -16
x0, L__unnamed_cfstring_@PAGE
x0, x0, L__unnamed_cfstring_@PAGEOFF
x29, x30, [sp],
.cfi_endproc
__TEXT,__cstring,cstring_literals
&demo func&
__DATA,__cfstring
@_unnamed_cfstring_
L__unnamed_cfstring_:
___CFConstantStringClassReference
1992 0x7c8
__DATA,__objc_imageinfo,regular,no_dead_strip
L_OBJC_IMAGE_INFO:
.subsections_via_symbol然后删除demo.m这个C源代码,仅留下test.m和demo.s:wuqiong:~ apple$ rm demo.m现在,我们来把test.m这个C源代码和dmeo.s这个汇编源代码来一起带着-fembed-bitcode参数来生成目标代码并打包为一个静态库:wuqiong:~ apple$ xcrun -sdk iphoneos clang -arch arm64 -fembed-bitcode -c test.m demo.s
wuqiong:~ apple$ xcrun -sdk iphoneos ar -r libTest.a test.o demo.o然后我们再运行otool工具来检查这个新的静态库中包含的2个目标文件是否都带有bitcode段:wuqiong:~ apple$ ar -t libTest.a
__.SYMDEF SORTED
wuqiong:~ apple$ otool -l libTest.a | grep bitcode
sectname __bitcode很意外,这一次,只有一行sectname __bitcode输出,这就说明这两个目标文件,有一个不带有bitcode段,哪怕我们在编译的时候指定了参数-fembed-bitcode也没有用.至于具体是哪一个不带bitcode段,我们肯定知道就是那个从ARM64汇编语言编译过来的目标文件不带.那么就得出一个结论,bitcode的生成,是由汇编语言以上的上层语言编译而来,和最前面所说的那样,他是上层语言与汇编语言(机器语言)之间的一个中间码.目前我们日常的iOS应用开发中,一般不会需要用到汇编层面去优化的代码.所以我们主要关注第三方(开源)C代码,尤其是音视频编码解码这些计算密集型项目代码,关键计算的代码针对特定平台都有对应平台的汇编版本实现,当然也有C的实现,但是默认编译一般都是用的汇编版本,这样就会导致我们在编译这个开源代码的时候哪怕你带了-fembed-bitcode参数也仅仅只是让项目中的部分C代码的目标文件带了bitcode段,而那小数的汇编代码的目标文件一样不带bitcode段,这样编译出这个库交给上层开发者使用的时候,就会出现在打包上传或者真机调试的时候因为Xcode默认开了bitcode功能而链接失败,导致不能真机调试或者不能上传应用到AppStore.此文之初衷最近在辅导我戴维营战友们做手机音视频直播的App,调试的时候手机采集音视频,视频用h264编码,音频采用aac编码,通过RTMP协议往斗鱼直播频道发布媒体流,项目需要用FFMPEG和libx264两个开源项目,在编译为iOS框架库提供给学生用的时候,他们遇到了bitcode的问题,虽然可以采取直接关闭bitcode来避免错误,但是战友的求知欲必须满足,格物致知,必须让其知其究竟.libx264是VideoLan基金会管理的一个视频编解码的开源项目,其大量使用了各个平台的多媒体汇编指令进行了优化,在编译为不带bitcode的库的时候,完全按官方autotools编译方法是没有任何问题的;编译全带bitcode的库的时候我们不得不关闭汇编优化,在执行./configure阶段可以加上--disable-asm参数来禁用汇编.但是,这个选项在configure脚本中的实现机制有问题.导致其仍然调用了汇编的函数,但是汇编的代码却没有编译进去,从而会导致项目为真机构建和打包的链接阶段会爆出找不到符号的错误,这样就不能做到两全其美.出于轻微程度的强迫症影响,故把之前的FFMPEG和libx264项目的编译脚本进行了改进和打补丁.目前已经可以做到一键编译出带全部bitcode的FFMPEG和libx264的框架了.FFmpeg需要依赖libx264.自动编译脚本项目位置放在github:由于时间和篇幅原因,关于其他更多详细的信息就不细细道来了.
&&相关文章推荐
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1402685次
积分：15368
积分：15368
排名：第633名
原创：242篇
转载：300篇
译文：10篇
评论：299条
文章：22篇
阅读：53428
阅读：11418
文章：14篇
阅读：37718
文章：58篇
阅读：154901
(3)(3)(5)(4)(3)(4)(7)(15)(12)(16)(17)(5)(16)(13)(7)(10)(15)(8)(12)(18)(33)(8)(10)(3)(7)(3)(4)(5)(10)(9)(17)(27)(26)(22)(7)(1)(5)(2)(1)(1)(1)(3)(2)(3)(1)(1)(5)(2)(2)(1)(2)(2)(2)(3)(3)(14)(5)(16)(9)(15)(7)(16)(8)(1)(1)(1)(1)(21)(1)(4)(1)(1)(2)(3)(2)(1)(1)(4)(3)(1)独家揭秘：苹果的Bitcode计划为什么让英特尔悲喜交加-控制器/处理器-与非网
要求在WatchOS上开发的应用必须以的形式提供，意味着其有了更大的自主性。
苹果使令应用强制采用Bitcode形式提交的举动，将会为赢得iPhone和iPad下一代处理器业务带来机遇。
关于英特尔是否已经准备好或愿意做出相应的努力拿下苹果处理器业务，目前还无法得出结论。
一个不时搅动苹果和英特尔的投资者的热烈讨论是，英特尔的部门是否能够拿下苹果基于iOS系统的处理器业务。从英特尔投资者们的角度来看，这笔交易的逻辑坚如磐石：
1、移动和物联网是半导体行业未来发展的两大前沿阵地-英特尔未来的收入和利润增长与此息息相关。
2、英特尔赢得苹果SoC的代工业务将帮助验证x86可以成为一个成功的移动SoC架构。
3、在移动生态系统中，苹果独步天下，攫取了大部分行业利润，出货量市场份额大约15%左右，对英特尔而言，这是个很有分量的目标客户。
4、苹果在移动市场的成功将为低功耗SoC技术的持续创新提供坚实的物质保障，从而能为进军物联网市场提供跳板。
5、苹果坚持的高端设计非常适合采用英特尔业界领先的FinFET工艺。
6、强调公平的苹果也不大喜欢其竞争对手三星为其提供代工服务。
7、台积电虽然也很强大，但未必能够提供英特尔力所能及的先进芯片设计中的创新水平，所以台积电只能沦为第二选项。
将上面这些要素集合在一起来看，瞧，苹果和英特尔的合作简直就是天作之合，典型的双赢。苹果能够采用最先进的工艺，而且还能借助英特尔增加品牌影响力。英特尔则是在多个层面上受益，虽然利润率降低了，但其代工业务获得了继续发展壮大的动能和足够产能需求，这样一来，其收入和利润都能得到很大的提升，股东们也能欣喜地看到每股盈余的增长，何乐而不为呢？
现在一年时间近乎过半，而英特尔和苹果仍没有合作的迹象，发生了什么呢？他们之间还能搞出点事来吗？尽管在本网站和其它出版物上关于这个话题有各种各样的议论和言辞，但我们不得不承认，这个话题依然充满争议没有定论。坦率地讲，英特尔的粉丝们基本上都认为苹果使用英特尔的处理器是个好主意，他们所有的猜测也完全不会顾及苹果方面任何可证实的意向表达。在AppleInsider最近的一篇文章中，作者探讨了英特尔和苹果关系破裂的开端。
&英特尔CEO欧德宁曾这样提到：英特尔当年有意将其新的Core x86处理器出售给苹果用于其Mac电脑（同时为他们开发配套的芯片组），但是对为苹果的iPhone开发移动芯片并没有兴趣，至少以苹果想支付的价格和英特尔预计苹果的购买量来看，英特尔确实不大感冒。
显然，当年，他不相信英特尔专门为苹果的iPhone开发移动芯片能够覆盖开发成本，更无法盈利，主要是因为他并不认为苹果的iPhone能够大批量销售。&
好吧，有得必有失对吧？从那时起，英特尔为了在移动领域站稳脚跟，已经付出了几十亿美金的代价，它现在的Atom仍然落后于高通。苹果是给了英特尔一些Mac电脑处理器的业务（每年大约2000万片），但除此之外，再无瓜葛，苹果独立走上了属于自己的阳光大道。
这是怎样一条阳光大道呢。自2007年iPhone面世以来，苹果以其Ax系列处理器打造和开发了世界一流的ARM架构的SoC，就在最近，它又把这种专业经验扩展到苹果手表的处理器S1上。欧德宁未能预见到的&大批量&目前已经累计到了3亿 多片的数量。这笔丢掉的处理器业务对英特尔的潜在价值仍然无法估算，但至少也在将近百亿美金。而且，对英特尔而言，比这笔合约带来的盈利更重要的是，三星和台积电通过苹果订单赢得了一定的竞争优势。
且不论英特尔对拿下苹果业务的积极性和自身能力如何，苹果是否有兴趣把业务交给他们还是个问题。对苹果来说，这个阶段转向英特尔风险太大了。毕竟，现在有上亿的消费者在使用苹果应用商店中的140万个应用程序，这些app都是针对苹果设计的ARM架构CPU进行设计的。如果苹果要把这些app转移到基于英特尔x86指令集的系统上，这个风险将非常巨大。就现在情况而言，所有的应用需要被重新编译、测试和发布。除此之外，苹果公司辉煌的设计师团队，已经掌握了ARM指令集，并且能够在通用的ARM核之上构建苹果自己的处理器核，这时他们不得不重新学习一种新的语言(x86)，这种学习曲线得有多长呢？
现在假设苹果能够克服上述这些问题，英特尔能真的为苹果安排最佳的代工黄金时间吗？它确实真心如此？苹果能否信赖英特尔会永远把它放在第一位，放在最高的优先级（比数据中心还高）上？不要忘了，欧德宁在对iPhone体量的判断上犯了大错，但他在相对价格和对英特尔的盈利判断上是正确的。除了以传闻的200美金售价将其Mac用Core I5出售给苹果，该公司的SoC代工也表现不俗，平均每片SoC的价格为35美金。目前有传闻称台积电的A8处理器价格在25-30美金之间。对于一个将毛利润目标定在55-61%之间的公司来说，能达到35-40%就很幸运了。如果中间出了差错呢？在三星之外，苹果还有台积电和GlobalFoundries做其第二选择供应商。英特尔会在其高昂的FinFET 10nm工艺上再做第二手准备吗？
从上面的分析中我们能得到的结论：
苹果不急于转向英特尔是有非常充分的理由的。
很可能在不久的将来会有合适的机会，让苹果与英特尔深度合作。
为转向英特尔的x86打基础需要相当长的时间。
现在，让我们看看苹果实现与处理器架构的独立性走出的第一步。
在不久前的WWDC上，苹果提到了bytecode、p-code和bitcode这三个意思相同的词汇，它们指的是一个软件实体，它把开发者实现app采用的Swift或Objective C这类高层代码编译成与硬件无关的虚拟机器语言，然后再通过另一个程序编译成可在任何物理机器上运行的应用。重点是，苹果不希望自己被绑定在任何特定的硬件平台上，p-code就是实现这种硬件无关性的一种方式。自由、灵活、放大-所有这些奇妙的属性来自于这个'P'字。哈利路亚，终于自由了，下面是对苹果开发者的采访，里面提到了p-code的重要性：
他（苹果开发者）认为，如果苹果下一代iPhone处理器突然转换到英特尔的一款芯片上，在他这里，不需要什么工作，当天就能让原有的app运行起来。
关注与非网微信 ( ee-focus )
限量版产业观察、行业动态、技术大餐每日推荐
享受快时代的精品慢阅读
与非网小编
电子行业垂直媒体--与非网小编一枚，愿从海量行业资讯中淘得几粒金沙，与你分享！
高通与苹果的专利诉讼，苹果的制造商缘何也成了被告？
发表于： 11:18:46
高通方面认为，制造商们停止支付费用的原因，在于受到苹果公司逼迫。
发表于： 10:38:23
伴随5G商用的不断临近，类似的巨头间的纷争或恶斗预计还会持续上演，因为这毕竟是为下一个时代的影响力和话语权而搏杀。
发表于： 09:46:45
高通方面认为，制造商们停止支付费用的原因，在于受到苹果公司逼迫。
发表于： 08:50:45
据外媒Engadget今日报道，IBM的两个量子计算机平台在处理能力方面都取得了飞跃的成绩。该公司今日宣布，至目前为止功能最强大的两台量子计算机已经完成构建和测试成功。以研究和业务为重点的“Quantum Experience”通用计算机和原型处理器将最终构成“IBM Q”量子系统商用的核心。
发表于： 15:10:46
谷歌花了十年打造服务器中心，处理每日数十亿次的网络搜寻需求。 如今谷歌更进一步，自行研发专属芯片--Tensor Processing Units (TPU、见图)，加快机器学习脚步，并宣称TPU性能优于CPU、GPU。
发表于： 12:52:51
10nm工艺麒麟970芯片曝光 要被秒的节奏；
发表于： 12:20:46
NVIDIA公司是全球可编程图形处理技术领袖。与ATI（后被AMD收购）齐名，专注于打造能够增强个人和专业计算平台的人机交互体验的产品。
发表于： 09:56:46
国家信息中心与10家主要单车企业签署信用信息共享协议，通过加强信用信息共享、建立守信联合激励和失信联合惩戒机制
发表于： 08:31:26
开源是当今最热门的话题之一，也是未来的趋势，就像1998年时任微软CEO的鲍尔默痛斥Linux是癌症，而如今的CEO 却称&Microsoft love Linux&，因为开源&以人为本&，然而开源的商业化是一条必行却又难行的路。
如今的处理器、SoC基本被x86与ARM
发表于： 22:42:13
你是如何看待余承东反思的？ ……
21:00:00本节课讲基于STM32的幻彩灯的驱动程序编写，在实现驱动程序之后会设计几个简单的闪烁模式并实现。
19:00:00CANoe是德国Vector公司出的一款总线开发环境，全称叫CAN open environment，主要用于汽车总线的开发而设计的。CANoe的前期是为了对CAN通信网络进行建模、仿真、测试和开发，
21:00:00本次课程讲基于51的幻彩灯条的驱动程序编写，并设计实现几个简单的样式。
本系列课程主要围绕嵌入式研发工程师”众所周知”的从业历程分享进行,从线上实习到研发总监的各类项目工作经验分享。通过交流让大家了解相关的技术以及那个时代研发的部分情况，古今一辙，抛砖引玉，给人以灵感
小马哥新系列课程：幻彩灯驱动教程
第三讲：基于STM8S003F3的幻彩灯驱动程序编写该系列课程直播内容：
幻彩灯驱动教程第一讲：基于STM32F103的幻彩灯驱动程序编写（观看直播）
旗下网站：
与非门科技(北京)有限公司 All Rights Reserved.
京ICP证:070212号
北京市公安局备案编号： 京ICP备：号理解Bitcode：一种中间代码
招聘信息：
今天试着用Xcode 7 beta 3在真机(iOS 8.3)上运行一下我们的工程，结果发现工程编译不过。看了下问题，报的是以下错误：ld:&‘/Users/**/Framework/SDKs/PolymerPay/Library/mobStat/lib**SDK.a(**ForSDK.o)’&does&not&contain&bitcode.&You&must&rebuild&it&with&bitcode&enabled&(Xcode&setting&ENABLE_BITCODE),&obtain&an&updated&library&from&the&vendor,&or&disable&bitcode&for&this&target.&for&architecture&arm64得到的信息是我们引入的一个第三方库不包含bitcode。嗯，不知道bitcode是啥，所以就得先看看这货是啥了。Bitcode是什么？找东西嘛，最先想到的当然是先看官方文档了。在一节中，找到了下面这样一个定义：Bitcode is an intermediate representation of a compiled program. Apps you upload to iTunes Connect that contain bitcode will be compiled and linked on the App Store. Including bitcode will allow Apple to re-optimize your app binary in the future without the need to submit a new version of your app to the store.说的是bitcode是被编译程序的一种中间形式的代码。包含bitcode配置的程序将会在App store上被编译和链接。bitcode允许苹果在后期重新优化我们程序的二进制文件，而不需要我们重新提交一个新的版本到App store上。嗯，看着挺高级的啊。继续看，在中，还有一段如下的描述Bitcode. When you archive for submission to the App Store, Xcode will compile your app into an intermediate representation. The App Store will then compile the bitcode down into the 64 or 32 bit executables as necessary.当我们提交程序到App store上时，Xcode会将程序编译为一个中间表现形式(bitcode)。然后App store会再将这个botcode编译为可执行的64位或32位程序。再看看这两段描述都是放在App Thinning(App瘦身)一节中，可以看出其与包的优化有关了。喵大(@onevcat)在其博客中也描述了iOS 9中苹果在App瘦身中所做的一些改进，大家可以转场到那去研读一下。Bitcode配置在上面的错误提示中，提到了如何处理我们遇到的问题：You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture arm64要么让第三方库支持，要么关闭target的bitcode选项。实际上在Xcode 7中，我们新建一个iOS程序时，bitcode选项默认是设置为YES的。我们可以在”Build Settings”->”Enable Bitcode”选项中看到这个设置。不过，我们现在需要考虑的是三个平台：iOS，Mac OS，watchOS。对应iOS，bitcode是可选的。对于watchOS，bitcode是必须的。Mac OS不支持bitcode。如果我们开启了bitcode，在提交包时，下面这个界面也会有个bitcode选项：盗图，我的应用没办法在这个界面显示bitcode，因为依赖于第三方的库，而这个库不支持bitcode，暂时只能设置ENABLE_BITCODE为NO。所以，如果我们的工程需要支持bitcode，则必要要求所有的引入的第三方库都支持bitcode。我就只能等着公司那些大哥大姐们啥时候提供一个新包给我们了。题外话如上面所说，bitcode是一种中间代码。LLVM官方文档有介绍这种文件的格式，有兴趣的可以移步。参考
微信扫一扫
订阅每日移动开发及APP推广热点资讯公众号：CocoaChina
点击量10887点击量9070点击量6832点击量6807点击量6167点击量6133点击量5809点击量5585点击量5315
&2015 Chukong Technologies,Inc.
京公网安备89