我是 Objective-c 和 osx 架构的新手。我开始尝试构建一个框架，然后使用它。我遵循了这个很棒的教程。
在本教程中，我必须将框架的目标的动态库安装名称设置为@rpath/MyFramework.framework/Versions/A/MyFramework. 我的理解是@rpath将扩展为加载器（消费者）的运行路径搜索路径。
加载框架的责任似乎由框架作者和消费者作者分担。有人可以解释为什么框架的作者需要关注消费者的运行路径搜索路径吗？例如，如果框架作者将动态库安装名称设置为指向某个随机目录（而不是@rpath），客户端将如何使用框架？
提前致谢。
这在很大程度上取决于框架的使用方式。重要的是要记住，框架结构在平台上已经存在了很长时间。
对于系统框架，例如 Apple 创建的框架，您会很高兴他们将框架保存在已知位置。在这些情况下，它们使用的路径对于操作系统是固定的，它保证您不会意外加载错误的路径。此外，正如框架文档中所指出的，这些框架在机器上只加载一次，无论它们被使用了多少次（参见Apple：什么是框架）。这里的好处是性能，在许多情况下它既适用于代码，也适用于资源。
由于最近采取了随机化框架位置的举措，以及 Apple 在发布说明中的评论“Mountain Lion 在系统启动时随机重新定位内核、kexts 和系统框架”，看来他们仍然在共享这些资源，因此仍然从中获益。
对于嵌入式框架，情况要繁琐得多，多年来，Apple 已经通过各种方法使无论在哪里都能更容易地找到框架。同样，由于共享的性质，共享公共库要求的应用程序在机器上共享它们是有意义的，这既是为了提高效率，又是为了确保它们在共享数据时处于相同的版本. 因此，例如，如果您有两个单独的应用程序使用相同的框架来处理共享数据，您可以将共享框架放入/Library/Frameworks并让两个应用程序显式查找它，确保其他（可能较旧）版本的已被另一个应用程序加载的框架不会被使用。
最后，对于框架生产者和消费者来说，它目前的工作方式具有很大的灵活性。这意味着开发人员可以决定共享一个框架，包括一个框架的私有副本，或者甚至两者都做，这取决于框架是否存在于机器上。然而，这种灵活性的代价就是我们今天所拥有的复杂性。
您可能不想@rpath专门使用的另一个原因是紧密链接的嵌入式框架（是的，人们将框架嵌入到其他框架中）。在这些情况下，您不知道第一个框架在哪里加载，但您希望将嵌入式框架放入其中，以便它们保持在一起。在这种情况下@loader_path，是相对于加载它的代码而言的，因此您的插件框架可以正确地找到它的资源。
回答您关于有人将动态库安装名称 设置为“随机”位置的具体示例。在这种情况下，您必须知道该位置。有人这样做可能有很多原因，例如想要阻止其他程序重用，或者因为框架中有大量资源应该只安装在已知的共享位置。