简介

笔者的第一份iOS开发工作，从事的是消息模块消息链路及商业化的建设。在商业化建设过程中，为了更好的服务业务，满足业务快速迭代诉求，建设了一套UI组件化方案。在此简单记录一下，持续完善中。

背景

• 消息模块承接满足一定关系下的双方沟通能力，相对来说数据模型和交互场景是稳定和确定的，需要尽量减少因上层业务迭代导致的基础能力的变更，保障模块的稳定性。
• 消息模块有不同的业务形态下的聊天场景，比如单聊包括商家与消费者、淘友与淘友；群聊包括商家群、淘友群、大促群。不同的业务需要在对应的业务形态下的聊天场景下得到业务呈现，以获得业务曝光的增长。
• 业务迭代期望有一定的动态能力且不依赖端侧发版，消息模块的Native能力升级是依赖每个月的版本迭代。

挑战

• 如何平衡消息模块稳定性诉求和业务不依赖发版的动态诉求？

分析

• 我们通过对业务的诉求进行了梳理，虽然业务需要动态能力来随时满足业务变更，但业务形态相对来说比较简单，能够在合适的位置提供对应的坑位来呈现业务，如聊天页的导航栏下方、输入框上方、输入面板等等
• 样式上虽然有业务诉求，但是经过沟通后确认，大致是大卡、小卡、收起几种样式状态，可以统一交互风格。
• 对于不能展示缓存、需要时刻展示最新的业务内容，业务服务端愿意承担对应的资源消耗。

方案

UI组件化包括的能力

• 组件协议化，方便在配置中进行组织
  • 组件标识，用于标识组件类型
  • 组件属性，作为基础的入参
  • 组件样式，style字段里有基本的描述
  • 组件关系，通过children字段包含子组件，建立层级关系
• 页面配置用于描述组件与组件的布局和层级关系
  • 每个页面对应一份配置，生成一个容器对象，该对象负责组件的创建、VC的生命周期透传
  • 容器解析配置中描述组件的布局信息，解析出对应的组件实例和组件层级关系
  • 容器加载组件时，默认采用的是垂直线性布局的方式，以简化布局方案
• 组件间的事件通信方式
  • 父子组件间的事件冒泡和拦截
  • 基于容器的事件订阅方式

UI组件类型

• 承接消息基础能力的组件，如消息列表组件、发送消息组件、导航栏组件
• 承接业务动态诉求的通用动态组件，如H5组件、Weex组件、小程序组件
• 其他自定义的Native业务组件，如商品发送组件、订单发送组件

页面容器的定义

• 容器与页面一一对应，容器上下文能够拿到页面对应的url和query，以及补偿必要的参数，以保证上下文参数的完善
• 容器是组件订阅事件的载体，组件能够在上下文中获取到页面容器，并通过容器订阅事件的接口订阅关心的事件
• 容器能够向组件透传页面的生命周期(如viewWillAppear)，组件根据实际业务情况做出对应的处理

总结

优点

• 组件描述的业务能力明确也单一，组件与组件相互间不依赖，彼此间的交互通过约定的事件协议，相对比较解耦。
• 通过提供具有动态能力的组件(如H5、Weex、小程序等)，来帮助业务不依赖发版的方式完成业务诉求
• 给不同维度业务提供不同的页面配置，满足不同业务下的多样化诉求，同时聊天基础组件能力确定且稳定

缺点

• 没有很好的描述事件的处理规则，通过文档约定事件的方式，随着业务复杂度上升后，维护成本也越来越高
• 布局能力过于单一，面对一些复杂的交互场景，需要封装大组件包含小组件的方式来解决，灵活性不足

展望

• 增强配置的能力，在配置中增加对事件的描述，包括事件名称和事件参数。这样通过阅读配置，能够知道配置对应的页面在消费哪些事件。
• 接入或自建渲染框架，来代替现有的配置，以增强布局能力不足的问题。目前笔者团队采用的是合作团队的一套类Android XML的布局解析方案。