公司這邊為了統(tǒng)一管理應(yīng)用證書(shū)跟應(yīng)用發(fā)布，搭建了一個(gè)iOS自動(dòng)打包平臺(tái)。iOS應(yīng)用打包使用了腳本來(lái)完成，核心是使用了蘋果提供的xcodebuild命令。使用腳本打包的確帶來(lái)了很大的方便，但在各個(gè)不同項(xiàng)目組使用的過(guò)程，就發(fā)現(xiàn)了各種各樣的坑，其中的原因包括腳本本身的缺陷、各個(gè)項(xiàng)目組形形色色的設(shè)置，當(dāng)然還包括蘋果公司。本文將不會(huì)對(duì)xcodebuild命令的使用進(jìn)行說(shuō)明，xcodbuild的使用可以參考網(wǎng)絡(luò)其它資料，本文主要對(duì)項(xiàng)目組使用打包平臺(tái)所遇到的各種問(wèn)題進(jìn)行總結(jié)，所有的故事匯集在一起，會(huì)讓你對(duì)蘋果公司應(yīng)用打包機(jī)制了解的更透澈。

1.貍貓換太子

有一天，項(xiàng)目組A給我打了個(gè)電話，說(shuō)他們的項(xiàng)目在打包平臺(tái)打出的ipa有問(wèn)題。具體情況是打包沒(méi)有報(bào)錯(cuò)，ipa也下載下來(lái)了，但發(fā)現(xiàn)除了測(cè)試手機(jī)外其它手機(jī)裝不了?，F(xiàn)象有點(diǎn)像是用了開(kāi)發(fā)證書(shū)一樣，他也是這樣懷疑的，問(wèn)我證書(shū)是不是弄錯(cuò)了。我登了打包電腦看了下，頁(yè)面上配置的證書(shū)是對(duì)的，又查看了一下打包的log，打印出來(lái)的證書(shū)配置也是對(duì)的。實(shí)在想不通，然后登錄了開(kāi)發(fā)者賬號(hào)看看，證書(shū)沒(méi)問(wèn)題，也是有效的，確認(rèn)不是配置跟證書(shū)有問(wèn)題之后，我把ipa下載下來(lái)，ipa其實(shí)就是一個(gè)zip文件，可以直接把它解壓查看其中的內(nèi)容。我打開(kāi)里面的證書(shū)，雙擊安裝了下，會(huì)提示覆蓋已有的證書(shū)，這時(shí)問(wèn)題就來(lái)了，竟然提示覆蓋另外一個(gè)證書(shū)，一個(gè)Ad命名帶通配符的證書(shū)。當(dāng)時(shí)我就無(wú)語(yǔ)了：這證書(shū)哪來(lái)的？我又在打包的log搜了下，沒(méi)有發(fā)現(xiàn)跟這證書(shū)相關(guān)的任何內(nèi)容。這時(shí)“貍貓換太子”這出戲閃現(xiàn)在腦邊，想想這換的還真是天衣無(wú)縫，中間怎么沒(méi)有看到任何破綻，有些像完美犯罪一樣。但又想想，肯定會(huì)留下蛛絲馬跡的，于是查了起來(lái)。首先這個(gè)證書(shū)是Ad命名的，說(shuō)明這是一個(gè)xcode自動(dòng)創(chuàng)建的證書(shū)，然后又是一個(gè)帶通配符的開(kāi)發(fā)證書(shū)，說(shuō)明xcode在某個(gè)時(shí)候偷偷創(chuàng)建的，打包的時(shí)候把它給打到ipa里面了。然后我就把本地的證書(shū)通配證書(shū)給刪除了，再用腳本跑了一下，果然報(bào)錯(cuò)：找不到證書(shū)。我就想著好好給你指定了一個(gè)證書(shū)不用，非要找一些亂七八糟的。仔細(xì)看了下log，發(fā)現(xiàn)archive竟然成功了，在第二步打ipa的時(shí)候報(bào)錯(cuò)了。我想著證書(shū)不是在arichive的時(shí)候就用了嗎，然后打開(kāi)了生成的archive，里面也有一個(gè)證書(shū)，安裝一下，竟然是我指定的正確的證書(shū)，一下就顛覆我三觀了。前面都沒(méi)問(wèn)題，怎么在打ipa那一步錯(cuò)了，把證書(shū)給換了。這里突然想起前些天剛好把蘋果打包命令升級(jí)了，用了帶plist參數(shù)的打包命令，立馬改了回去，發(fā)現(xiàn)一切都回歸正常，打出的ipa也是對(duì)的了。蘋果公司或許想把用戶體驗(yàn)做到最好，盡量簡(jiǎn)化用戶的操作，但這個(gè)在我已經(jīng)配置好的情況下還自動(dòng)創(chuàng)建、替換我的證書(shū)就有點(diǎn)過(guò)了，關(guān)鍵xcodebuild里面的細(xì)節(jié)你也不知道，也沒(méi)有其它可以替換的命令，市面上其它的工具一般都是在xcodebuild上面再包裝一下，冶標(biāo)不治本。蘋果的封閉所帶來(lái)問(wèn)題也顯而易見(jiàn)了。資料簡(jiǎn)單、說(shuō)明少、沒(méi)有替換產(chǎn)品，以后只能多注意這種問(wèn)題。

2.簽名做了什么

蘋果使用證書(shū)來(lái)對(duì)應(yīng)用簽名，保障了應(yīng)用來(lái)源的合法性，在安全性上的確有很大提高。但另外一方面，由于iphone對(duì)應(yīng)用簽名的檢查機(jī)制并不清晰，有時(shí)遇到因?yàn)楹灻灰恢聦?dǎo)致安裝不了應(yīng)用的情況。蘋果在簽名的時(shí)候到底做了什么事情呢？

ipa目錄下有一個(gè)_CodeSignature目錄，其中的CodeResources文件記錄了當(dāng)前應(yīng)用所有的資源校驗(yàn)的信息，其中應(yīng)該使用了數(shù)字簽名及資源檢驗(yàn)兩種技術(shù)，每個(gè)資源文件會(huì)生成一個(gè)對(duì)應(yīng)的字符串，如下圖所示：

手機(jī)在安裝應(yīng)用的時(shí)候會(huì)根據(jù)codesignature進(jìn)行檢驗(yàn)，通過(guò)對(duì)比資源與校驗(yàn)結(jié)果來(lái)判斷資源是否被修改。這個(gè)是在網(wǎng)上傳的比較廣的說(shuō)法。在此之前，我也一直簡(jiǎn)單以為簽名只是一個(gè)CodeResources的文件。當(dāng)我遇到多target打包的時(shí)候，因?yàn)槎鄠€(gè)target只是BundleID跟簽名的問(wèn)題，然后通過(guò)一行命令無(wú)法實(shí)現(xiàn)設(shè)置兩個(gè)BundleID與簽名，就想通過(guò)一些方法來(lái)繞過(guò)，卻行不通，才發(fā)現(xiàn)簽名并沒(méi)有之前想的那么簡(jiǎn)單，多了一步。

其實(shí)有一個(gè)辦法可以非常簡(jiǎn)單地知道簽名那一步做了什么，就想一個(gè)問(wèn)題：如果我要替換一個(gè)證書(shū)，簽名之后的結(jié)果有什么區(qū)別。在前面貍貓換太子那當(dāng)中我已經(jīng)知道在使用xcodebuild export那一步的時(shí)候可以替換證書(shū)。于是使用diffMerge來(lái)比較替換證書(shū)之后的兩個(gè)文件夾，看看有什么區(qū)別。下面在export那一步替換了證書(shū)A與B之后使用diffMerge查看的結(jié)果：

CodeResources兩者不一樣，這在意料之中。驚奇發(fā)現(xiàn)二進(jìn)制文件hello竟然也不一樣，這是怎么回事？如果你使用過(guò)codesign –vvvv –d hello.app查看應(yīng)用的簽名信息，你會(huì)發(fā)現(xiàn)，如果你把傳入的目錄改成hello.app/hello二進(jìn)制文件，上述的命令也能正確執(zhí)行，可能某幾項(xiàng)會(huì)缺失，但你卻可以看到證書(shū)的信息。由此可以知道，簽名在給每個(gè)資源計(jì)算簽名值之前，會(huì)先將證書(shū)的信息寫(xiě)入到二進(jìn)制文件當(dāng)中，然后再進(jìn)行簽名。

3.傲嬌的iphone 6 plus

使用打包命令在帶來(lái)方便的同時(shí)，也帶來(lái)了很多問(wèn)題。腳本里面可以設(shè)置的參數(shù)是畢竟是有限的，很多參數(shù)是需要在項(xiàng)目工程里面來(lái)配置。當(dāng)兩者出現(xiàn)了沖突或者有不一致的時(shí)候，就有可能帶來(lái)問(wèn)題，再加上蘋果公司給打包套了個(gè)黑盒子，內(nèi)部細(xì)節(jié)不對(duì)外暴露，出現(xiàn)的問(wèn)題更讓人難以捉摸。傲嬌的iphone 6 plus就是遇到的問(wèn)題之一。某天A項(xiàng)目組給我發(fā)郵件了，說(shuō)他們項(xiàng)目的ipa在iphone 6 plus上無(wú)法安裝，其它手機(jī)能夠正常安裝使用。我當(dāng)時(shí)就懵了，xcode也沒(méi)聽(tīng)說(shuō)有什么配置會(huì)使得某個(gè)型號(hào)的手機(jī)無(wú)法安裝啊。由于沒(méi)有測(cè)試機(jī)，就去A項(xiàng)目組那邊查看具體情況，負(fù)責(zé)人向我演示了一下，他那個(gè)iphone 6 plus在安裝的時(shí)候就會(huì)失敗，entitlement不一致什么的。雖然看到了結(jié)果，但還是沒(méi)有頭緒，也不可能把iphone給拆了，關(guān)鍵拆了你也不知道里面是怎么檢查的。實(shí)在沒(méi)辦法，只能把他們的項(xiàng)目拉下來(lái)自己進(jìn)行對(duì)比，檢查了大半天，只發(fā)現(xiàn)他們?cè)诠こ膛渲玫?/span>bundleid跟打包平臺(tái)上配置的不一樣，在生成的ipa當(dāng)中，info.plist當(dāng)中的bundleid跟打包平臺(tái)上配置的不一致。然后讓他們先改了再打包一次，確認(rèn)了ipa的info.plist沒(méi)問(wèn)題之后再讓他們安裝，結(jié)果奇了，安裝上了。我當(dāng)時(shí)以為是跟系統(tǒng)版本有關(guān)系，然后問(wèn)了一下，是9.2的系統(tǒng)，但之前其它型號(hào)的手機(jī)也是9.2的，安裝也沒(méi)問(wèn)題，但說(shuō)明跟機(jī)型還是有很大關(guān)系。最后雖然解決了這個(gè)問(wèn)題，但感覺(jué)還是挺無(wú)語(yǔ)的，因?yàn)闆](méi)有各種型號(hào)的測(cè)試機(jī)，如果各種細(xì)節(jié)問(wèn)題跟機(jī)型有關(guān)系那就很難處理了。不過(guò)另外一方面也要求打包平臺(tái)上的項(xiàng)目配置盡可能規(guī)范，保持一致性，只能不斷積累，盡量避免這類問(wèn)題。

4.卡到天荒地老

打包平臺(tái)在最初使用的時(shí)候會(huì)遇到有些項(xiàng)目在運(yùn)行腳本的時(shí)候會(huì)卡住，剛執(zhí)行到xcodebuild命令時(shí)就卡在那邊沒(méi)動(dòng)靜了，直到天荒地老。最初主要的原因是工程的scheme沒(méi)有選中為shared，xcodebuild找不到scheme，但也不報(bào)錯(cuò)，然后就一直停在那邊，這個(gè)問(wèn)題在xcode舊版本上會(huì)出現(xiàn)，最新的7.X版本我測(cè)試了沒(méi)有再發(fā)現(xiàn)這個(gè)問(wèn)題。每次遇到這種問(wèn)題的時(shí)候都會(huì)提醒項(xiàng)目組將shared選上就能解決。但某一天卻遇到一個(gè)特別奇怪的現(xiàn)象，在提醒了項(xiàng)目組將shared選上之后，提交上來(lái)的代碼依然不能打包，運(yùn)行會(huì)卡住。我把他們的工程拉到自已電腦上，直接用腳本打包發(fā)現(xiàn)不行。然后打開(kāi)他們的工程，確認(rèn)是否選中shared，發(fā)現(xiàn)選上。然后再用腳本打包了下，竟然發(fā)現(xiàn)又能正常打包了。通過(guò)不斷測(cè)試，發(fā)現(xiàn)這樣的規(guī)律，工程直接拉下來(lái)，打包失敗，卡住，用xcode打開(kāi)工程后不做任何處理，再次打包就能成功。雖然從表面上看我只是用xcode打開(kāi)了工程而已，什么也沒(méi)有做，但實(shí)際上并沒(méi)有這么簡(jiǎn)單。當(dāng)時(shí)我就懷疑xcode在后面默默做了一些事情，只是沒(méi)看到而已。為了印證自己的想法，就通過(guò)svn來(lái)查看打開(kāi)工程之后文件的變化，最終發(fā)現(xiàn)打開(kāi)工程后會(huì)在*.xcodeproj目錄下創(chuàng)建xcshareddata/xcschemes目錄，這個(gè)是在選中shared的時(shí)候會(huì)創(chuàng)建該目錄及文件，項(xiàng)目組的svn上并沒(méi)有將該文件上傳上來(lái)。xcode默認(rèn)應(yīng)該有一套糾錯(cuò)機(jī)制，檢測(cè)到缺失后自動(dòng)創(chuàng)建了目錄文件。而在xcode打開(kāi)之前使用腳本打包的時(shí)候就會(huì)發(fā)現(xiàn)缺少的shared的信息，導(dǎo)致打包失敗。然后就讓項(xiàng)目組把缺少的目錄及文件都提交到svn上也就解決了這個(gè)問(wèn)題。注意，現(xiàn)在xcode7.X在打包時(shí)不會(huì)有這種問(wèn)題了，我本來(lái)想重現(xiàn)下這個(gè)現(xiàn)象，卻發(fā)現(xiàn)在最新的xcode7.X上沒(méi)能做到。現(xiàn)在寫(xiě)在這里也是想提醒xcode本身有一套處理機(jī)制，打開(kāi)工程并沒(méi)有想像的簡(jiǎn)單，遇到這類問(wèn)題就做文件比較吧，svn還有這種功用。