Ich denke, es gibt drei Schlüsselelemente, die Sie bezüglich der Projektstruktur verstehen müssen: Ziele, Projekte und Arbeitsbereiche. Ziele bestimmen im Detail, wie ein Produkt/binär (z. B. eine Anwendung oder Bibliothek) erstellt wird. Sie enthalten Build-Einstellungen wie Compiler- und Linker-Flags und definieren, welche Dateien (Quellcode und Ressourcen) tatsächlich zu einem Produkt gehören. Wenn Sie bauen/ausführen, wählen Sie immer ein bestimmtes Ziel aus.
Es ist wahrscheinlich, dass Sie einige Ziele haben, die Code und Ressourcen teilen. Diese verschiedenen Ziele können leicht unterschiedliche Versionen einer App sein (iPad/iPhone, verschiedene Marken,…) oder Testfälle, die natürlicherweise auf dieselben Quelldateien wie die App zugreifen müssen. All diese zusammenhängenden Ziele können in einem Projekt gruppiert werden. Während das Projekt die Dateien aller seiner Ziele enthält, wählt jedes Ziel seinen eigenen Satz relevanter Dateien aus. Gleiches gilt für Build-Einstellungen: Sie können Standard-Projekteinstellungen im Projekt festlegen, aber wenn eines Ihrer Ziele unterschiedliche Einstellungen benötigt, können Sie diese dort immer überschreiben:
![Geteilte Projekteinstellungen, die alle Ziele erben, es sei denn, sie überschreiben sie]()
Geteilte Projekteinstellungen, die alle Ziele erben, es sei denn, sie überschreiben sie
![Konkrete Ziel-Einstellungen: PSE iPhone überschreibt die Base SDK-Einstellung des Projekts]()
Konkrete Ziel-Einstellungen: PSE iPhone überschreibt die Base SDK-Einstellung des Projekts
In Xcode öffnen Sie immer Projekte (oder Arbeitsbereiche, aber keine Ziele) und alle enthaltenen Ziele können gebaut/ausgeführt werden, aber es gibt keine Möglichkeit/Definition zum Bauen eines Projekts, daher benötigt jedes Projekt mindestens ein Ziel, um mehr als nur eine Sammlung von Dateien und Einstellungen zu sein.
![Wählen Sie eines der Ziele des Projekts aus, um es auszuführen]()
Wählen Sie eines der Ziele des Projekts aus, um es auszuführen
In vielen Fällen sind Projekte alles, was Sie brauchen. Wenn Sie eine Abhängigkeit haben, die Sie aus dem Quellcode erstellen, können Sie sie als Unterprojekt einbetten. Unterprojekte können separat oder innerhalb ihres übergeordneten Projekts geöffnet werden.
![demoLib ist ein Unterprojekt]()
demoLib ist ein Unterprojekt
Wenn Sie eines der Ziele des Unterprojekts zu den Abhängigkeiten des übergeordneten Projekts hinzufügen, wird das Unterprojekt automatisch gebaut, es sei denn, es wurde nicht geändert. Der Vorteil hierbei ist, dass Sie Dateien sowohl aus Ihrem Projekt als auch aus Ihren Abhängigkeiten im selben Xcode-Fenster bearbeiten können und beim Bauen/Ausführen aus den Zielen des Projekts und seiner Unterprojekte wählen können:
![Ausführen von Zielen aus einem Unterprojekt]()
Wenn Ihre Bibliothek (das Unterprojekt) jedoch von einer Vielzahl anderer Projekte (oder deren Ziele, um genau zu sein) verwendet wird, macht es Sinn, sie auf der gleichen Hierarchieebene zu platzieren - dafür sind Arbeitsbereiche da. Arbeitsbereiche enthalten und verwalten Projekte, und alle direkt enthaltenen Projekte (also nicht ihre Unterprojekte) befinden sich auf der gleichen Ebene und ihre Ziele können voneinander abhängen (Ziele von Projekten können Ziele von Unterprojekten abhängen, aber nicht umgekehrt).
![Arbeitsbereichsstruktur]()
Arbeitsbereichsstruktur
In diesem Beispiel können beide Apps (AnotherApplication / ProjectStructureExample) auf die Ziele des Projekts demoLib verweisen. Dies wäre auch möglich, indem Sie das Projekt demoLib in beiden anderen Projekten als Unterprojekt einschließen (was nur eine Referenz ist, also keine Duplizierung notwendig), aber wenn Sie viele Kreuzabhängigkeiten haben, sind Arbeitsbereiche sinnvoller. Wenn Sie einen Arbeitsbereich öffnen, können Sie aus allen Zielen der Projekte wählen, wenn Sie bauen/ausführen.
![Ausführen von Zielen aus einem Arbeitsbereich]()
Sie können Ihre Projektdateien immer noch separat öffnen, aber es ist wahrscheinlich, dass deren Ziele nicht gebaut werden, weil Xcode die Abhängigkeiten nicht auflösen kann, es sei denn, Sie öffnen die Arbeitsbereichsdatei. Arbeitsbereiche bieten Ihnen denselben Vorteil wie Unterprojekte: Sobald sich eine Abhängigkeit ändert, wird Xcode sie neu erstellen, um sicherzustellen, dass sie auf dem neuesten Stand ist (obwohl ich damit einige Probleme hatte, es scheint nicht zuverlässig zu funktionieren).
Ihre Fragen in Kürze:
1) Projekte enthalten Dateien (Code/Ressourcen), Einstellungen und Ziele, die Produkte aus diesen Dateien und Einstellungen erstellen. Arbeitsbereiche enthalten Projekte, die sich gegenseitig referenzieren können.
2) Beide sind dafür verantwortlich, Ihr Gesamtprojekt zu strukturieren, aber auf verschiedenen Ebenen.
3) Ich denke, Projekte sind in den meisten Fällen ausreichend. Verwenden Sie Arbeitsbereiche nicht, es sei denn, es gibt einen spezifischen Grund. Außerdem können Sie Ihr Projekt später immer in einem Arbeitsbereich einbetten.
4) Ich denke, dafür ist der obige Text gedacht…
Es gibt eine Anmerkung zu 3): CocoaPods, das automatisch Drittanbieter-Bibliotheken für Sie behandelt, verwendet Arbeitsbereiche. Daher müssen Sie sie auch verwenden, wenn Sie CocoaPods verwenden (was viele Leute tun).
