到这个月，参加工作正好一年，期间忙于各种需求，虽说业务熟悉了，但是技术方面还是有待提高，尤其对证书那一块不太熟悉，写下这篇博客主要还是自己学习过程中的一些记录。
主要是一些概念的解释：
1. bundle ID
bundle ID是用来唯一标识一个app的字符串，bundle ID不论是在开发过程中还是在app上架发布之后都会用到，例如，当你的app使用Game Center 或 In-App Purchase(应用内购买)等某些服务时，这些服务就会用bundle ID当做唯一标识符去识别。手机里的偏好设置也是用bundle ID来区分每个app从而对不同的app应用不同的设置。类似的，Launch Services会用bundle ID去判断一个app是否能够打开某个特定的文件。bundle ID也同样被用来验证一个app的签名。
bundle ID一般是反向域名(reverse-DNS format)的格式,比如，你的公司域名是abc.com，你创建了一个app叫hello，那么你可以设置你的app的bundle ID为com.abc.hello。
在开发的过程中，你会在许多地方用到bundle ID：
1> 在Xcode project中，bundle ID被存储在Info.plist中。当你编译你的项目的时候，这个文件将会被拷贝进你的app bundle 中。
2> 在iTunes Connect中，bundle ID被用来识别你的app，当你向iTunes Connect的提交过一次之后，bundle ID就不能修改了。
3> 在developer account中，Xcode会创建一个匹配bundle ID 的APP ID，如果这个APP ID是一个explicit App ID(唯一的APP ID，这里后面会说到)，那么这个APP ID 应该是和bundle ID完全一样的(需要注意的是，bundle ID是区分大小写的，所以如果这个explicit App ID全是小写的，对应的bundle ID也应该是全小写的)
4> 在iCloud中，你在Xcode中指定的container ID就是基于bundle ID创建的。
2. APP ID
APP ID是用来标识单个development team(开发组)中一个或一组app的字符串。它由两部分组成，Team ID和bundle ID search string(这里可以理解为就是某个app的bundle ID)，中间由 . 连接。Team ID是由苹果提供的，对每一个development team(开发组)是唯一的，bundle ID则是由开发者自己指定的。
APP ID分为2种：
Explicit App ID：唯一的App ID，这种App ID用于唯一标识一个应用程序，例如com.ABC.demo1，标识Bundle ID为com.ABC.demo1的程序。
Wildcard App ID：通配符App ID，用于标识一组应用程序。例如*可以表示所有应用程序，而com.ABC.*可以表示以com.ABC开头的所有应用程序。
服务是与App ID相关的。每创建一个App ID，我们都可以设置该App ID所使用的APP Services，也就是其所使用的额外服务。每种额外服务都有着不同的要求，例如，如果要使用Apple Push Notification Services，则必须是一个explicit App ID，以便能唯一标识一个应用程序。下面是一些可选的服务和相应的配置要求。
3. Code signing
简单来说就是运用加密技术对app或者安装包进行签名，从而保证该app的来源是可信任的，并且代码是完整的， 未经修改的。一个app如果想要在设备上运行，使用某些额外服务，发布到应用商店都需要被Code signing。Code signing后，app就被这个签名保护着，因为只要这个app的代码被改动了，这个签名将会失效，手机系统将无法确认这个app是可信任的，那这个app将无法被启动。(需要注意的是，像图片或者nib文件这类的资源将不会被签名，所以这些文件的改动将不会导致签名失效)
4. certificate
证书是用来给应用程序签名的，只有经过签名的应用程序才能保证他的来源是可信任的，并且代码是完整的， 未经修改的。在Xcode Build Setting的Code Signing Identity中，你可以设置用于为代码签名的证书。
我们申请一个Certificate之前，需要先申请一个Certificate Signing Request (CSR) 文件，而这个过程中实际上是生成了一对公钥和私钥，保存在你Mac的Keychain中。代码签名正是使用这种基于非对称秘钥的加密方式，用私钥进行签名，用公钥进行验证。如下图所示，在你Mac的keychain的login中存储着相关的公钥和私钥，而证书中包含了公钥。你只能用私钥来进行签名，所以如果没有了私钥，就意味着你不能进行签名了，所以就无法使用这个证书了，此时你只能revoke之前的证书再申请一个。因此在申请完证书时，最好导出并保存好你的私钥。当你想与其他人或其他设备共享证书时，把私钥传给它就可以了。私钥保存在你的Mac中，而苹果生成的Certificate中包含了公钥。当你用自己的私钥对代码签名后，苹果就可以用证书中的公钥来进行验证，确保是你对代码进行了签名，而不是别人冒充你，同时也确保代码的完整性等。
certificate主要分为2类：
Development certificates：开发证书，用来开发和调试应用程序，对应着一个development team中的某一个成员
Distribution certificates：发布证书，主要用来分发应用程序（根据证书种类有不同作用），对应着一个development team(开发组)
一个development team中所有的成员都能创建自己的开发证书，但是只有team agent或者team admin可以创建发布证书。
5.Device
Device就是运行iOS系统用于开发调试app的设备， 每台设备使用UDID来唯一标识。Apple Member Center 网站个人账号下的 Devices 中包含了注册过的所有可用于开发和测试的设备，普通个人开发账号每年累计最多只能注册100个设备。Disable 一台设备也不会增加名额，只能在membership year 开始的时候才能通过删除设备来增加名额。
6.Provisioning Profile
Provisioning是配置一个app可以运行在哪些设备上，可以使用哪些服务，用哪张证书签名的过程，这个过程最后产生的文件，就叫做Provisioning Profile(配置文件)。
一个Provisioning Profile文件包含了：证书、App ID、设备。
试想一下，如果我们要打包或者在真机上运行一个应用程序，我们首先需要证书来进行签名，用来标识这个应用程序是合法的、安全的、完整的等等；然后需要指明它的App ID，并且验证Bundle ID是否与其一致；再次，如果是真机调试，需要确认这台设备能否用来运行程序。而Provisioning Profile就把这些信息全部打包在一起，方便我们在调试和发布程序打包时使用，这样我们只要在不同的情况下选择不同的profile文件就可以了。
例如，如下图所示，一个Provisioning Profile中包含了该Provisioning Profile对应的App ID，可使用的证书和设备。这意味着使用这个Provisioning Profile打包程序必须拥有相应的证书，并且是将App ID对应的程序运行到Devices中包含的设备上去。
与证书一样，Provisioning Profile也分为Development和Distribution两种。
当你build你的程序时，Provisioning Profile会嵌入app bundle中，而整个bundle又是被Code signing签名过的。在一个app第一次运行在某个设备上之前，嵌入在其中的配置文件会先在该设备上安装，如果这个配置文件不满足某些特定的条件，这个app将不会被启动，这些特定条件大概如下图：
参考：
1.https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/MaintainingCertificates/MaintainingCertificates.html#//apple_ref/doc/uid/TP40012582-CH31-SW6
2. http://blog.it985.com/11375.html
3.https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppStoreDistributionTutorial/CreatingYourTeamProvisioningProfile/CreatingYourTeamProvisioningProfile.html#//apple_ref/doc/uid/TP40013839-CH33-SW1
网友评论