Architecture►第七章：技术选型

UI组件选择历程

[toc]

UI组件选择历程

前言

对于组件定制(非从0开发)，现有业内有Bruno和Templates等成套组件库，其中多为个人或团队开发，少为公司或企业开源；

组件的实现，有使用多个业内公认性强的独立组件和使用成套组件开发两种方式。

一、现有UI规范与三方UI组件库比较

与三方的比较相似度：

1：不一致，可定制成UI样式，无影响

2：不一致，不可定制成UI样式，

编号 类型 现有UI规范图 三方UI组件图 相似度 是否已实现 备注
1 Loading image-20220112191111893image-20220112191111893 image-20220112193119354image-20220112193119354 0% 已实现
2 Toast image-20220112193921648image-20220112193921648 image-20220112193810225image-20220112193810225 100% 已实现
3 Alert/Dialog image-20220112190638017image-20220112190638017
image-20220112191225610image-20220112191225610
image-20220112192144651image-20220112192144651		 image-20220112193013294image-20220112193013294
 10% 已实现
4 ActionSheet image-20220112191823819image-20220112191823819 image-20220112193433345image-20220112193433345 40% 已实现
5 ItemPicker image-20220112191918224image-20220112191918224
image-20220112192433517image-20220112192433517		 image-20220112192909758image-20220112192909758 60% 已实现
6 DatePicker image-20220112191956752image-20220112191956752 image-20220112192754849image-20220112192754849 60% 已实现
7 AreaPicker image-20220112192520814image-20220112192520814 image-20220112193655738image-20220112193655738 0% 已实现
8 Button image-20220112195209438image-20220112195209438
image-20220112195319946image-20220112195319946		 image-20220112194425751image-20220112194425751
image-20220112194521899image-20220112194521899		 95% 已实现

基于，目前app中对应的UI组件，基本已实现过，只是缺少统一，导致有复制代码，局部定制的不当操作；

又由于避免重复开发，统一组件，是必须处理的事项。所以，当前的处理方案为抽离并保持已实现的UI，新开发部分采用从组件中调用。此工作与后续其他部分不重合。

而后续如有其他需要定制成组件的部分，对UI实现的图，继续优先与第三方组件库从匹配度、扩展性、维护性等角度考虑。

如果从数据上比价，得知该三方UI组件库与现有UI匹配度较低(匹配度=符合规范的组件个数/总的组件个数)。

基于匹配度较低的情况，处理方案有如下两种。

方案一：UI规范向三方组件靠齐，即后续UI设计使用三方组件样式；

方案二：放弃三方组件库，分别使用独立三方组件，定制成现有UI想要的特有样式；

二、UI规范选择方案比较

方案一：
使用三方规范
(由组件库集体定制)		 方案二：
使用自己规范
(由独立组件分别定制)
前期开发效率 高
美观性 高
前提 舍弃部分美观性，需领导批准，同步UI团队 正常开发

1、开发优先，放弃特有风格

如果从未开发，则基于前期开发效率考虑，使用方案一成套组件库进行开发（需领导批准，同步UI团队改变设计规范）。

2、风格保持，实现次之

如果为了保证维持app特有的风格，组件实现则必须与UI设计保持一致，则

1、三方成套组件库与UI匹配度高：

直接使用

2、三方成套组件库与UI匹配度低：

则组件的实现，有以下两种方式

①尝试基于成套组件库，进行深度定制，如无法定制指定效果，放弃；

②使用与UI匹配度高的独立三方组件，进行快速定制；

三、保持UI风格使用自己规范时，开源库选择标准

成套组件库 VS 各独立组件，我们主要从以下三点考虑：

一、后期维护性。维护性是避免该组件不进行维护，导致需要使用新的组件进行替换。从概览上讲成套组件的不维护风险比由多个独立组件组成的集体不维护风险概览大，从而产生的维护替换成本也会较高。

二、扩展性。扩展性是指该组件支持的可定制程度。为了避免有些组件早高度封装下，可定制程度不高，当后期需要补充定制其他功能时候，无法支撑需求，从而导致需要修改源码或使用新组件来替换，我们会优先考虑扩展性强的组件，从而节省后期的维护成本。

三、受众广度。指一个组件或一群组件组成的组件库在业内使用开发者的多少或流行度。以下以轻提示控件toast举例，单个toast和组件库里的toast，在https://pub.flutter-io.cn/上查到的受众广度分别如下：

toast-fluttertoasttoast-fluttertoast

toast-Brunotoast-Bruno

对于项目中前期已实现的组件，是优先以使用github上与我们匹配最高且Star最多的组件来进行二次封装，从而定制成App所需的实际样式。如无或只是简单封装，才使用一次封装和定制，为的是避免对只是简单封装的控件也产生不必要的依赖。就开发成本上来讲，与使用成套组件无实际差别，并不会多增加，且有降低成套组件后续维护性风险的好处。

四、后续

基于目前从产品、UI上已统一使用Bruno中的风格，所以后续对于前期未实现的组件（如后续可能需要的底部弹窗下拉关闭组件）会直接使用Bruno组件库中的组件；而前期已实现的部分，在产品和UI有需要更新风格的情况下，也会按需进行替换成组件库中的风格

End