架构

设计一个App的思路：

原则：易读 易维护 易扩展  ；技术储备；语言选择

组成：

1.应用入口(Appdelegate):存放推送 IM 支付回调等

2.功能模块:根据业务进行划分：可以灵活采用MVC MVVM MVP

3.管理模块:登陆状态信息 单例 网络监听 广告页

4.工具类:自己写的工具类

5.基类:一些定制化的内容页面 样式 空数据页面 无网络提示页面

6.分类:对系统类 自定义类增加的类别

7.宏定义文件:全局通用的宏定义 方法

8.资源文件:图片 json xml test plist

9.第三方库的封装:

10.Cocoapods:

---

重构需要考虑的因素:

1.明确重构的目的和重用性

2.定义重构完成的界限

3.持续渐进式重构

4.确定当前的架构状态

5.不能忽略数据的重用性

6.管理好技术债务

7.远离虚华的东西 追求实际

8.做好准备面对压力,做好面对非技术的准备

9.了解当前业务

10.时刻注意代码的质量

11.团队一致 做好准备

---

MVC:https://www.jianshu.com/p/eedbc820d40a

MVC是软件工程中的一种软件架构模式，它把软件系统分为三个基本的部分：模型Model、视图View以及控制器Controller；

数据Model： 负责封装数据、存储和处理数据运算等工作

视图View： 负责数据展示、监听用户触摸等工作

控制器Controller： 负责业务逻辑、事件响应、数据加工等工作

在iOS中，M和V之间禁止通信，必须由C控制器层来协调M和V之间的变化，C对M和V的访问是不受限的

Controller 可以直接与 Model 对话（读写调用 Model），Model 通过 Notification 和 KVO 机制与 Controller 间接通信

Controller 可以直接与 View 对话，通过 outlet，直接操作 View，outlet 直接对应到 View 中的控件，View 通过 action 向 Controller 报告事件的发生(如用户 Touch 我了)。Controller 是 View 的直接数据源（数据很可能是 Controller 从 Model 中取得并经过加工了）。Controller 是 View 的代理（delegate)，以同步 View 与 Controller

MVC的缺点在于并没有区分业务逻辑和业务展示, 这对单元测试很不友好

---

MVP:

MVP模式是MVC模式的一个演化版本（好像所有的模式都是出自于MVC~~），MVP全称Model-View-Presenter;

MVP的 V 层是由UIViewController 和UIView 共同组成;

Model：与MVC中的model没有太大的区别。主要提供数据的存储功能，一般都是用来封装网络获取的json数据的集合

Presenter：作为model和view的中间人，从model层获取数据之后传给view，使得View和model没有耦合

view 将委托presenter 对它自己的操作，（简单来说就是presenter发命令来控制view的交互，要你隐藏就隐藏，叫你show 你就乖乖的show）

presenter拥有对 view交互的逻辑（就是上面说的意思）

presenter跟model层通信，"Present"一方面通过Service层调用接口获取数据给Model层,并将数据转化成对适应UI的数据并更新view

presenter不需要依赖UIKit

view层是单一，因为它是被动接受命令，没有主动能力

presenter 作为业务逻辑的处理者，首先要向Service层拿数据赋值给model，所以它将可以向model层通信。其次，UI的处理权移交给了它，所以它需要与view成通讯，发送命令更新UI。同时，UI的响应将触发业务逻辑的处理，所以view 层向presenter层通讯，告诉他用户做了什么操作，需要你反馈对应的数据来更新UI。这样就完成了从用户交互获得交互反馈到整个业务逻辑。

关于C端和P端的循环引用的问题, 直接用weak关键字就可以解决了

总得来说MVP的好处就是解除view与model的耦合，使得view或model有更强的复用性

只需要初始化P层, 然后调P层的接口就可以了. 至于P层内部的逻辑, 我不需要知道

V层也只专注于视图的创建

M层只专注于模型的构建(字典->模型)

优点：

对Controller进行瘦身，View和Model之间不存在耦合，同时也将业务逻辑从View中抽离，复用性更好

缺点：

由于对视图的渲染放在了Presenter中，所以视图和Presenter的交互会过于频繁。还有一点需要明白，如果Presenter过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么Presenter也需要变更了

---

MVVM:

MVVM

在MVVM 中，view 和 view controller正式联系在一起，我们把它们视为一个组件

view 和 view controller 都不能直接引用model，而是引用视图模型（viewModel）

viewModel 是一个放置用户输入验证逻辑，视图显示逻辑，发起网络请求和其他代码的地方

使用MVVM会轻微的增加代码量，但总体上减少了代码的复杂性

MVVM模式将Presenter改名为ViewModel,基本上与MVP模式完全一致。

唯一的区别是，它采用双向绑定(data-binding) : View<->ViewModel, ViewModel作为Model中值的映射，是数据发生改变时，通知View中发生改变，以后不需要考虑View和Model之间的交互更新，只需着手界面布局逻辑即可。

①View和Model 不直接关联，而是通过ViewModel作为枢纽，沟通View和Model之间的关系。

②View中控件的值与属性进行绑定，通过KVO键值观察(这样当model的值发生变化时,View会自动发生改变) 

View和Model通过ViewModel实现动态关联

MVVM 的注意事项

view 引用viewModel ，但反过来不行（即不要在viewModel中引入#import UIKit.h，任何视图本身的引用都不应该放在viewModel中）（PS：基本要求，必须满足）

viewModel 引用model，但反过来不行

MVVM 的优势:

低耦合：View 可以独立于Model变化和修改，一个 viewModel 可以绑定到不同的 View 上

可重用性：可以把一些视图逻辑放在一个 viewModel里面，让很多 view 重用这段视图逻辑

独立开发：开发人员可以专注于业务逻辑和数据的开发 viewModel，设计人员可以专注于页面设计

可测试：通常界面是比较难于测试的，而 MVVM 模式可以针对 viewModel来进行测试

MVVM 的弊端:

数据绑定使得Bug 很难被调试。你看到界面异常了，有可能是你 View 的代码有 Bug，也可能是 Model 的代码有问题。数据绑定使得一个位置的 Bug 被快速传递到别的位置，要定位原始出问题的地方就变得不那么容易了

对于过大的项目，数据绑定和数据转化需要花费更多的内存（成本）

绑定是一种响应式的通信方式。当被绑定对象某个值的变化时，绑定对象会自动感知，无需被绑定对象主动通知绑定对象。可以使用KVO和RAC实现。例如在Label中显示倒计时，是V绑定了包含定时器的VM。

---

组件化:（使用cocoapods进行组件化的实现）

组件化方案的几种实现：

方案一：url-block

通过在启动时注册组件提供的服务，把调用组件使用的url和组件提供的服务block对应起来，保存到内存中。在使用组件的服务时，通过url找到对应的block，然后获取服务

出现的问题：

1、需要在内存中维护url-block的表，组件多了可能会有内存问题

2、url的参数传递受到限制，只能传递常规的字符串参数，无法传递非常规参数，如UIImage、NSData等类型

3、没有区分本地调用和远程调用的情况，尤其是远程调用，会因为url参数受限，导致一些功能受限

4、组件本身依赖了中间件，且分散注册使的耦合较多

方案二：protocol-class

通过protocol定义服务接口，组件通过实现该接口来提供接口定义的服务，具体实现就是把protocol和class做一个映射，同时在内存中保存一张映射表，使用的时候，就通过protocol找到对应的class来获取需要的服务

出现的问题：

依然没有解决组件依赖中间件的问题、内存中维护映射表的问题、组件的分散调用的问题

方案三：target-action

通过给组件包装一层wrapper来给外界提供服务，然后调用者通过依赖中间件来使用服务；其中，中间件是通过runtime来调用组件的服务，是真正意义上的解耦，也是该方案最核心的地方。具体实施过程是给组件封装一层target对象来对外提供服务，不会对原来组件造成入侵；然后，通过实现中间件的category来提供服务给调用者，这样使用者只需要依赖中间件，而组件则不需要依赖中间件

方案四：使用cocoapods进行组件化的实现）

具体就是建立一个项目工程的私有化仓库，然后把各个组件的podspec上传到私有仓库，在需要用到组件时，直接从仓库里面取

---

1.添加Podfile文件 pod init 然后会发现你的工程目录下多了Podfile文件

2.生成xcworkspace工程 pod install

3.新建一个Lib（自己起名）文件夹，用来存放组件库（其他独立工程）然后cd到Lib下 执行 pod lib create 

XXX(工程名)

4.打开新建的XXX(工程名)工程里的Example，可以看到pods里面，有个ReplaceMe的文件，意思就是要替换它，换成我们自己需要对外提供的类

5.新建一个类，比如TRUXXX，复制粘贴到ReplaceMe同级目录下，并删掉ReplaceMe.m文件

6. 之后cd到Lib/TRUXXX/Example/文件目录下，执行pod install 这个时候在Development Pods文件下会多出这两个文件，这就是本地开发的pods文件

7.而Podfile的内容其实是

pod 'TRUXXX', :path => '../'

说明他获取的是本地路径

然后删除Example for TRUXXX里面的TRUXXX类，不然运行会因为类重复报错。

至此，一个组件的本地库就创建完成了。

8. 壳工程使用本地组件库

首先cd到壳工程LZDemo目录下，修改LZDemo的Podfile文件，增加

pod 'TRUXXX', :path => 'Lib/TRUXXX'

执行 pod install

---

组件需要对外提供依赖关系。所以我们还得多做一步操作，那就是增加podspec文件

以TRUXXX为例，cd到TRUXXX目录下，执行

git tag 0.1.0

git push --tags

这个tag分支就是将来提供给别人依赖的版本号分支，有了它，别人使用你的组件的时候就可以根据版本号来控制了。

改好后，在上传之前，最好先本地检查一下podspec是否合法

执行下面语句

pod lib lint --verbose

如果出现passed validation，说明通过，可以提交到cocoapods上了

成功后，就可以pod search到我们提交的库了

ps：如果搜不到，不是没传成功，是我们的本地搜索库没更新，可以先删除~/Library/Caches/CocoaPods目录下的search_index.json文件或者pod repo update一下

rm~/Library/Caches/CocoaPods/search_index.json

---

组件间通讯

1. Protocol注册方案

通过JJProtocolManager 作为中间转化

+ (void)registerModuleProvider:(id)provider forProtocol:(Protocol*)protocol;

+ (id)moduleProviderForProtocol:(Protocol *)protocol;

有组件对外提供的procotol和组件提供的服务由中间件统一管理，每个组件提供的procotol和服务是一一对应的。

例如：

在JJLoginProvider中:load方法会应用启动的时候调用，就会在JJProtocolManager进行注册。JJLoginProvider遵守了JJLoginProvider协议，这样就可以对外根据业务需求提供一些方法。

+ (void)load

{

    [JJProtocolManager registerModuleProvider:[self new] forProtocol:@protocol(JJLoginProtocol)];

}

- (UIViewController *)viewControllerWithInfo:(id)userInfo needNew:(BOOL)needNew callback:(JJModuleCallbackBlock)callback{

    CLoginViewController *vc = [[CLoginViewController alloc] init];

    vc.jj_moduleCallbackBlock = callback;

    vc.jj_moduleUserInfo = userInfo;

    return vc;

}

这样就可以在需要登录业务模块的地方，通过JJProtocolManager取出JJLoginProtocol对应的服务提供者JJLoginProvider，直接获取。如下：

id<jjwebviewvcmoduleprotocol> provider = [JJProtocolManager moduleProviderForProtocol:@protocol(JJWebviewVCModuleProtocol)]; 

   UIViewController *vc =[provider viewControllerWithInfo:obj needNew:YES callback:^(id info) { 

       if (callback) { 

           callback(info); 

       } 

   }]; 

   vc.hidesBottomBarWhenPushed = YES; 

   [self.currentNav pushViewController:vc animated:YES];</jjwebviewvcmoduleprotocol> 

2. URL注册方案 OPENURL

原理：

通过url注册服务, 其他地方通过url, 获取服务；框架在维护一个url-block的表格

特点：

每个业务组件, 都需要依赖这个框架

url维护成本高 硬解码

可以在组件内部任何地方调用/注册服务, 没有必要统一组件接口服务

[MGJRouter registerURLPattern:@"mgj://detail?id=:id" toHandler:^(NSDictionary *routerParameters) { 

NSNumber *id = routerParameters[@"id"]; 

//create view controller with id 

// pushview controller 

}]; 

首页只需调用 [MGJRouter openURL:@"mgj://detail?id=404"] 就可以打开相应的详情页。

3. Target-Action runtime调用方案

原理：

每个组件, 提供一个统一披露的接口文件

额外的维护一个中间件的分类扩展（在此处进行硬解码 通过运行时进行物理解耦）

其他地方通过target-action;的方案进行交互

特点：

统一了组件api服务

组件与框架之间无依赖关系

需要额外维护中间件类扩展

实现：

我们主要是依赖CTMediator 这个中间件工具类中主要使用如下方法：

- (id)performTarget:(NSString *)targetName action:(NSString *)actionName params:(NSDictionary *)params shouldCacheTarget:(BOOL)shouldCacheTarget

方法内部使用Runtime调用 需要传三个参数

当前需要调用的类名 （字符串）

当前需要调用类的方法名 （字符串）

需要传的参数 （字典形式）

# 通过Runtime 把字符串 转换类

Class targetClass = NSClassFromString(ClassString);

id  target = [[targetClass alloc] init];

# 把字符串转换成事件

SEL action = NSSelectorFromString(actionString);

# 如果当前类中有这个事件 那就执行这个事件 把需要的参数传值

if ([target respondsToSelector:action]) {

    return [target performSelector:action withObject:params];

}

4.使用cocoapods进行组件化的实现）

1.每个业务组件库里面会有一个控制器的配置文件（路由配置文件），标记着每个控制器的key；

2.在App每次启动时，组件通讯的工具类里面需要解析控制器配置文件（路由配置文件），将其加载进内存；

3. 在内存中查询路由配置，找到具体的控制器并动态生成类，然后使用==消息发送机制==进行调用函数、传参数、回调，都能做到。

5. 依赖注入

组件化的好处：

业务分层、解耦，使代码变得可维护；

有效的拆分、组织日益庞大的工程代码，使工程目录变得可维护；

便于各业务功能拆分、抽离，实现真正的功能复用；

业务隔离，跨团队开发代码控制和版本风险控制的实现；

模块化对代码的封装性、合理性都有一定的要求，提升开发同学的设计能力；

在维护好各级组件的情况下，随意组合满足不同客户需求；

https://www.jianshu.com/p/59c2d2c4b737创建组件化的步骤

各个组件该如何进行拆分：

1.  项目主工程：主工程就是一个空壳子工程

2.  业务组件：业务组件就是各个独立的产品业务功能模块

3.  基础工具类组件：基础工具类是各个互相独立，没有任何依赖的工具组件。它们和其它的工具组件、业务组件等没有任何依赖关系。这类组件例如有：对数组，字典进行异常保护的Safe组件，对数组功能进行扩展Array组件，对字符串进行加密处理的加密组件等等。

4.  中间件组件：中间调度者就是一个功能独立的中间件组件

5.  基础UI组件：视图组件就比较常见了，例如我们封装的导航栏组件，Modal弹框组件，PickerView组件等。

6.  业务工具组件：这类组件是为各个业务组件提供基础功能的组件。这类组件可能会依赖到其他的组件。例如：网络请求组件，图片缓存组件，jspatch组件等等

详细操作步骤：

第一步：

我们先创建一个空的iOS工程项目:MainProject，这个空项目作为我们的主工程项目，就是上面所说的壳子工程项目，然后初始化pod

第二步：

我们创建一个空工程项目:ModuleA，这个ModuleA 项目作为我们的业务A组件。然后我们初始化pod，初始化podspec文件

第三步：

我们创建一个空工程项目:ModuleB，这个ModuleB 项目作为我们的业务B组件。然后我们初始化pod，初始化podspec文件

第四步：

我们创建一个空工程项目:ComponentMiddleware，这个项目就是我们上面所说的中间调度者。然后我们初始化pod，初始化podspec文件。

第五步：

我们创建一个空工程项目: ModuleACategory，这个工程是对应业务组件A的一个分类工程。然后我们初始化pod，初始化podspec文件。

第六步：

我们创建一个空工程项目: ModuleBCategory，这个工程是对应业务组件B的一个分类工程。然后我们初始化pod，初始化podspec文件。

第七步：

我们在主工程MainProject的Podfile中引入我们的业务组件B工程ModuleB，以及引入我们的ModuleB的分类工程：ModuleBCategory。然后我们pod install。这时已将这两个组件库引入到我们的主工程中了。

#import <ModuleBCategory/ComponentScheduler+ModuleB.h>

- (void)moduleB {

    UIViewController *VC = [[ComponentScheduler sharedInstance] ModuleB_viewControllerWithCallback:^(NSString *result) {

        NSLog(@"resultB: --- %@", result);

    }];

    [self.navigationController pushViewController:VC animated:YES];

}

第八步：

上面第七步中，我们用到了ModuleBCategory 这个分类工程。这个工程我们只对外暴露了两个文件。这两文件是上面的中间调度者的分类，也就是说是中间件的分类。我们先来看下这个分类文件的.h 和.m 实现

#import "ComponentScheduler+ModuleB.h"

@implementation ComponentScheduler (ModuleB)

- (UIViewController *)ModuleB_viewControllerWithCallback:(void(^)(NSString *result))callback {

    NSMutableDictionary *params = [[NSMutableDictionary alloc] init];

    params[@"callback"] = callback;

    return [self performTarget:@"ModuleB" action:@"viewController" params:params shouldCacheTarget:NO];

}

@end

第九步：

这个分类的作用你可以理解为我们提前约定好Target的名字和Action的名字，因为这两个名字中间件组件中会用到。

因为上面第八步中引用到中间件工程，这里我们就来看下中间件工程到底做了什么工作。还记得上面第八步中，我们调用了一个中间件提供的函数：performTarget:action:params:shouldCacheTarget吧，这个是中间件核心函数。

这个函数最终调用到苹果官方提供的函数：[target performSelector:action withObject:params];

看到 performSelector: withObject: 大家应该就比较熟悉了，iOS的消息传递机制。

[Target_ModuleB performSelector:Action_viewController withObject:params];

上面这行伪代码意思是: Target_ModuleB这个类 调用它的 Action_viewController: 方法，然后传递的参数为 params。

细心的小伙伴们就会发现，我们没有看到过哪里有这个Target_ModuleB 类啊，更没有看到Target_ModuleB 调用它的 Action_viewController: 方法啊。

是的，这个Target_ModuleB类和类的Action_viewController方法就在第十步中讲解到。

第十步：

业务组件B除了提供组件B的业务功能外，业务组件B还需要为我们提供一个Target文件

#import "Target_ModuleB.h"

#import "ModuleBViewController.h"

@implementation Target_ModuleB

- (UIViewController *)Action_viewController:(NSDictionary *)params {

    ModuleBViewController *VC = [[ModuleBViewController alloc] init];

    return VC;

}

@end

从上面的实现文件中，我们可以看到，Target文件的作用也很简单，就是为我们提供导航跳转的目标控制器实例对象。这里的目标控制器实例就是业务组件B的ModuleBViewController 实例。