iOS 设计模式

MVC和MVVM?
它是iOS开发中阻力最低的架构模式。MVC代码量最小，设计开销最小的模式。
MVC常见的问题:

1. 在变更model的同时去更改View的层级，这种做法假设了变更的结果，而没有等待model进行通知，如果model拒接了这个变更的话，就会发生错误，这类错误会使view和model不同步，奇怪的行为也就随之而来
2. 肥大的ViewController：viewController需要负责view层（设置view属性，展示view等），最后，它还要负责model层（获取数据，对其变形或者处理），结合它在架构中的中心角色，这使得我们很容易在不经意间把所有的职责都赋予viewconroller，变得难以管理。

如何避免ViewController 臃肿

1. 使用代码而不是 Storyboard,我们可选择用代码来定义我们的view层级，这样的变更能给我们在构建阶段更多的控制力，其中最大的有点在于，我们可以更好地掌控依赖。

2. 在扩展中进行代码重用，在多个view controller 中都出现的方法有的时候个被添加到UIViewController的扩展中区，这样一来，所有的viewcontroller就都能获取这个方法了，比如。我们可以为UIViewController 添加一个文本警告简便方法

3. 需要在viewConroller 上有某个特定的方法可用，我们可以在协议里确保这些能力。

4. 利用child view controller 进行代码重用，把你一个功能写在childViewController中，再讲childviewcontroller 添加到Viewcontroller上的做法，这样做法要容易的多，也还维护。拥有多种状态的ViewController 可将不同状态分别拆分成独立的viewcontroller中

5. 提取对象把viewController tableviewDataSource提取出来 提取对象

6. 简化view配置代码。如果viewcontroller需要构建和更新非常多的view，那么讲这部分view配置的代码提取出来会很有帮助。特别是对那些不需要双向通讯的

一个swift 的文件超过2000行就卡顿
MVVM

mvvm.png

MVVM所做的不仅仅是把代码移动到新的地方。加入一层新的view-model层的目的是双重的：

1. 鼓励将model和view之前的关系构建为一系列的变形管道。
2. 提供一套独立于app框架的接口，但是它在相当程度上代表view应该展示的状态。
3. 必须构建View-model
4. 必须建立view-model 和view的绑定
5. Model 由view-model拥有，而不是viewcontroller所拥有

---

VIPER
一个典型的Viper Module 总是有五个部分组成:View, Interactor, Presenter, Enitity, 和Router。

• View view是被动的，自己什么都做不了，它的主要职责是想演示者发送事件消息并显示UI元素。
• Interactor是一个独立于UIKit的组件，执行所有的业务逻辑，例如API 通信等。
• Presenter也是独立于UIkit的，它从视图接收消息，并决定是否将消息发送给Interactor或者是Router，它还接收来着Ineractor的数据，为视图的显示做准备
• Entity是Ineractor使用的模型
• Router在我们的应用程序中负责创建一个特定的Module和从一个Module导航到另一个Module
  参考链接

---

组件化？
组件化开发的缺点：

• 代码耦合严重
• 依赖严重
• 其它app接入某条产品线难以集成
• 项目复杂、臃肿、庞大，编译时间过长
• 难以做集成测试
• 对开发人员，只能使用相同的开发模式

组件化开发的优点：

• 项目结构清晰
• 代码逻辑清晰
• 拆分粒度小
• 快速集成
• 能做单元测试
• 代码利用率高
• 迭代效率高

CocoaPods远程私有库制作

1. Create Component Project

pod lib create ProjectName

2. Use Git

echo "# test" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin https://github.com/c/test.git
git push -u origin master
复制代码3、Edit podspec file
vim CoreLib.podspec
Pod::Spec.new do |s|
  s.name             = '组件工程名'
  s.version          = '0.0.1'
  s.summary          = 'summary'

  s.description      = <<-DESC
  description
                       DESC

  s.homepage         = '远程仓库地址'
  s.license          = { :type => 'MIT', :file => 'LICENSE' }
  s.author           = { '作者' => '作者' }
  s.source           = { :git => '远程仓库地址', :tag => s.version.to_s }

  s.ios.deployment_target = '8.0'

  s.source_files = 'Classes/**/*.{swift,h,m,c}'
  s.resources = 'Assets/*'
  
  s.dependency 'AFNetworking', '~> 2.3'
end

4. Create tag

//create local tag
git tag '0.0.1'
或
git tag 0.0.1

//local tag push to remote
git push --tags
或
git push origin 0.0.1

//delete local tag
git tag -d 0.0.1

//delete remote tag
git tag origin :0.0.1

5. Verify Component Project

pod lib lint --allow-warnings --no-clean

6. Push To CocoaPods

pod repo add CoreLib git@git.test/CoreLib.git
pod repo push CoreLib CoreLib.podspec --allow-warnings

各个组件该如何拆分

• 项目主工程：当我们工程完全使用组件化架构进行开发后，我们会惊奇的发现我们的主工程就成了一个空壳子工程。因为所有的主工程呈现出来的内容都被拆分成了各个独立的业务组件了，包括各个工具组件也是各自互相独立的。这样我们发现开发一个完整的APP就像是搭建乐高积木一样，各个部件都有，任我们随意的组合搭建，这样是不是感觉很爽。
• 业务组件：业务组件就是我们上面示例图所示的各个独立的产品业务功能模块，我们将其封装成独立的组件。例如示例Demo中的电子发票业务组件，业务组件A，业务组件B。我们通过组装各个独立的业务组件来搭建一个完整的APP项目。
• 基础工具类组件：基础工具类是各个互相独立，没有任何依赖的工具组件。它们和其它的工具组件、业务组件等没有任何依赖关系。这类组件例如有：对数组，字典进行异常保护的Safe组件，对数组功能进行扩展Array组件，对字符串进行加密处理的加密组件等等。
• 中间件组件：这个组件比较特殊，这个是我们为了实现组件化开发而衍生出来的一个组件，上面示例图中的中间调度者就是一个功能独立的中间件组件。
• 基础UI组件：视图组件就比较常见了，例如我们封装的导航栏组件，Modal弹框组件，PickerView组件等。
• 业务工具组件：这类组件是为各个业务组件提供基础功能的组件。这类组件可能会依赖到其他的组件。例如：网络请求组件，图片缓存组件，jspatch组件等等
  参考链接