Question

我想在调试屏幕中查看此内容以获取构建信息。有没有办法在运行时检查这个？

我意识到我可以为构建或类似设置编译器标志，但如果有一个我可以利用的现有方法，我想利用它。

Answer 1

虽然我同意Abhi Beckert认为运行时是错误的时间（使用预处理程序指令和构建设置！），但我想澄清之前的答案/评论中的一些细节和推测，并发出一些启示关于你可以做的事情。忍受我，这将是一个更长的答案......

有许多数据可以归入“建立信息”的通用范围。这些事情的非详尽列表包括：构建配置，代码签名标识，构建时间，构建日期，营销版本号，SCM修订号，SCM分支名称，供应配置文件团队标识，供应配置文件过期，CI构建号。这个清单一直在继续。

假设目前您的问题主要集中在获取有关用于构建的iOS证书和配置文件类型的信息，那么我将不得不选择一个非常坚定的“没有”的问题。作为问题的答案：有没有办法在运行时检查[使用现有的API方法构建信息]？简而言之：这两个数据点统称为＆＃34; { {3}}＆＃34;在Xcode 4.6.x构建设置或＆＃34; CODE_SIGN_IDENTITY＆＃34;为您的命令行构建设置爱好者。

截至提出此问题时，您可以调用任何单一的公共iOS API来获取有关当前正在运行的应用程序的代码签名类型的信息。这背后可能的原因很多，但这里有几个例子：

允许开发人员构建自己的构建方案和构建配置。这意味着我们可以拥有一个方案和一个构建配置，或一个方案和几十个构建配置，甚至每个配置数千个。当然，可以为每个方案分配不同的构建配置，并且可以为每个配置分配不同的代码签名标识。正如您可能猜到的那样，开发人员或团队不需要进行太多定制就可以快速混乱。
代码签名标识仅要求为当前应用程序标识符颁发的未过期的Provisioning Profile包含用于签署二进制文件的证书的公钥副本。对于在团队中工作的人员，您可能拥有一个包含团队中开发人员所有证书的Provisioning Profile，或者您可以为团队中每个仅包含其证书的开发人员制作单独的Provisioning Profiles。这是开发人员如何选择构建应用程序的另一个变化点。
开发人员可以共享一个证书（tsk tsk）或者颁发自己的证书......是的，你猜对了，还有更多的变化。

这个假设的一站式API需要在运行时访问您的所有构建配置数据，证书和配置文件，以便能够解开“有效”的问题。在编译时应用的设置，并将所有数据减少到有限的字符串...只是为了开发人员诊断视图......在任何想象力的范围内都不是一个不可能完成的壮举，但这种潜在的计算密集型操作对于可忽略不计的开发人员的好处肯定会在任何人的优先级列表中排名很低。鉴于其他选项（如编译时标志！）更可靠，设置更便宜，并且从长远来看更容易维护，它会在优先级列表中被踢得更远。

现在，至于半潜伏的问题＆＃34;我可以在运行时这样做吗？＆＃34;我会强调说'是的，你可以。＆＃39;

如您所知，设备构建是唯一需要代码签名的构建类型。部分过程在主捆绑中创建一个名为“embedded.mobileprovision”的文件。这是您应用程序的沙箱所拥有的文件，因此您绝对有能力以编程方式打开：

[[NSBundle mainBundle] pathForResource:@"embedded.mobileprovision" ofType:nil]

.mobileprovision文件是PCKS＃7编码的，包含二进制和文本数据。您寻求的信息是嵌入在PCKS＃7数据中的基于文本的plist的信息。首先，使用OS X，让我们从您的一个设备版本中查看此文本数据：

右键点击您的构建设备.app捆绑包，然后选择“显示包裹内容＆＃39;
将embedded.mobileprovision文件复制到易于访问的位置。
使用首选文本编辑器打开该文件。

你立即注意到有很多二进制数据，但你可以找出部分文本数据。滚动到右侧，您将看到plist风格的xml，只是在此视图中不容易阅读。我们可以使用OS X命令行工具以更有条理的方式查看此数据：

打开终端和＆＃39; cd＆＃39;到包含您的embedded.mobileprovision副本的文件夹。
运行：security cms -D -i embedded.mobileprovision

这会将plist xml显示在终端窗口中，以便以精美的标签格式进行阅读。如果您为Ad-Hoc构建，Dev构建和App Store构建重复此过程，您将开始注意到本文中指示各个构建类型的键。对于使用iPhone开发人员签名的版本：...＆＃39;证书（或原始帖子中列出的＆＃39; Dev＆＃39; build），查找：

<key>get-task-allow</key>
<true/>

＆＃39; get-task-allow＆＃39; key是用于指示iOS的，如果应用程序允许调试器附加到它。对于iPhone开发者＆＃39;签名二进制文件是有意义的 - 在将代码从Xcode推送到您的设备以进行测试时，您通常需要能够在设备上进行调试。

Ad-Hoc＆＃39;之间的差异。和App Store＆＃39;需要一些额外的检查。同样的“get-task-allow”＃39;对于这两种发行版，key都将设置为false：

<key>get-task-allow</key>
<false/>

然而，＆＃39; Ad-Hoc＆＃39;版本具有一组已定义的“已安装设备”，而不会出现在“应用商店”中。构建：

<key>ProvisionedDevices</key>
<array>
    <string>abcdef01234567890abcdef01234567890abacde</string>
    <string>1abcdef01234567890abcdef01234567890abacd</string>
    <string>2abcdef01234567890abcdef01234567890abacd</string>
</array>

那么这对运行时检查问题的实际意义是什么呢？是的，您可以通过从主捆绑中打开embedded.mobileprovision文件，并从中解析数据以做出明智的决定，但这是您自己实施的全部责任。您需要添加逻辑来处理丢失该文件的情况（例如模拟器构建）并解析PCKS＃7数据或者可靠地提取文件的ASCII内容，您的代码可以在该文件上运行一系列字符串搜索。很可能很明显，这需要付出一些微不足道的努力来解决一些脆弱的解决方案，否则可以通过上一个答案中概述的Abhi Beckert的构建设置和预处理器宏轻松实现。

App Store拒绝的风险如何？这是非法的吗？或者颠覆性的＆＃39;

假设您在阅读和解析embedded.mobileprovision文件的内容时使用了所有公共API，那么App Store的当前条款是完全允许的。你应用程序的沙盒中的任何东西都是公平的游戏，包括embedded.mobileprovision，如果碰巧存在的话。我仍然强烈警告不要走这条路，这与Abhi Beckert的评论相呼应。对于不到1％的用例而言，这是一项相当大的努力，并且有更容易的解决方案！此外，开发人员诊断视图不应该在App Store版本构建中，但是包含无关代码的决定完全在您手中。

我希望这可以解决任何挥之不去的问题，但如果没有，请发表评论，我们可以看到我们能做些什么。

Answer 2

这可能是您正在寻找的。 Abhi有一个很好的，彻底的解释，这个要点有实际代码：

https://github.com/blindsightcorp/BSMobileProvision

Answer 3

运行时是执行此操作的错误时间。

如果您尝试这样做，您的应用可能会被拒绝。或者它可能被批准，然后你做一个紧急的bug修复版本，那个可能会被拒绝。

正如@rmaddy在评论中建议的那样，你应该在编译时这样做。

编辑项目设置以定义此常量：CONFIGURATION_$(CONFIGURATION)，然后在代码中执行此操作：

#if defined (CONFIGURATION_Debug) || defined (CONFIGURATION_Adhoc)
  NSLog( @"Warning message");
#endif

来源/更多详情：http://ios-dev.gravitini.com/2009/02/identifying-current-xcode-configuration.html

如果需要，可以在其周围包装运行时函数。也许：

void debugLog(NSString *str)
{
    #if defined (CONFIGURATION_Debug)
      NSLog(@"%@", str);
    #endif
}

检查app是否在运行时是ad-hoc | dev | app-store构建

3 个答案: