最近在搭建新项目的iOS框架，一直在思考如何才能搭建出高可用App框架，能否避免后期因为代码质量问题的重构。以前接手过许多“烂代码”，架构松散，底层混乱，缺少规范，导致团队开发时代码风格迥异，清晰的项目结构和良好的代码规范是保证产品质量的关键，下面分享一下我的架构思路。

 

 

    

 

    架构原则：易读性、易维护性、易扩展性。

 

 

    做好一件事，花在思考上的时间应该多于执行。

 

    首先根据产品需求和设计图，脑中先建立一个产品架构：

 

 

    社交？媒体？游戏？运动？音视频？电商……要搞清楚你要做一个什么类型的App，不同类型的产品，技术选型也有所不同，在这我是搭建一个基础App架构，可以在此基础上拓展社交、电商、音视频等！

 

 

    根据当前产品的需求以及未来可能有的需求(我怎么知道未来会有什么需求？可以参照竞品，可以发挥想象，如果产品说：“我们要做IM文字聊天，只做文字！不做音视频，以后都不做！” 类似这样的承诺，你如果信了他的邪……后面的故事就精彩了。。哈哈哈哈哈哈。。。。所以说这时候你就要考虑到后面会有语音+视频聊天，在设计的时候不要偷懒，预留一定空间，当某天产品反悔的时候，你可以微微一笑，从容应对。

 

    一把拉回话题，接着说技术选型，通常我会选择一些当下比较热门、好用的第三方框架，例如： YYKit ，YYKit 是一组庞大、功能丰富的 iOS 组件，包含Model解析、图片加载、缓存等基础服务，都是基于Category设计的，使用方便且性能高于一些老的框架，用过的都说好。

 

    其他框架的选择可以根据项目需求，去GitHub上搜索，星星多的每个都看一下，会给你增加一些思路。

 

    程序猿长得可以保守，思想一定不能太保守。

 

 

   

 

    如上图，我是这样搭建App目录结构的，从下到上，使用Pods管理第三方框架，将第三方框架进行二次封装，供给顶层使用，尽可能减少各模块之间的耦合度，只为更清晰。

 

 

   

 

    1. AppDelegate是应用的代理，应用级的事件都委托它处理，包含启动退出、推送等事件，以及IM、支付等第三方的回调，这使得AppDelegate内代码庞大，错综复杂，十分不利于阅读和维护，因此我新增了一个AppDelegate+AppService类别，用来处理生命周期之外的业务，AppDelegate作为事件入口，具体实现直接调用类别里的方法，只为更清晰。

 

   

 

    2. Modules包含了应用内的功能模块，根据底部Tab栏划分并关联实体文件夹(默认是虚拟的要手动建立实体文件夹拖进来)，每个模块内使用的是MVC模式，有人会问为什么多了Resource和Service文件夹，MVC是一种设计思想，并非死套路就仨文件夹，根据实际需求适当增加，在这我选择在Service封装数据请求，VC里调用拿数据即可，至于Resource为什么在这，我认为当功能模块层级较多时，每个大功能模块都对应许多资源，对应到模块内用起来方便，当然也可以放到最外层的Resource文件夹里，建立对应的模块名称，在这儿我是选择把公共的放到最外层Resource里，功能相关的放到模块里的Resource文件夹内，只为更清晰。