zoukankan      html  css  js  c++  java
  • 【转】 iOS开发之打包上传到App Store——(一)各种证书的理解

    OK,有日子没写iOS开发的相关文章啦,主要是最近的精力都没在这上面,不过既然产品已经快要出来了,就有必要了解一下各种证书啥的(众所周知iOS的一堆证书可是很让人头大呀),最近确实被这个搞得头大,然后就决定参考网上的一些资料,进行一下整理,留作一个备份。

    内容参考自:苹果所有常用证书,appID,Provisioning Profiles配置说明及制作图文教程 

        理解Certificate、App Id、Identifiers 和 Provisioning Profile

    在我们平常的开发过程中,可以使用模拟器进行调试,也可以直接使用真机测试,真机测试的话,证书的申请也是相对容易的多,但是当我们要实际打包发布程序到App Store时,那个证书真叫一个头疼。

    首先,我们打开https://developer.apple.com/account/ios/profile/profileList.action,看下左边:

    可以看到有这么几个选项。其中,Devices指的是团队(公司账号是可以以Team的形式添加多个成员的)中的设备,每个开发者账号(不论公司还是个人)可以关联100台设备,可以通过在苹果开发者控制台中添加,也可以通过Xcode直接添加设备。

    然后,我们今天的重点目标是各类的证书啊、App ID啊还有Provisioning Profile啥的,所以重点理解一下这几个。

    Certificate(证书)

    证书指的是由苹果颁发(先交钱后发货的说)给你的证明你有权利进行iOS开发(不买证书你就只能用模拟器的说)并且可以将你开发的应用上传到App Store(么有证书估计只能自己做越狱开发)的一个凭证,表示你是一个开发者,就跟护照啊、身份证啊啥的一样。一个开发者账号只有一套,这个套装里呢包含两个证书,一个是Development证书,也就是所谓的开发证书,凭借这个证书你可以进行开发和真机调试(么有这个就只能用模拟器啦);另一个是Distribution证书,也叫Production证书,即所谓的分发证书或者说生产证书。其中呢,Development证书可以制作多个副本分发到多台设备,但是Distribution证书只能有一个,不能制作副本分发到多台电脑。
     
    下面大致介绍一下证书的种类以及分别包含的子分类啥的:
    • Development
      • App Development (1年):用来开发和真机调试应用程序。
      • Push Development (1年):用来调试Apple Push Notification
    • Production
      • In-House and Ad Hoc (3年):用来发布In-House和AdHoc的应用程序。

      •     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)文件,这个过程呢,实际上是生成了一对公钥和私钥,保存在我们电脑上的钥匙串中。代码的签名也就是使用这种基于非对称密钥的加密方式,用私钥进行签名,用公钥进行验证。如下图:
    我们的钥匙串中存储着相关的公钥和私钥,而证书里则包含了公钥。我们只能使用私钥来进行签名,如果不小心把私钥弄丢了,那么就表示这个证书基本上已经被咔嚓了,不要怕不要慌,你只是不能签名了而已,解决的办法就是revoke掉已经咔嚓了的证书,再重新申请一个,不过由此带来的麻烦可也是不少,所以可见备份的重要性啊,在申请完证书的时候,最好导出并且保存好你的私钥。这么做的另一个好处是当你需要跟其他人共享证书时(尤其是手头儿银子不多的个人开发者),只需要把私钥发给他人就好。当你用自己的私钥对代码进行签名后,苹果就可以用证书中的公钥来进行验证,确保真的是你对代码进行签名了,一来防止冒名顶替,二来确保代码的完整性。
     

    App ID

    App ID的主要用途是标识一个或者一组App,App ID应该是和Xcode中的Bundle ID是一致的或者说,可以匹配的。App ID有以下两种:
    • Explicit App ID:唯一的App ID,这种类型的App ID只能用来标识一个应用,例如,com.aiscot.whatever,用来标识Bundle ID为com.aiscot.whatever的应用程序,其他的不行。
    • Wildcard App ID:通配符App ID,这种类型的App ID用来标识一组应用程序,例如,com.aiscot.*可以用来标识Bundle ID为com.aiscot.whatever1和com.aiscot.biteme1等所有Bundle ID以com.aiscot开头的应用程序
    每次创建一个新的App ID,我们可以设置该App ID所使用的App Services,比如有的使用Game Center,有的不使用,需要注意的是如果你要使用推送服务,那么你要新建的这个新的App ID必须是Explicit类型的App ID,这样儿,苹果的Apns才能识别到唯一的一个应用从而进行推送提醒,而不会出现所谓“一呼百应”的现象,下面是目前的一些可选服务和相对应的配置要求:
    配置的时候,一定仔细瞅瞅哈,搞错了不要打我~(≧▽≦)/~啦啦啦

    Identifiers

    Identifiers是标识符的意思,相当于身份证吧,用于创建以下三个:
    App IDs
    Pass Type IDs
    Website Push IDs
    其中,App ID是应用的唯一标识符,每个应用的App ID是不一样的。

    Provisioning Profile

    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是相同的。
     
     
    证书的大概讲解就先到这里,我先出门剪个头发去,晚上把开发和发布流程整理一下。
     
    2015年1月31日,EricTang 记
     
    from :http://blog.csdn.net/jeepxiaozi/article/details/43309217
  • 相关阅读:
    《Python机器学习及实践:从零开始通往Kaggle竞赛之路》
    CPA专业阶段单科成绩有5年有效期限,即从通过科目考试的第一年算起
    升级gitk后,Error in startup script: unknown color name "lime"
    新三板:精选反馈问题103题(建议收藏)
    jQuery .on
    onload in JavaScript
    The JavaScript this Keyword
    JavaScript method overload
    JavaScript modularity with RequireJS (from spaghetti code to ravioli code)
    Understanding RequireJS for Effective JavaScript Module Loading
  • 原文地址:https://www.cnblogs.com/xuan52rock/p/4953172.html
Copyright © 2011-2022 走看看