2025/11/13 -- 组队系统

        组队系统的结构和好友系统的结构非常相似，唯一不同的是，好友系统的后处理是用一个bool值来判断是否进行的。好友信息的更新是独享的，每个玩家都有一个独立的好友信息面板。而组队系统里面的队伍是共享的，所以后处理这块会有一些不同。这里的组队系统没有采用持久化存储，也就是说一断线，就相当于退出了。
1. 协议层：
发送邀请，接收邀请，队伍列表，离开队伍

        邀请相较于好友，多了一个队伍id，邀请响应里面和好友相同，都是给请求封装进去，简化逻辑。这里的获取退伍列表目前也是通过后处理机制来实现的，尽可能减少发包量。离开和好友差不多。

2. 服务端：
因为这里的团队是暂存的，所以没用到DB，增加了一个Model层，Team:

Model里面存储了队长的信息，成员信息，以及该队伍上次修改信息的时间戳，该时间戳后面后处理时会用到。
构造时调用添加成员方法，添加成员时判断一下是否为第一个成员。是就设置为队长。
  

        离开队伍时，判断离开的是否为队长，默认队长离开就是解散队伍

后处理，给teamInfo添加到响应协议里面，给队伍成员同步到客户端。

        在角色里面定义一个Team字段，以及更新时间戳


总的后处理入口中添加组队系统的后处理，如果角色目前的队伍信息的更新时间戳要小于Team的更新时间戳，就代表不是最新的信息，触发组队系统的后处理，因为这里是在Character里面添加的字段，所以每个队伍成员都会有该字段，这样就可以保证一个人加入队伍的时候，其他的队伍成员都会通过后处理更新一遍。

TeamService:
订阅请求

初始化的时候，给队伍管理器初始化一下。


离开队伍的时候，调用Manager里面的方法处理离开的逻辑。

服务端的发送邀请以及响应邀请都和好友系统里面的差不多，这里就不多描述了。

        TeamManager:队伍管理器里面主要维护的是所有的队伍信息。List用于遍历，字典用于查询。

        添加成员时，如果队长的队伍为空会先调用创建队伍接口，如果有空闲的队伍直接拿过去用，否则创建一个新队伍，之后调用Model的添加成员。



离开队伍时，如果是队长的话，需要将队伍里面的所有成员都清空。

客户端：
UITeam:

这里ListView的元素是固定5个的，所以在start的时候，给其添加上去。如果User里面的队伍信息没有就直接返回，并且隐藏。
因为UITeam是直接挂载UIMain上面的，所以每次激活的时候，调用一下刷新，这里还提供了一个show的接口，给UIMain调用。


这里的ListView的刷新逻辑和以往的有区别，以往都是直接实例化出来的，这里是控制显隐的个数，显示出来的给其设置值。

离开队伍：

UITeamItem:


这个Itemrender也是和以往的都差不多，设置一下数据

TeamService:
订阅方法：

客户端这里的邀请组队与好友的添加非常相似。

        接收服务端的队伍信息后就通过Manager刷新UITeam


客户端的发送退出队伍、接收退出。接收到退出之后刷新UI。

        客户端的队伍管理器，主要用来接受服务器数据后更新数据以及刷新UI.