播放器UI组件规划

播放器组件UI规划

现存问题思考

不通用

播放器组件UI目前只对播放器独立端适配对编辑器,VR,PAD,乃至播放器其他版本都存在不通用的情况及时同一个UI,在不用的应用上可能有几种不同的表现,需要针对这些不同的表现定制不同的资源和代码逻辑,这导致UI组件的重复代码增多,同时资源包的体积也越来越大

更新频繁

UI本身属于改动频繁且容易暴露问题的部分,放入大包后,遇到集成多个功能的时候,会频繁更改,导致发包频繁而且,由于所有应用都会用到UI组件,单个应用端的修改需要考虑是否会影响别的应用,否则通过大包出去后,别的应用可能会出现无法运行的情况

UI组件是否需要作为组件形式存在

目前,编辑器UI已经重构,不再使用UI组件,PAD端的UI大部分也是重新开发,VR大部分UI不通用这种情况下,UI组件基本只有独立端使用

方向

完全摒弃,与应用端代码合并开发

把播放组件从大包里面去除,与应用端代码合并,这样做的好处立竿见影,有三点:
    1:应用端出版本无需依赖组件出包,节约时间;
    2.让大包避免频繁更新,增强了稳定性,减少了对其他依赖大包应用的影响;
    3.各个应用有自己的代码仓库,减少了分支,维护起来会更方便,也不会对其他应用开发造成影响。
编辑器目前采用的是这种方法。PAD端目前没有合并,但是已经有自己的UI组件仓库,和现在的UI组件相差已经很大。

部分摒弃,去异留同

继续保留UI组件,保证这个组件是相对稳定并且通用的,需求不会更改频繁需要完成以下工作:
    1.策划以及各应用端对现有UI进行一个全面的梳理,找出真正共用的UI,放入UI组件
    2.剩余的UI依然合并到应用端,保证这个UI组件放到今后新的应用里面也照样无需修改立即使用
    3.后续的开发,策划同学也需要考虑到该功能对用UI的通用性,是否需要设计的更通用一些,是否可以多平台使用
只有满足以上条件,UI组件才能真正作为一个通用的组件存在,避免上述所的问题

数据保留,表现移除

采用黄金民设计的MVP或者MVVM模式,主要思路是把表现层分离出来,由各个应用端处理,数据和控制作为组件留下大体上,可以分以下步骤实现:
    1.根据选择的模式创建为数据逻辑组件,提供数据和逻辑
    2.各应用重构现在UI组件,逻辑和数据放在数据逻辑组件里面,只保留表现;
    3.后续的开发,各应用都在自己的UI组件上进行
    4.该UI组件其实已经不能称为组件了,各应用可以考虑合并到应用端代码里
这种情况需要注意的问题有几个:
    1.需要规划好该框架以及实现;
    2.框架实现后,要对现有的UI进行重构,这是个比较大的工程;
    3.后续的开发任务的分配,采用这种模式的情况下,大部分逻辑都已经在组件实现,以现有的人员分配无法匹配应用的开发节奏,这里需要考虑是否将该组件交与应用来管理;
    4.需要组件和应用的开发人员都遵循这套模式来进行开发