iOS 開發-Certificate、App ID和Provisioning Profile之間的關係

模擬器調試的時候有的時候不能檢驗出程序在真實手機上的差異,若是須要進行真機測試或者發佈應用到App Store上去的時候, 公司若是沒有開發過App,你能夠從頭開始弄,大部分都是後來接手的,那麼當咱們進入https://developer.apple.com/account/ios/profile/profileList.action網站的時候咱們可能會有一些迷茫,會看到以下圖片"
ios

能夠很容易的發現這樣的幾個東西。xcode

 

Devices是設備,不須要解釋,每一個開發者帳號能夠關聯100臺設備,能夠經過xcode直接添加你的設備,Certificate、App  ID和Provisioning Profile不是那麼好理解。 安全

Certificate(證書)

證書是你有權利開發的憑證,是開發者的一種標識,至關於身份證,一個開發者帳號只有一套。一套含兩個,Development和Distribution(也就是Production)。app

其中Development證書提供開發者在電腦上真機調試的權限,能夠製做多個副本分發到多臺電腦。測試

Distribution證書給開發者提供發佈ios程序的權限,也就是說有了這個,你就有權力發佈程序到App Store去了。只有一個,不能製做副本分發到多臺電腦。網站

下面是證書的分類信息:(括號內爲證書有效期)加密

  • Development
    • App Development (1年):用來開發和真機調試應用程序。
    • Push Development (1年):用來調試Apple Push Notification
  • Production
    • In-House and Ad Hoc (3年):用來發布In-House和AdHoc的應用程序。spa

    •  

         App Store :用來發布提交App Store的應用程序。
    • MDM CSR
    • Push Production (1年):用來在發佈版本中使用Apple Push Notification。
    • Pass Type ID Certificate
    • Website Push ID Certificate

申請一個Certificate以前,須要先申請一個Certificate Signing Request (CSR) 文件,而這個過程當中其實是生成了一對公鑰和私鑰,保存在你Mac的Keychain中。代碼簽名正是使用這種基於非對稱祕鑰的加密方式,用私鑰進行簽名,用公鑰進行驗證。以下圖所示,在你Mac的keychain的login中存儲着相關的公鑰和私鑰,而證書中包含了公鑰。你只能用私鑰來進行簽名,因此若是沒有了私鑰,就意味着你不能進行簽名了,因此就沒法使用這個證書了,此時你只能revoke以前的證書再申請一個。所以在申請完證書時,最好導出並保存好你的私鑰。當你想與其餘人或其餘設備共享證書時,把私鑰傳給它就能夠了。私鑰保存在你的Mac中,而蘋果生成的Certificate中包含了公鑰。當你用本身的私鑰對代碼簽名後,蘋果就能夠用證書中的公鑰來進行驗證,確保是你對代碼進行了簽名,而不是別人冒充你,同時也確保代碼的完整性等。 調試

 

App ID

 App ID用於標識一個或者一組App,App ID應該是和Xcode中的Bundle ID是一致的或者匹配的。App ID主要有如下兩種: code

  • Explicit App ID:惟一的App ID,這種App ID用於惟一標識一個應用程序,例如com.cnblogs.keso,標識Bundle ID爲com.cnblogs.keso的程序。
  • Wildcard App ID:通配符App ID,用於標識一組應用程序。例如*能夠表示全部應用程序,而com.ABC.*能夠表示以com.ABC開頭的全部應用程序。

 每建立一個App ID,咱們均可以設置該App ID所使用的APP Services,也就是其所使用的額外服務。每種額外服務都有着不一樣的要求,例如,若是要使用Apple Push Notification Services,則必須是一個explicit App ID,以便能惟一標識一個應用程序。下面是目前全部可選的服務和相應的配置要求。

Provisioning Profile

 一個Provisioning Profile文件包含了上述的全部內容:證書、App ID、設備。

試想一下,若是咱們要打包或者在真機上運行一個應用程序,咱們首先須要證書來進行簽名,用來標識這個應用程序是合法的、安全的、完整的等等;而後須要指明它的App ID,而且驗證Bundle ID是否與其一致;再次,若是是真機調試,須要確認這臺設備可否用來運行程序。而Provisioning Profile就把這些信息所有打包在一塊兒,方便咱們在調試和發佈程序打包時使用,這樣咱們只要在不一樣的狀況下選擇不一樣的profile文件就能夠了。並且這個Provisioning Profile文件會在打包時嵌入.ipa的包裏。

例如,以下圖所示,一個用於Development的Provisioning Profile中包含了該Provisioning Profile對應的App ID,可以使用的證書和設備。這意味着使用這個Provisioning Profile打包程序必須擁有相應的證書,而且是將App ID對應的程序運行到Devices中包含的設備上去。

如上所述,在一臺設備上運行應用程序的過程以下:

與證書同樣,Provisioning Profile也分爲Development和Distribution兩種:

(注:前面提到不一樣帳戶類型所能建立的證書種類不一樣,顯然Profile文件的種類是和你所能建立的證書種類相關的)

  • Development (1年)
  • Distribution (1年)
    • In House
    • Ad Hoc
    • App Store

In House 與Ad Hoc的不一樣之處在於:In House沒有設備數量限制,而Ad Hoc是用來測試用的,Ad Hoc的包只能運行在該帳戶內已登記的可用設備上,顯然是有最多100個設備的數量限制。因此這兩種Provisioning Profile文件的區別就在於其中的設備限制不同而已,而他們所使用的Certificate是相同的。

 開發/發佈流程

 進行Development開發主要有如下幾個步驟:

  • 申請證書
  • 加入設備
  • 生成Provisioning Profile
  • 設置Xcode Code Sign Identifer

事實上第三步一般是不須要的,由於咱們一般都是用Xcode生成和管理的iOS Team Provisioning Profile來進行開發,由於它很是方便,因此不須要本身手動生成Provisioning Profile。

iOS Team Provisioning Profile是第一次使用Xcode添加設備時,Xcode自動生成的,它包含了Xcode生成的一個Wildcard App ID(*,匹配全部應用程序),帳戶裏面全部的Devices和全部Development Certificates,以下圖所示。所以,team中的全部成員均可以使用這個iOS Team Provisioning Profile在team中的全部設備上調試全部的應用程序。而且當有新設備添加進來時,Xcode會更新這個文件。

相關文章
相關標籤/搜索