Xcode工程结构详解

当咱们新建一个 Cocoa 项目时，Xcode 会提供一系列的模板，咱们选择Single View App便可。

工程模板

Application类型

• Master-detail Application.
  能够构建树形结构导航模式应用，生成的代码中包含了导航控制器和表示图控制器。(表示图控制器指的是导航控制器里的界面);
• Game. 构建基于iOS的游戏应用；
• Page-Based Application. 平铺导航，相似于电子书效果;
• Tabbed Applecation. 构建标签导航模式应用，生成的代码中包含了标签控制器和标签栏。
• Single View Application. 构建简单的单个视图应用。

Framework & Library类型

• Cocoa Touch Framework:自定义应用于UIKit框架。
• Cocoa Touch Library:可建立基于Foundation框架的静态库。

Other类型

可构建应用内购买内容包盒空工程——内置收费功能的应用。

输入必要的配置信息后，这些信息包括：

• 编译选项、证书链选项
• 项目 Target、单元测试 Target
• 基于 git 的版本控制管理
• 默认的源文件。

因为苹果的封闭性，对 Cocoa 项目的管理基本上都在 Xcode 中进行，Xcode提供了从文档、编码、调试、测试，再到签名、打包、上线的全流程支持。

随着开发的深刻，咱们的项目变得愈来愈复杂，各类连接库、子工程相互引用，不一样 Target、Scheme 配置混杂，还会遇到多人协做开发时诡异的冲突。

Xcode基础概念

Schema、Target、Project 和 Workspace 是组成一个 Xcode 工程最核心的单元，也是咱们首先须要理解的部分。

Target

Target 是咱们工程中的最小可编译单元，每个 target 对应一个编译输出，这个输出能够是一个连接库，一个可执行文件或者一个资源包。它定义了这个输出怎样被 build 的全部细节，具体包括：

• 编译选项，好比使用的编译器，目标平台，flag，头文件搜索路径等等。
• 哪些源码或者资源文件会被编译打包，哪些静态库、动态库会被连接。
• build 时的前置依赖、执行的脚本文件。
• build 生成目标的签名、Capabilities 等属性。

在ios项目中， Build Settings，Build Phases 中配置的各类选项，大部分都是须要对应到指定的 target 的。

而且，每次咱们在 Xcode 中 run/test/profile/analyze/archive 时，都必须指定一个 target。

工程中的 targets 有时候会共享不少代码、资源，这些类似的 targets 可能对应同一个应用的不一样版本，好比 iPad 版和 iPhone 版，或者针对不一样市场的版本。

Project

Project 很好理解，Project就是一个 Xcode 工程，它管理工程下的全部targets 集合以及它们的源码，引用的资源，framework 等等。

Project 是管理资源的容器，自己是没法被编译的，因此每一个 project 至少应该有一个可编译的 target，不然就是一个空壳。一个 target 编译时引用的资源是它所在 project 全部管理资源的子集。

咱们也能够对 project 进行配置，包括基本信息和编译选项（Build Settings）等，这些配置会应用到它管理的全部 targets 中，可是若是 target 有本身的配置，则会覆盖 project 中对应的配置。

在不少状况下，咱们的工程中只有一个 project。能够在 finder 中双击后缀名为.xcodeproj 的文件，就能够直接打开单个 project 了。

若是咱们须要从源码编译一个依赖库，能够把这些源码所在的工程做为主工程的subProject 添加到目录结构中去。

Workspace

当一个 target 被多个不一样的项目依赖，或者 project 之间互相引用，那么咱们就须要把这些 projects 放到相同的层级上来。管理相同层级 projects 的容器就是 Workspace。

和 projects，target 不一样，workspace 是纯粹的容器，不参与任何编译连接过程，它主要管理：

• Xcode 中的 projects，记录它们在 Finder 中的引用位置。
• 一些用户界面的自定义信息（窗口的位置，顺序，偏好等等）。

细心的童鞋可能已经注意到：当你把不一样的 projects 放到一个 workspace 中管理后，你仍然能够用 Xcode 单独打开其中的某一个 project，可是若是它涉及到对其它 project target 的依赖，这时候你没法在这个单独的窗口中编译成功。

在 iOS 开发中，咱们经常使用 Cocoapods 来管理三方库，它会把这些三方库的源码组装成一个 project，和主工程一块儿放入到 workspace 中，自动配置好主工程与 pods 库之间的依赖。因此若是引入了 Cocoapods，咱们必须打开这个新的 workspace 才能正常 build 原来的项目。

Scheme

咱们知道苹果手机中的每一个APP都有一个沙盒，APP就是一个信息孤岛，相互是不能够进行通讯的。可是iOS的APP能够注册本身的URL Scheme，URL Scheme是为方便app之间互相调用而设计的。咱们能够经过系统的OpenURL来打开该app，并能够传递一些参数。

URL Scheme必须能惟一标识一个APP，若是你设置的URL Scheme与别的APP的URL Scheme冲突时，你的APP不必定会被启动起来。scheme的命名应该是只能纯英文字符，而不能含有下划线或者数字。

平常开发中咱们经常点击 Xcode 左上角的 Run 箭头来运行调试代码，这其实就是执行了 Scheme 定义的一个任务。

针对一个指定的 target，scheme 定义了 build 这个 target 时使用的配置选项，执行的任务，环境参数等等。Scheme 能够理解为一个工做流，或者蓝图，当咱们点击 debug，test 按钮时，Xcode 会按照 scheme 中的定义，去执行对应的工做流。

Scheme 中预设了六个主要的工做流： Build, Run, Test, Profile, Analyze, Archive。包括了咱们对某个 target 的全部操做，每个工做流均可以单独配置。

Scheme 中最重要的一个配置是选择 target 的 build configuration，对每个 project，会有两个默认的 build configuration：debug 和 release。

每一个 configuration 对应了 build target 时不一样的参数集，好比宏，编译器选项，bundle name 等等。咱们能够在 target 的配置页中更改这些选择项，也能够本身建立新的 build configuration，好比为 App 建立免费和付费版本的配置。

除了 build configuration 外，scheme 还能够配置：

• 运行时的环境变量（Environment Variables）
• 启动时设置给 UserDefaults 的参数（Arguments Passed on Launch）
• App 执行时的系统语言、模拟的定位坐标、国家等环境参数
• runtime，内存管理，日志，帧率检测等调试选项。

工程目录分包策略

注：如下部分截取自网络。

在ios开发中，你简单最糟心的项目是什么，确定有人会说要多糟心有多糟心，曾经我也见到过很糟心的项目，没有采用任何框架，编译都好几分钟的那种。
下面是一个传统的MVC方式开发的项目的分包：

• Bms:这个文件夹下主要放的是与业务相关的文件;
• Application:这个文件夹下主要放的是UI相关的文件、业务控制层相关的文件、数据模型、业务逻辑相关的文件等;
• BaseServer:这个文件夹下主要放的是 UI 业务逻辑相关文件和业务数据逻辑相关的文件;
• Controllers:这个文件夹下主要放的是业务相关控制类,例如:UIViewcontroller;
• Dtabase:这个文件夹下主要放的是数据库相关的业务文件;
• Models: 这个文件夹下主要放的是业务数据实体(数据模型);
• View:这个文件夹下主要放的是UI窗口组件和UI 公共组件;
• Config:这个文件夹下主要放的是一些自定义的配置文件,例如:宏定义文件、自定义 .plist文件、.pch文件等;
• Helpers:这个文件夹下主要放的是一些辅助业务相关的辅助文件;
• IM:这个文件夹下主要放的是即时聊天相关的业务文件;
• Core:这个文件夹下主要放的是一些核心代码,好比一些三方包,工具类,底层代码等;
• Database:这个文件夹下主要放的是一些数据库底层核心代码;
• IM:这个文件夹下主要放的是即时聊天模块的核心代码;
• Libs:这个文件夹下主要放的是三方包文件,例如:FMDB 三方包;
• Network:这个文件下主要放的是与服务器交互的核心文件,例如:Https、Socket、Webserver等;
• Utils:这个文件夹下主要放的是一些系统经常使用的工具类,例如:获取时间工具类,文件大小等;
• Supporting Files :这个文件夹下主要放的是系统生成的文件,好比:AppDelegate文件、info.plist文件和 main.m文件;
• Resource:这个文件夹下主要放的是一些资源文件,好比:图片文件、音频文件等;
• Frameworks: 这个文件夹下主要是将用到系统的
  Frameworks,整理到这个文件夹下,好比:AVFoundation.framework
• Products:这个文件夹是系统本身生成的,主要放的是 .app文件。

因为，此种分别，不少代码都写在一块，因而又出现了按照功能进行的分包策略。例如：

能够看到，项目就是按照功能进行分包，而后进行业务迭代，估计也是不少公司的项目的样本。而咱们队项目进行了一些简单的归类，归类的示意图以下：

这样一来，咱们的工程主要有三大部分：Core、Resource、SupportingFiles。其中，Core存放咱们的代码，也是文章主要说明的部分。Resource用于存放资源，例如图片、音效、文件等等，SupporrtingFiles用于存放pch、main.m等等文件。

Core的分组主要分为AppDelegate、Modules、NetWork/Requests、Services、General、Macro、Vendors等六个大模块。

AppDelegate

AppDelegate文件只存放AppDelegate的h和m文件，也能够放入其余跟AppDelegate有关的文件，好比咱们写了一个AppDelegate+Router的Category文件，用来处理rootViewController的变化，这个也应该放到这个分组来比较清晰，而不是放到General的Category。

Modules

Modules用于存放应用的业务逻辑代码，总而言之，Modules就是放App主要业务逻辑和功能代码的地方。

Services

服务模块，主要提供应用的基础服务，好比说Apns推送管理，数据库，本地推送等等，这一类的封装以后的功能模块。

Vendors

全部的第三方类库都放到Vendors里面。

此种分别只供参考，并不绝对和权威，实际采用的分包和开发方案还得根据实际状况，或者配合一些诸如MVVM等框架来进行拆包。