2. Server
  3. t_user表中的_name 字段是否影响APP端获取用户信息逻辑

t_user表中的_name 字段是否影响APP端获取用户信息逻辑

fqybzhangji 2022-11-4 288

前提情况：

  • 《用户2》和《用户3》是《用户1》的好友
  • 《用户2》的 name 是空的
  • 《用户3》的 name 是有值的

现象：

每次第一次加载《用户1》通讯录效果如下

当点击其中任意一个昵称异常显示的用户，进入个人信息页面后 在返回到通讯录页面，这个异常显示的用户，昵称又显示正常了

查看代码发现更多的疑问

APP端发送getUserInfos 的uid 是四个，服务端收到的是三个 APP端断点调试

服务端接收请求日志

其中 w3gqmws2k 的用户，服务端是返回很健全的数据，但是APP端接收的只有一个uid 客户端接收到的 服务端返回的

最新回复 (6)
  • HeavyRain 2022-11-4
    引用 2楼
    name应该是可见的登录账号用的，对应微信，userId对应微信中一个不可见的id，name对应于微信账号。在应用中可以看到微信号，可以根据微信号搜索用户，也可以修改微信号，只要保证当时唯一就行。但name的唯一用途就在这里，其他都没有影响。

    看到图上getUserInfos函数，这个函数的实际上是这样执行的，这个函数是同步返回，返回存在本地的用户信息，然后不存在的再异步去IM服务更新。所以这个函数很可能返回的用户数量不全，而当去异步去IM服务更新时也会做排重（就是已经调用过获取用户信息的就不再调用了）。当异步获取成功后会发送通知，这个时候要监听到通知再次刷新。请参考demo中的实现
  • fqybzhangji 2022-11-4
    引用 3楼

    异步通知数据也不对

    APP接收到的数据

    服务端发送的数据

  • HeavyRain 2022-11-4
    引用 4楼
    第一种图里返回的数据是同步返回的，在android平台如果不存在就会返回来一个空的对象来。在用到用户信息的地方需要监听用户信息更新的通知，当收到通知后再次刷新页面
  • fqybzhangji 2022-11-4
    引用 5楼
    HeavyRain 第一种图里返回的数据是同步返回的，在android平台如果不存在就会返回来一个空的对象来。在用到用户信息的地方需要监听用户信息更新的通知，当收到通知后再次刷新页面
    第一张图是监听里面收到的，不是getUserInfos直接返回的
  • fqybzhangji 2022-11-4
    引用 6楼

    第一张图是监听返回的

  • HeavyRain 2022-11-4
    引用 7楼
    查出来了，name还有个作用是检验用户信息的有效性，如果没有name字段就会认为不合法，所以必须加上name字段，如果你们系统中没有对应信息，可以把用户id放进去
返回