iOS端页面模块可配置化方案（一）
KLOOK客户端配置化方案 轻量级iOS页面模块化框架 （简介）
-
背景
- 支付成功页UI与业务逻辑耦合到一个页面控制器，导致改动困难。加上大部分以前的页面的架构设计是不太方便与我们后续业务的快速发展，因此我们需要设计一个尽量适用于APP内大部分页面的模块化方案，降低后续页面开发与页面变化所带来的研发成本。
- 多条业务线共同修改订单详情页，导致代码冲突严重，代码可读性与维护性差，影响开发效率。
-
设计原则与目标
- 框架设计要以现有架构（MVC）为基础，尽可能复用现有模块以节省时间成本（例如一个旧的Cell，只需要遵循容器协议，即可复用于新容器，并且对旧的代码没有影响），框架需要低侵入性，方便以后替换与更改。
- 以后页面内以组件为单位，通过组合的方式，只需要配置文件增删内容，不需要改动到整体页面UI代码，就可以更改页面内容。且UI组件是可以以很低的成本复用到其他页面。
-
简单分析App页面渲染与展示基本流程
-
请求网络数据 -> 渲染列表 -> 用户交互 -> 跳转新页面 -> 继续请求网络数据...
-
请求网络数据 -> 渲染列表 -> 用户交互 -> 刷新数据/更新视图/提交数据
-
-
抽象APP内有代表性的页面结构
-
纯展示界面
-
首页、城市/国家页、活动详情页、订单详情页、支付成功页、越来越多的垂直页...
image.png
-
-
具有交互逻辑界面
- 个人信息、下单页、支付页
-
-
可配置化抽象
-
页面组件以 Section 为单位，分为UI部分，与viewModel部分，UI部分负责视图样式，ViewModel负责业务逻辑，隔离UI与业务逻辑，方便复用。因为部分页面虽然UI一样，但数据Model不同，有些页面业务逻辑不变，但是UI却有改动，这样做可以隔离UI与业务逻辑，使UI与ViewModel都能达到可替换与复用的目的。
image.png
-
针对负责的模块可以使用ViewModel，但目前的实现没有使用，而是直接使用VC进行数据请求与业务逻辑处理 。后期做进一步优化的时候再考虑实现
-
统一页面容器，通过协议的方式，实现协议方法，就可以修改配置文件，放到这个页面容器中（以前我们每个页面并没有使用统一的容器，导致UI组件在页面之间复用的成本较高）
image.png
- 在统一页面容器中，Section 间可以任意组合 && Section内可以配置独立数据模型 && Section内有独立渲染与刷新数据机制
-
具体实现方案
-
字符串映射绑定Section视图，刷新指定 Section
-
使用统一容器
-
-
代码实现
-
容器协议
-
页面配置类
-
-
重构方案实现前后对比
- 看代码....
-
优势 与 局限性
-
统一容器，减少代码量，减轻负担。通常情况下只需要修改配置文件即可组装出页面，让开发者更专注于实现具体模块样式与业务。
-
逻辑清晰，业务与UI分离，利于后期维护。
-
拥抱变化，可以很方便的增删或替换Section（只需要更改配置或映射关系）
-
利于复用，理论上在所有使用统一容器的页面内都可以复用现有Section
-
暂时不支持炫酷动画，特殊业务界面暂不适用
-
-
后续
- 开发一个新的垂直页，只需要拉取数据，并配置好该垂直页需要使用的 Section
- 配置文件通过服务端下发，动态变更样式（A/B Test）
