前前言

好久没写Blog了,我把Blog从Ghost又转回了Wordpress,然后发现弄主题什么的,要把评论弄回来,真是太麻烦了,好吧,一切重来,文章算是弄回来了,但是样式我也懒得改了。

我在这家公司,一直做IM,架构改造了很多版
比如,Dagger从入门到放弃、MVP从入门到放弃、Clean Architecture从入门到放弃,这些所谓的架构我都经历过了,最终留下的,最终觉得,任何架构的切入点,都是以当前人员与需求发展为导向变更的。

哦,上面只是个人的体验,但我觉得,大家有空搞一搞dagger,clean Architecture,mvp都是挺好的,我就觉得我现在的代码视野比以前大了很多。

前言

前段时间做了一次转发优化,觉得这个案例很有代表性,所以决定在这里记录下来。当然,主要的讨论还是和同事一起讨论最终确定下来的。

需求

原始需求

目前所做的IM架构一个会话页面,一个联系人页面,联系人界面是树形架构。接下来的讲解都基于这样类型来说我们的改造

在会话列表,以及联系人界面都有头部的综合搜索,这样,原始的综合搜索流程调整就如下所示

需求叠加

上面的原始需求,搜索只是打开而已,而且,组织架构树的页面,也没有抽象,接下来,需要叠加需求,这时候,你就会发现,代码写的很处理,首选的需求是,讨论组成员添加。那么,在原来打开的基础上,变成如下逻辑。

嗯,你看到的是指增加了三条操作线路,这些线路都是返回结果到之前的界面,但是导致了联系人界面被引用之后,需要判断要打开的的操作类型,并且更可怕的是,这个业务操作被带到了搜索里面,搜索必须知道这个是什么业务,然后相应的,每个界面都要有对应的业务操作,比如,打开会话的代码,比如返回选中人的id。在原来这个业务基础上复用搜索界面,联系人架构师,需要修改有颜色变动的界面的对应代码。

需求膨胀

接下来,还有不同的需求,比如添加消息转发,同样需要引用联系人界面,使用组织架构树,并且能够综合搜索对应的群,讨论组,联系人进行消息发送。然后罗就就变成这样了。
接下来,因为会话中,需要进行消息转发所以,这时候的逻辑进行了如下变动(因为项目赶,同事在写这段代码的时候,就是在原来基础上进行添加)。从会话窗口开始进行界面功能叠加。逻辑变成了如下。
嗯,目前只加了一个界面,但是,联系人打开功能,就需要判断三种业务操作,而且不单直接点击树形的人需要三种业务判断,打开综合搜索,群组列表搜索,讨论组搜索,等,都需要把三个业务操作带过去,消息还有数据的情况下,还要判断数据。

需求变态

因为我们还整合了其他自由非IM业务,需要使用这个联系人模块,以及搜索模块,如果在这么添加下去,你肯定可以想象,添加一个功能,联系人界面,对应的搜索界面需要添加这个业务的接收代码,点击之后的处理代码。想一下,肯定很繁琐把。尼玛写到这里,我都不想改这个界面了。一个转发消息,所有界面都要测一遍,毕竟,你传数据过去啊,每个搜索界面的对应处理位置都要处理啊。

改造

改造要点其实有两个,一个是组织架构树的通用性,一个是搜索的通用性。

组织架构改造

首选,先把组织架构树改造了一把,让其支持单选回调,和多选回调模式,多选回调支持设置已选择用户id,用来实现通用。

这时候,组织架构树上面对应的用户点击,就是回调到主界面进行业务操作了。
由主界面打开会话界面

搜索改造

搜索逻辑,也是返回type,id的形式,让搜索界面与具体业务无关,让具体业务回到最先的功能功能进行业务操作

嗯,这是不是感觉和第一次实现的有点但也有点不异样?因为搜索的结果,都关掉当前页面,从原路径返回,回到最原先打开的界面进行对应的业务操作,比如现在的打开会话。
搜索到人之后打开单聊会话,搜索到群组之后,打开群组会话,嗯,我不是在搜索结果也直接打开的会话。这是重点。

引入讨论组变更

现在我想邀请一个同事进入讨论组,我的改造代码就远远变小了,我只要增加一个activity界面,去承载联系人,然后会有回调告诉我选了什么人,点击确定的时候,把这些人调用接口添加到讨论组就可以了。于是,产生了如下变动。

嗯,没错,我的搜索没有动,联系人界面可能说是适配了多选模式,人员新增不需要修改搜索有关的任何界面,这改动,是不是比原来的代码改动要少了,

引入转发消息

引入转发消息,与引入讨论组一样,新增一个界面,引入联系人,并服用里面的搜索,处理返回的typd,id,就可以进行业务处理了。所有的转发业务,转发数据的承载,都在这个页面进行。然后架构变成了如下:

尾声

按照目前的逻辑,其实已经比较完美的解决搜索路径代码膨胀,修改过多的问题,每次新增业务需要进行选人的时候,复用联系人界面,处理好回调几个进行业务操作,不需要将过多的业务操作数据,代码传入后面的路径的页面上。

但在组织架构树上,人员选择还有很多优化的地方,比如,屏蔽某些人,或者只展示某些人,可以把部分ID数组传输到后面,让其做着部分的适配,依然不需要处理业务。做通用适配就好了。

在通用选择上,也还有一个更优点,只要选人,或者讨论组,那么可以把选择界面封装好,用透明界面来承载。可以变成如下逻辑流程

嗯,只要涉及到选择人,选择对应会话的情况下,就可以添加一个透明的界面,专门处理业务逻辑,启动之后,马上启动选人的界面。当返回时,就回到透明界面进行业务处理。代码量更少。

结语

嗯,很久没写blog了,感觉组织语言都有点奇怪了,得慢慢抓起来。