iOS项目的目录结构和开发流程

转自无网不剩的博客

网上相关的资源不多，开源的且质量还不错的iOS项目也是少之又少，最近正好跟同事合作了一个iOS项目，来说说自己的一些想法。

 

目录结构

AppDelegate

Models

Macro

General

Helpers

Vendors

Sections

Resources

 

一个合理的目录结构首先应该是清晰的，让人一眼看上去就能大概了解目录的职责，且容易应对新的变化。

 

AppDelegate

这个目录下放的是AppDelegate.h(.m)文件，是整个应用的入口文件，所以单独拿出来。

 

Models

这个目录下放一些与数据相关的Model文件，里面大概是这样：

 

Models

    |- BaseModel.h

    |- BaseModel.m

    |- CollectionModel.h

    |- CollectionModel.m

    ...

 

Macro

这个目录下放了整个应用会用到的宏定义，里面大概是这样：

Macro

    |- AppMacro.h

    |- NotificationMacro.h

    |- VendorMacro.h

    |- UtilsMacro.h

    ...

 

AppMacro.h 里放app相关的宏定义，如:

// 表情相关

#define EMOTION_CACHE_PATH @"cachedemotions"

#define EMOTION_RECENT_USED @"recentusedemotions"

#define EMOTION_CATEGORIES @"categoryemotions"

#define EMOTION_TOPICS @"emotiontopics"

 

// 收藏相关

#define COLLECT_CACHE_PATH @"collected"

 

// 配图相关

#define WATERFALL_ITEM_HEIGHT_MAX 300

#define WATERFALL_ITEM_WIDTH 146

 

NotificationMacro.h 里放的是通知相关的宏定义。

 

UtilsMacro.h 里放的是一些方便使用的宏定义，如：

#define UIColorFromRGB(r,g,b) [UIColor \

colorWithRed:r/255.0 \

green:g/255.0 \

blue:b/255.0 alpha:1]

 

#define NSStringFromInt(intValue) [NSString stringWithFormat:@"%d",intValue]

 

VendorMacro.h 里放一些第三方常量，如：

#define UMENG_KEY @"xxxxx"

#define UMENG_CHANNEL_ID @"xxx"

 

如果有新的类型的宏定义，可以再新建一个相关的Macro.h。

 

General

这个目录放会被重用的Views/Classes和Categories。里面大概是这样：

General

    |- Views

        |- TPKScollView

        |- TPKPullToRefresh

        ...

    |- Classes

        |- TPKBaseViewController

        |- TPKHorizontalView

        ...

    | - Categories

        |- UIViewController+Sizzle

        |- UIImageView+Downloader

        ...

这里的TPK是项目的首字母缩写。

 

Helpers

这个目录放一些助手类，文件名与功能挂钩。里面大概是这样：

Helpers

    |- TPKShareHelper

    |- TPDBHelper

    |- TPKEmotionHelper

    ...

 

助手类的主要作用是帮助Controller瘦身，也可以提供一定程度的复用。

 

Vendors

这个目录放第三方的类库/SDK，如UMeng、WeiboSDK、WeixinSDK等等。

 

Sections

这个目录下面的文件对应的是app的具体单元，如导航、瀑布流等等。里面大概是这样：

Sections

    |- Menu

    |- Setting

    |- Collection

    ...

 

Resources

这个目录下放的是app会用到的一些资源，主要是图片。

 

Cocoapods

业务无关的类库可以通过 Cocoapods 来方便地管理，如SDWebImage, Reachability等等。还有一些是多个应用都会用到的基础模块，比如HBAPI、HBSNS 、HBFoundation（HB为公司名首字母）等等，可以建一个私有的git repo，然后加到podfile中，这样如果HBAPI有更新，只需要pod update一下就行了。

 

顺便说一下HBFoundation，这个git仓库中可以放一些自己写的所有应用基本上都会用到的小模块。如很多app都会有隔一段时间跳出一个求好评的alertView，就可以写一个HBRating类，这样需要使用该功能的app只需加上一句：[HBRating checkIfShouldPopupWithAppID:(NSInteger)appID]就行了。又比如app都有接受push notification的需求，可以写一个HBAPNS类，等等。

 

开发流程

在拿到设计图后，就可以针对设计图抽离出可复用的Classes/Views/Helpers，考虑一下某个效果的具体实现，使用合适的设计模式来避免大量的if/else嵌套，等等。不要一下子就钻到Sections中去实现页面效果和功能，初看起来可能会快一点，但只要有点复杂度的项目，这种做法到后来只会吃尽苦头，代码会变的越来越难维护。所以前期一定要做好充足的准备工作。

 

经验有限，如果你有更好的想法，欢迎交流：）

 

 

• 本文由CocoaChina--不再犹豫（tao200610704@126.com）翻译

• 作者：@NIkant Vohra

• 原文：7 Things you must absolutely do before writing an iOS app

这两年，我一直在编写并发布有质量的iOS 应用。我发现大多数的开发人员有直接跳进编码应用程序的核心逻辑的倾向，因为这是乐趣所在。遵循流程开发是很无聊的。

我了解到最有效的方式是，如果你提前花些时间正确设置项目，你将会为将来节省大量的时间。如果你是一位独立开发者，你可能意识不到下面提到的这些步骤的重要性。大多数优秀的应用程序都由团队开发，如果遵循以下步骤，肯定能帮你减少挫败感并提升应用质量。

1.为工程设置编码风格规范

编码风格规范指的是在使用特定语言写代码之前要明确遵守的风格和惯例，它包括类似于该使用tab键还是空格键，如何命名变量以及特定语言本身的约定俗成（像swift语言中是否该使用Classes还是Structs）。

编码规范本身没有孰对孰错。在项目开始前，你可以设置自己的编码风格，但是必须保证同组的人遵守相同的规范。编码规范能够保证代码更加统一和更易于阅读。

一些公司已经开源了Objective-C和Swift语言的编码规范。

• Ray Wenderlich/Swift Style Guide

• GitHub/swift-style-guide

• NYTimes/objective-c-style-guide

2.在写代码之前确定应用的架构

在写代码之前，确定应用架构是非常重要的。一个好的架构可以提升应用的可测试性，更加易于理解并且能降低维护成本。你可以使用传统的MVC架构，或者使用更加流行的MVVM或VIPER架构，这里提供了大量的资源来介绍这些架构。

• iOS Architecture Patterns（中文版：iOS 架构模式--解密 MVC，MVP，MVVM以及VIPER架构）

• Issue 13 Architecture *objc.io

• Modern application architectures (Reactive programming, MVVM and beyond)

3.设定应用的目录结构

为了使数以百计的源代码文件至始至终保存在相同的目录中，最好是根据项目的架构制定目录结构，例如，你可以使用以下的目录结构：

首先，在Xcode的Project Navigator中工程名称分组下面，以group的形式创建它们（小黄色的文件夹），然后，通过打开Xcode右边的File Inspector，为每个创建的group链接到真实的项目路径下对应的目录，点击File Inspector中小的灰色的文件夹icon，在工程目录下创建对应group名称的子目录。

这个看起来是件小的事情，却可以使你的项目更加有条理且易于理解。

了解更多目录结构可以参考以下资源：

• futurice/ios-good-practices

4.项目依赖管理

你当然会在项目中使用第三方库，在项目中，你可以有三种方式可以管理项目依赖。

• CocoaPods

CocoaPods是适用于Swift和Objective-C Cocoa项目的依赖管理库，它有将近10000个开源库，可以优雅地帮你管理项目的规模。它是最有效的方式做依赖管理，就像Ruby中的Gems。

Youtube上有一个google开发者创建的滑稽的视频（地址，需FQ）来解释为什么必须在项目中使用CocoaPods。

• Github Submodules

你也可以使用Github Submodules管理你的项目依赖作为子库，相比CocoaPods，Github Submodules的优点在于它是sub-repos- 这不仅意味着git和git GUIs能够隐式识别他们，并且也可以获得更多支持，同时意味着你的工程依赖能够更加紧密的联系到他们的git仓库，而Cocoapods则不能。

submodules的问题是：你的工程不拥有你依赖库的源代码，仅仅是拥有一个引用到submodule的仓库。大多数情况你控制不了这些代码仓库。

• Carthage

Carthage被认为是往Cocoa应用中添加框架的最简单的方法。Carthage使用xcodebuild编译framework二进制，但是把集成的任务留给了用户。CocoaPods的目的是对用户简单，但是Carthage对用户来说是灵活的、不干涉的。

不幸的是，Carthage的最大的缺点是----只支持iOS8及以后版本。

这三个当中，我最常用并且我个人最喜欢的是CocoaPods，因为它设置超级简单，并且提供了数以千计的第三方库供你访问。

5.为应用设置合适的Scheme

当你点击了Run、Test、Profile、Analyze或者Archive 操作后，Schemes告诉Xcode什么会发生。通常，每个操作对应一个target和一个编译配置。你也可以传递启动参数，比如应用运行的语言(测试本地化很有用)或者debug时设置一些判断的标识位。

建议Scheme的命名规则采用MyApp () [Environment]:

你也可以使用Target制作不同的发布、测试以及开发来编译程序，如以下描述：

• How to Use Xcode Targets to Manage Development and Production Builds

6.设置合适的Certificates和Provisioning Profiles

在测试和发布应用过程中，这个是开发者最头疼且重要的步骤。证书对代码签名来说是必须的，你可以在真机上运行应用程序。

有两种类型的证书：

• 开发证书：每个团队的开发者都有自己的证书，需要请求生成。Xcode会为你做这些，但是最好不要点击“Fix issue”按钮，并且能够理解点击这个按钮会真正执行什么。开发证书是发布应用的开发版本到设备上。

• 发布证书：可以有多个，但是最好保持一个公司一个发布证书，通过内部渠道分享相关的秘钥。发布应用到App Store时需要这个证书，或者是公司内部的企业级应用分发。

• Provisioning Profiles

Provisioning Profiles 可能是系统中最容易引起混淆的部分了，如果你访问苹果开发者网站，你会注意到你可以创建两种类型的Provisioning Profiles（开发和发布）。Provisioning Profiles是“以这个证书的私钥作为签名的应用可以在这些设备上正常运行: https://www.quora.com/What-are-the-differences-between-certificates-provisioning-profiles-and-identifiers

你可以阅读更多相关资源:

• Maintaining Your Signing Identities and Certificates

• What is a Provisioning Profile? Part 2

7.设置应用持续集成和交付过程

建立一个持续集成和交付过程已成为关键，因为现在它可以帮助您在开发早期发现bug和节省大量的开发人员的时间。

持续集成 (CI) 是一种开发实践，要求开发人员一天将代码同步到共享存储库几次。每次提交都会用自动脚本进行验证，可以使团队尽早的发现问题。

很多工具可以帮你做iOS应用程序的持续集成，比如 Xcode Server、Jenkins和Travis CI。

• About Continuous Integration in Xcode

• Travis-CI:Test and Deploy with Confidence

• iOS CI with Jenkins

持续交付 (CD) 是一个软件工程的方式，可以使团队在短周期内开发软件，确保软件可以在任何时间可靠地发布。它旨在更快、更频繁地构建、测试和发布的软件。

为什么使用持续交付？

• 可以在准备应用提交、上传截图以及发布应用上节省数天时间。

• 如果在同事休假期间，但你发现一个严重问题需要修复并发布怎么办？在发布更新版本时不需要依赖某一个人。

• 通过更频繁和小版本的更新，提高软件质量和反应时间。

虽然有大量的工具供持续交付，我个人最喜欢的是Fastlane。它非常容易安装，并提供了一些强大的功能，可以使你整个的编译和发布过程自动化。

• Fastlane

如果你喜欢这篇文章，欢迎推荐，以便其他人也可以看到。

转载：cocoachina