本文翻译自:Xcode Project vs. Xcode Workspace - Differences
I am trying to understand how the whole ecosystem of iOS
works. 我试图了解iOS
的整个生态系统是如何工作的。
Until now, I could find an answer for most of my question (and trust me, there have been a lots of them), but for this one, there seems to be no clear answer yet. 到现在为止,我可以找到大部分问题的答案(相信我,有很多问题),但对于这个问题,似乎还没有明确的答案。
What is the difference between XcodeProject and XcodeWorkspace files? XcodeProject和XcodeWorkspace文件有什么区别?
- What is the difference between the two of them? 他们两个有什么区别?
- What are they responsible for? 他们负责什么?
- Which one of them should I work with when I'm developing my Apps in team/alone? 当我在团队/单独开发我的应用程序时,我应该使用哪一个?
- Is there anything else I should be aware of in matter of these two files? 对于这两个文件,还有什么我应该注意的吗?
#1楼
参考:https://stackoom.com/question/1SlI9/Xcode项目与Xcode工作区-差异
#2楼
A workspace is a collection of projects. 工作区是项目的集合。 It's useful to organize your projects when there's correlation between them (eg: Project A includes a library, that is provided as a project itself as project B. When you build the workspace project B is compiled and linked in project A). 在项目之间存在相关性时组织项目非常有用(例如:项目A包含一个库,项目本身作为项目B提供。当您构建工作区时,项目B在项目A中编译和链接)。
It's common to use a workspace in the popular CocoaPods . 在流行的CocoaPods中使用工作区是很常见的 。 When you install your pods, they are placed inside a workspace, that holds your project and the pod libraries. 安装pod时,它们将放置在工作区内,该工作区包含项目和pod库。
#3楼
I think there are three key items you need to understand regarding project structure: Targets , projects , and workspaces . 我认为有关项目结构需要了解的三个关键项目: 目标 , 项目和工作区 。 Targets specify in detail how a product/binary (ie, an application or library) is built. 目标详细说明了如何构建产品/二进制文件(即应用程序或库)。 They include build settings, such as compiler and linker flags, and they define which files (source code and resources) actually belong to a product. 它们包括构建设置,例如编译器和链接器标志,它们定义哪些文件(源代码和资源)实际属于产品。 When you build/run, you always select one specific target. 构建/运行时,始终选择一个特定目标。
It is likely that you have a few targets that share code and resources. 您可能有一些共享代码和资源的目标。 These different targets can be slightly different versions of an app (iPad/iPhone, different brandings,…) or test cases that naturally need to access the same source files as the app. 这些不同的目标可能是稍微不同的应用程序版本(iPad / iPhone,不同的品牌......)或自然需要访问与应用程序相同的源文件的测试用例。 All these related targets can be grouped in a project . 所有这些相关目标都可以分组到一个项目中 。 While the project contains the files from all its targets, each target picks its own subset of relevant files. 当项目包含来自其所有目标的文件时,每个目标都会选择自己的相关文件子集。 The same goes for build settings: You can define default project-wide settings in the project, but if one of your targets needs different settings, you can always override them there: 构建设置也是如此:您可以在项目中定义默认的项目范围设置,但如果您的某个目标需要不同的设置,您可以在那里覆盖它们:
Shared project settings that all targets inherit, unless they override it 所有目标都继承的共享项目设置,除非它们覆盖它
Concrete target settings: PSE iPhone overrides the project's Base SDK
setting 具体目标设置: PSE iPhone会覆盖项目的Base SDK
设置
In Xcode, you always open projects (or workspaces, but not targets), and all the targets it contains can be built/run, but there's no way/definition of building a project, so every project needs at least one target in order to be more than just a collection of files and settings. 在Xcode中,您总是打开项目(或工作空间,但不是目标),并且可以构建/运行它包含的所有目标,但是没有办法/定义构建项目,因此每个项目至少需要一个目标才能不仅仅是一组文件和设置。
Select one of the project's targets to run 选择要运行的项目目标之一
In a lot of cases, projects are all you need. 在很多情况下,项目就是您所需要的。 If you have a dependency that you build from source, you can embed it as a subproject . 如果您具有从源构建的依赖项,则可以将其作为子项目嵌入。 Subprojects can be opened separately or within their super project. 子项目可以单独打开,也可以在超级项目中打开。
demoLib is a subproject demoLib是一个子项目
If you add one of the subproject's targets to the super project's dependencies, the subproject will be automatically built unless it has remained unchanged. 如果将子项目的一个目标添加到超级项目的依赖项中,则子项目将自动构建,除非它保持不变。 The advantage here is that you can edit files from both your project and your dependencies in the same Xcode window, and when you build/run, you can select from the project's and its subprojects' targets: 这里的优点是您可以在同一个Xcode窗口中编辑项目和依赖项中的文件,并且在构建/运行时,您可以从项目及其子项目的目标中进行选择:
If, however, your library (the subproject) is used by a variety of other projects (or their targets, to be precise), it makes sense to put it on the same hierarchy level – that's what workspaces are for. 但是,如果您的库(子项目)被各种其他项目(或其目标,确切地说)使用,则将它放在同一层次结构级别上是有意义的 - 这就是工作空间的用途。 Workspaces contain and manage projects, and all the projects it includes directly (ie, not their subprojects) are on the same level and their targets can depend on each other (projects' targets can depend on subprojects' targets, but not vice versa). 工作空间包含和管理项目,它直接包含的所有项目(即,不是它们的子项目)处于同一级别,它们的目标可以相互依赖(项目的目标可以取决于子项目的目标,但反之亦然)。
Workspace structure 工作区结构
In this example, both apps ( AnotherApplication / ProjectStructureExample ) can reference the demoLib project's targets. 在此示例中,两个应用程序( AnotherApplication / ProjectStructureExample )都可以引用demoLib项目的目标。 This would also be possible by including the demoLib project in both other projects as a subproject (which is a reference only, so no duplication necessary), but if you have lots of cross-dependencies, workspaces make more sense. 这也可以通过在其他项目中包含demoLib项目作为子项目(仅作为参考,因此不需要重复),但如果您有许多交叉依赖项,则工作区更有意义。 If you open a workspace, you can choose from all projects' targets when building/running. 如果打开工作区,则可以在构建/运行时从所有项目的目标中进行选择。
You can still open your project files separately, but it is likely their targets won't build because Xcode cannot resolve the dependencies unless you open the workspace file. 您仍然可以单独打开项目文件,但可能无法构建其目标,因为除非打开工作区文件,否则Xcode无法解析依赖项。 Workspaces give you the same benefit as subprojects: Once a dependency changes, Xcode will rebuild it to make sure it's up-to-date (although I have had some issues with that, it doesn't seem to work reliably). 工作区为您提供与子项目相同的好处:一旦依赖项发生变化,Xcode将重建它以确保它是最新的(尽管我遇到了一些问题,它似乎无法可靠地工作)。
Your questions in a nutshell : 您的问题简而言之 :
1) Projects contain files (code/resouces), settings, and targets that build products from those files and settings. 1)项目包含从这些文件和设置构建产品的文件(代码/资源),设置和目标。 Workspaces contain projects which can reference each other. 工作区包含可以相互引用的项目。
2) Both are responsible for structuring your overall project, but on different levels. 2)两者都负责构建整个项目,但在不同层面。
3) I think projects are sufficient in most cases. 3)我认为在大多数情况下项目就足够了。 Don't use workspaces unless there's a specific reason. 除非有特殊原因,否则不要使用工作区。 Plus, you can always embed your project in a workspace later. 此外,您可以随后将项目嵌入工作区。
4) I think that's what the above text is for… 4)我认为这就是上面的内容......
There's one remark for 3): CocoaPods , which automatically handles 3rd party libraries for you, uses workspaces. 3)的一句话: CocoaPods ,它自动为你处理第三方库,使用工作空间。 Therefore, you have to use them, too, when you use CocoaPods
(which a lot of people do). 因此,当你使用CocoaPods
(很多人都这样做)时,你也必须使用它们。
#4楼
In brief 简单来说
- Xcode 3 introduced subproject, which is parent-child relationship, meaning that parent can reference its child target, but no vice versa Xcode 3引入了子项目,它是父子关系,意味着父项可以引用其子目标,但反之亦然
- Xcode 4 introduced workspace, which is sibling relationship, meaning that any project can reference projects in the same workspace Xcode 4引入了workspace,这是兄弟关系,这意味着任何项目都可以在同一个工作区中引用项目
#5楼
When I used CocoaPods to develop iOS projects,there is a .xcworkspace
file,you need to open the project with .xcworkspace
file related with CocoaPods. 当我使用CocoaPods开发iOS项目时,有一个.xcworkspace
文件,你需要用与.xcworkspace
相关的.xcworkspace
文件打开项目。
But when you Show Package Contents
with .xcworkspace
file,you will find the contents.xcworkspacedata
file. 但是当您使用.xcworkspace
文件Show Package Contents
时,您将找到contents.xcworkspacedata
文件。
<?xml version="1.0" encoding="UTF-8"?> <Workspace version = "1.0"> <FileRef location = "group:BluetoothColorLamp24G.xcodeproj"> </FileRef> <FileRef location = "group:Pods/Pods.xcodeproj"> </FileRef> </Workspace>
pay attention to this line: 注意这一行:
location = "group:BluetoothColorLamp24G.xcodeproj"
The .xcworkspace
file has reference with the .xcodeproj
file. .xcworkspace
文件引用了.xcodeproj
文件。
Development Environment: 发展环境: macOS 10.14 Xcode 10.1