IM客户端设计常见问题

Search…
IM客户端设计常见问题
不知不觉做了六年的程序员，主做前端也已经三年时间，在这六年的时间里做了不少项目。虽然对基础层面、算法、JS运行原理去深究一些底层的运行机制还是一知半解。但这三年的项目中遇到的问题及做的优化点也有很多，深入JS底层的问题、深入逻辑底层的算法也遇到不少，但总是缺乏系统的梳理。在这里，率先对两年前我所做一个IM项目所遇到的问题作出整，方便知识后序查阅。
项目背景：工程师端是为实现线上客服在线通过IM的形式，发送/接受：文本、图片、标签、语音 及 在线视频直播。 等方式解决各个通路（公众号、APP）接入用户的问题。项目以 Electron 作为壳子，使用 vue 实现窗口界面。整个界面风格非常像Mac版QQ
Could not load image
image
IM消息发送顺序问题
不知道大家有没有观察过桌面版QQ发送框的输入逻辑，我们在输入框中同时输入的内容类型可以是：文字、表情、图片、链接... 其中，文字、表情和链接可以被单独发送出去，图片需要做拆分，比如我输入下列内容
1
今天天气真好[图片] 太阳火热 [图片] [图片]
Copied!
点击发送按钮，该内容会被拆分为:
1
[
2
    { type: 'text', content: '今天天气真好' },
3
    { type: 'image', url: [file] }, 
4
    { type: 'text', content: '太阳火热' },
5
    { type: 'image', url: [file] }, 
6
    { type: 'image', url: [file] }, 
7
]
Copied!
在发送的时候，我们需要调用多次发布接口，发布文字消息、图片、文字、图片、图片。由于是多消息发送，保证消息的发布顺序直观重要。关于这种情况，我们参考了一个 经典的 Promise 红绿灯问题：
解决方案：https://www.w3ctech.com/topic/916​
多消息通路整合
我们当时遇到的业务问题在于复杂的后端服务设计，整个应用由于用户接入的通路不同，导致需要对接多套IM 消息机制，接入 APP端用户IM 使用 长轮询链接，接入 微信端用户IM使用Websocket。两套机制在客户端的业务业务场景基本一致，但是所调用的系统和服务各不相同。所以我们在action 层做了分离，action的实例使用适配器模式进行初始化，action 的适配方法通过参数判断该用户是由 APP通路接入 还是 微信通路。调用不同的 action 实现
1
class ActionBase {
2
  getUserInfo() {}
3
}
4
​
5
class ActionAdapter extends ActionBase {
6
  constructor () {
7
    super()
8
​
9
    this.apiWX = new WXApi()
10
    this.apiApp = new AppApi()
11
  }
12
​
13
  getUserInfo(userId, phone, from) {
14
    if (from === 'wx')
15
      return this.apiWX.getUserInfo(userId, phone)
16
​
17
    this.apiApp.getUserInfo(userId)
18
  }
19
}
20
​
21
class WXApi extends ActionBase {
22
  getUserInfo(userId, phone) {
23
    console.log('Get user info from wx')
24
  }
25
}
26
​
27
class AppApi extends ActionBase {
28
  getUserInfo(userId) {
29
    console.log('Get user info from APP')
30
  }
31
}
32
​
33
const adapter = new ActionAdapter()
34
adapter.getUserInfo('1', '18668888888', 'wx')
Copied!
MVC 和 MVVM 设计模式的精髓就在于View 层与 Model 层的解耦，通过View组件调用适配器，我们可以实现在最小化View层修改的前提下，适配新的业务体系。
输入框的复制与覆盖
Electron 的跨进程通讯
Electron 有两个进程 Main 及 Renderer，两个进程通过IPC进行实时通讯。在业务触发一个较底层的功能时，我们通过 渲染进行调用 ipcMain，与主进程进行通讯，在 MainProcess主进程 中对对应的系统级 Electron 的API进行调用。
同时，在一些底层事件中，比如 关闭程序、触发快捷键、点击菜单栏等，主进程会率先收到消息，通过 ipcRenderer 调用渲染进程，通知页面对事件作出响应。
保证消息必达
监听错误并提示感叹号
刷新聊天记录
Websocket链接监听
客户端心跳保活
服务器轮询监测网络抖动
Electron 的多窗口管理
维护窗口
复杂跨多系统长链路调用，前端如何独善其身
随着项目业务的逐渐增多，我们调用后台的系统服务也变得越来越多，一度达到十几套系统的复杂程度。单一一个请求的前端业务动作，比如登陆，就要调用三套系统的五个接口实现。有些业务接口的饿调用顺序还是强依赖的，比如你必须先拿到 SessionId 才能请求登陆用户基本信息。后端系统相当复杂，并且从系统稳定性的角度看，几乎不能做大的调整。那么我们只有从前端的角度入手解决问题，开始的时候我们使用Promise 的回调链去处理这种长链路请求情况。比如登陆操作：
1
login(username, password) {
2
    const data = {}
3
    apiWX.auth({ username, password }).then(res => {
4
        return apiWX.getUserInfo({ res.userId })
5
    }).then(res => {
6
        return apiApp.auth({ username, password })
7
    }).then(res => {
8
        return apiApp.getUserInfo({ userId: res.userId })
9
    }).then(res => {
10
        return apiWX.getWorkState({ userId: res.userId })
11
    }).then(res => {
12
        return apiWX.startSocketListener({ userId: res.userId })
13
    }).then(res => {
14
        return apiApp.startSocketListener({ userId: res.userId })
15
    })
16
}
Copied!
有一些很明显的一个问题：
1.一些系统之间可能前后并没有依赖关系，如果单纯是顺序调用的话，加载时间会非常长
1
对不同的调用链路进行拆分，不把没有依赖关系的promise放到一条链路当中
Copied!
1.单一接口调用出错会导致余下接口都调用不成功，那怕是不那么重要的服务。针对上述问题我们做了两点优化
1
/**
2
 * finally方法用于指定不管Promise对象最后状态如何，都会执行的操作。
3
 * 它与done方法的最大区别，它接受一个普通的回调函数作为参数，该函数不管怎样都必须执行。
4
 * @param callback
5
 * @returns {Promise.<Promise.<*>>}
6
 */
7
Promise.prototype.finally = function (callback) {
8
    const P = this.constructor
9
    return this.then(
10
        value => P.resolve(callback()).then(() => value),
11
        reason => P.resolve(callback()).then(() => {
12
            throw reason
13
        })
14
    )
15
}
Copied!
1.Promise对象的回调链，不管以then方法或catch方法结尾，要是最后一个方法抛出错误，都有可能无法捕捉到（因为Promise内部的错误不会冒泡到全局）
1
Promise.prototype.done = function (onFulfilled, onRejected) {
2
    this.then(onFulfilled, onRejected)
3
        .catch((reason) => {
4
            setTimeout(() => {
5
                throw reason
6
            }, 0)
7
        })
8
}
Copied!
对抗复杂链路调用的堡垒：中台构建
我们可以看到，大型企业内部管理系统的复杂程度令人咋舌，而我们期待服务端去做出一些改变，基于其系统的历史情况，尤其很多系统属于跨部门协同，是不现实的。而每一个系统基于其自身的定位，只是在几个业务线之间，而我们的应用有需要跨越多个系统进行调用，取数据、实现业务能力。所以最好的方案是我们在中间搭建一层中台，一方面针对后端，通过内网对单一业务动作集成不同的系统，这样对于一些跨系统的请求更快。前端只需要跟中台通讯，保证客户端调用的单一性，适度的与复杂调用链路解偶，降低客户端内部的复杂度。另外，中台实现了一种新的业务能力，这种能力可以被其他的前端应用调用，实现业务的快速拓展。
Vue 编码规范
2013年的一段演讲：思考React最佳实践
Last modified 1yr ago
Copy link
Contents