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

1.貍貓換太子

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

2.簽名做了什么

蘋果使用證書來對應用簽名，保障了應用來源的合法性，在安全性上的確有很大提高。但另外一方面，由于iphone對應用簽名的檢查機制并不清晰，有時遇到因為簽名不一致導致安裝不了應用的情況。蘋果在簽名的時候到底做了什么事情呢？

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

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

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

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

3.傲嬌的iphone 6 plus

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

4.卡到天荒地老

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