关于微信等业务识别的情况浅析

    首先根据 辉子 提供的关于微信收发消息的机制（感谢辉子），原文参见：http://www.infoq.com/cn/articles/the-road-of-the-growth-weixin-background

    可以看出微信接收消息，是先接收到微信的消息通知，然后主动的获取消息。根据这个实现机制，客户端和服务器应该存在一个长连接，保持着客户端和服务器的消息通知通道（不考虑第三方推送的情况，安卓是否采用第三方推送不确定，微信自身不使用第三方推送的概率较大），以便服务器能够及时通知客户端要做什么事，这样就会存在保活消息，要不这个消息通知的长连接在一定时间内就会老化消失，服务器就无法推送通知消息到app客户端了。

    根据上面分析，微信只要驻留后台（没有使用任何微信业务），就应该有保活消息的流量存在，就不会出现业务无流量的情况，而实际我们测试的情况发现，微信业务驻留后台，出现长时间没有任何流量（至少15分钟），出现这种情况的主要原因应该是业务识别引擎没有识别出微信保活的消息（这个业务识别引擎暂时无法保证能够识别出保活信息的特征，只能保证识别出登录和收发信息等业务特征）；

    通过上面的分析，微信、qq等这些业务流量轨迹已经清晰，只要业务识别引擎能够识别出保活消息，这个问题就能解决，但是就目前业务识别引擎对于保活消息识别，是暂不能完全保证能识别的，因此依靠检测保活消息流量判断业务轨迹存在不是合理方案，这也是我们前期没有仔细分析业务识别引擎机制造成的。

    下面讨论下针对无长连接保活机制（单纯的C/S模式）的业务轨迹展现，目前我们测试的情况是出现大量的在同一分钟内上下线的业务轨迹情况（如下图所示），导致这个现象的原因是：很多业务客户端收发一些消息后，就不再有业务交互，如果在一段时间后再次有业务消息交互（15分钟以后），就会再次出现这个应用业务上下线的情况。这些现象的呈现，理论上没有任何问题，实现上也没有任何错误，在用户体验上是否更合理，需要我们再斟酌一下。

    综上所述，我们这个业务轨迹的呈现机制需更新方案，提供更好的用户体验。