iOS项目工程及目录结构

做过一些iOS的项目，不同项目的沉淀没有积累到一起，目录的管理都在后期随着人员的增加越来越混乱，因此在这里做一些梳理，希望达到两个目的。

• 一套相对通用的目录结构，作为后续项目的模版。

• 积累相应的基础库，在后续的项目里不断打磨，最后开源。

几个基本的原则：

• 一个合理的目录结构应该是清晰的，让人一眼就能了解目录职责，并且是容易扩展的。

• 不管是第三方库还是自己的库，尽量用CocoPods来管理。

• 区分不同层次的通用组件。

  • General Level, 最通用的组件，可以在不同项目里复用。

  • Project Level, 可以在该项目里复用。

  • Section Level, 可以在某个功能模块里复用。

• 对于General Level的组件，以Library的形式分出来，不要放在主工程。

• 对于基础库，保证质量，通用性，可扩展性，易用性，可以不断迭代

目录结构

下面是我建议的项目目录结构：(公司名为NB, 项目名为KP, General Level 组件都会以NB打头，Project Level组件以KP打头 )

KP_iOS
|
|--KP
|   |--Common
|   |    |-- KPUIKit
|   |    |-- KPCommon
|   |    |-- KPUtility
|   |    
|   |--Consts
|   |--Models
|   |--Sections
|   |--Vendors
|   |--Resources
|   
|--Pods
|    |--NBFoundation
|         |     
|         | -- NBUIKit
|         | -- NBCommon
|         | -- NBUtility
|                        
|    |--ThirdParty1
|    |--ThirdParty2

主目录下分为KP 和 Pods两个一级目录。

• KP是主工程目录

  • UIConsts.h

  • VendorConsts.h

  • KPCommon ： Project Level逻辑组件。

  • KPUIKit：Project Level UI组件。

  • KPUtility：Project Level的帮助函数。

  • Common: 主要存放在KP这个项目里可以通用但不对其它项目通用的Project Level的组件。

  • Consts 存放项目范围内公用的常量。 例如：

  • Model：各个功能模块数据逻辑相关的文件。

  • Sections：各个具体的功能模块UI及交互相关文件。 如果某个Section有一些Section Level的通用组件，可以在具体的Section下有一个Common目录。

  • Vendors： 存放没有被CocoaPods管理的第三方组件

  • Resources

• Pods是CocoaPods的根目录, 所有CocosPods管理的库都在该目录下。

  • NBFoundation: 可以在所有项目里通用的General Level 的组件（跟KP/Common里的内容及结构类似，但更通用)。

      * NBCommon  通用的逻辑组件。
      * NBUIKit 通用的UI组件。
      * NBUtility 帮助函数。

通用组件

• 设计通用组件跟设计UI一样，要做到优雅而简洁。

  • 直观性 。接口清晰，跟系统API风格一致，用户一看就知道怎么使用。

  • 易用性 。我们的设计需要使最经常被用到的的功能简单易用，不需要过度的配置，在默认配置下API就应该是可用的。

  • 容错性。 考虑到不同的使用场景，对于复杂场景，通过配置或者API接口，用户可以达到目的。

  • 解偶。 设计组件库另外一个要注意的就是解偶， 组件之间尽量做到不要互相依赖，这就需要每一个组件职责清晰。同时也需要组件库的层次是清晰的，基础库，帮助库，UI库 有层次界线，低层的库不要倒置依赖高层的库。

其它

• 关于预编译 预编译是双刃剑，它可以加快编译速度，但经常被滥用，很多人图方便把很多头文件都加到预编译，容易导致头文件依赖混乱。 我的建议是只把General Level组件的头文件加到预编译。

转载于:https://www.cnblogs.com/yulang314/p/5071685.html