UI组件化--干掉shape终极一战

背景

UI组件化对项目有正向收益，不仅能提效，还能保证高度的视觉还原度，减少和UI设计师沟通成本，所以也得到了大家的认可。

所以每个项目都会启动UI组件化建设，但是UI视图是和项目强相关的，项目间无法复用，导致大家疲于实现，重复造轮子，拖延下班时间，那么基于上面的背景，有没有更好的解决方案呢，答案是有的，下面介绍一下UI组件化在项目中的实施经验，下面分为目标、工程架构、组件架构、组件实现来展开。

目标

对现有UI组件化进行容器化抽象，底层UI组件提供最大功能集合，完全解耦业务逻辑，业务方根据自己需求，基于基础组件开发，通过属性配置或者组合的方式达到复杂的效果，所以只要底层组件抽象的足够好、能力足够全，就能大大的提高开发效率，后期适配也不会涉及核心逻辑修改，一定程度的保证了功能的稳定性

工程架构

module划分

所有的ui组件统一收敛到uikit下，其下面moudle划分以是否非常通用为依据，如果非业务属性，并且特别通用的模块组件，抽取单独module，方便解耦和复用，如果不是则统一放在同一个module下，这样uikit模块划分如下：

• app

空壳工程，可以单独运行

• demo

对所有的组件提供demo，里面的功能也可以在调试面板中打开

• uikit

依赖widget和module，业务使用ui组件直接依赖uikit即可

• widget

  • DivideLine

• XRadioGroup

• LoadingView

• ShimmerLayout

• ...

• uikit-module

  • flatButton

• roundView

• load

• dialog

• imageSelect

• toast

• ...

工程分层

工程架构可以分为5层，分别是：基础控件、组合控件、业务UI组件、桥接、demo。

• 基础控件：提供原子能力，单点控件，比如层叠布局FlowLayout、骨架控件ShimmerLayout、按钮Flatbutton

• 组合控件：会依赖基础控件，比如Dialog、ImageSelector，这些控件UI会比较复杂，所以会用到FlatButton、ShimmerLayout等基础组件来提高开发效率

• 业务UI组件：这个就是我们真正要实现的UI组件，基于设计要求定制开发，在基础控件和组合控件上配置业务偏好，组合成业务组件，开发工作量比较小

• 桥接：业务层不感知UI组件的个数和依赖关系，业务层只依赖uikit，而UI组件的依赖管理收敛到uikit中，这样的好处就是，后续迭代只在uikit维护依赖关系即可

• Demo: 一个好的组件除了使用文档，还需要有直观的示例代码，demo可以直接集成到调试面板中

架构分层如下图：

一个好的架构应该层次分明、低耦合、高扩展，对组件的增删支持的足够友好，任何组件都能准确的找到对应的分层，并且不会改动到已有代码，所以review一下刚刚设计的架构，基本上满足需求，架构设计符合预期。

架构设计好之后的步骤就是实施了，如何和现有的工程做结合呢，UI组件按阶段可以分为：开发阶段、稳定阶段，理想的开发模式为开发阶段在宿主工程中开发调试，但是放宿主工程中会带了编译慢的问题，组件开发和业务是接耦的，所以希望代码在宿主工程，demo和组件开发可以单独运行，当组件开发完成，到了稳定阶段，组件代码修改频率降低，同时加快编译速度，UIKit组件发布到远程maven仓库，最终uikit工程独立出来，单独迭代，下面是工程架构实现

UI组件和宿主打包编译

settings.gradle

includeIfAbsent ':uikit:uikit'
includeIfAbsent ':uikit:demo'
includeIfAbsent ':uikit:imgselector'
includeIfAbsent ':uikit:roundview'
includeIfAbsent ':uikit:widget'
includeIfAbsent ':uikit:photodraweeview'
includeIfAbsent ':uikit:flatbutton'
includeIfAbsent ':uikit:dialog'
includeIfAbsent ':uikit:widgetlayout'
includeIfAbsent ':uikit:statusbar'
includeIfAbsent ':uikit:toolbar'
复制代码

common_business.gradle中一键依赖

apply from: