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

1.貍貓換太子

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

2.簽名做了什么

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

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

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

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

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

3.傲嬌的iphone 6 plus

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

4.卡到天荒地老

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