VPS租用 > 教程 > 网站运营 > 正文
vps广告

【android客户端架构图】-微信Android客户端架构演进之路

五彩互联编辑部发布时间:2017-04-17 02:22:27浏览:0
摘要:拓荒微信1.0 for Android的测试版本于2011年1月发布。这是微信Android客户端的第一个版本,软件架构采用早期标准的Android系统应用设计。【图1】第一个版本是两个人用了一个

拓荒微信1.0 for Android的测试版本于2011年1月发布。这是微信Android客户端的第一个版本,软件架构采用早期标准的Android系统应用设计。

微信Android客户端架构演进之路

【图1】

第一个版本是两个人用了一个多月的时间开发出来的,其中一个还是刚刚毕业没多久的实习生。这个时期团队一穷二白,资源有限、经验不够,主导思想是,复杂的事情尽量交出去做,保持最精简的客户端代码。得益于Android应用开发简单快速,从结构上看,这个时候其实还没有到需要特别设计的阶段,是最原始、简单的Android应用。

当然,再简单的软件也要考虑基本的设计思路。分层设计思想从这最早的版本开始引入一直到今天。回顾当时的设计,更像是MVP结合事件通知机制。从最上面由Activity组件组成的UI层(VIEW),往下到由NetScene组成的表现层(Presenter),再往下Network负责网络长短连接与数据库的通信与Storage组成的存储层。NetScene是一个网络或者本地任务的基本单元,包括操作网络做数据收发、协议编解码,操作数据库做各种联系人、消息模块的读写。典型的例子如发送一条消息NetSceneSendMsg、做一次收信同步操作NetSceneSync。1.0版本的微信整个UI的activity可能不超过五个。

这个阶段,不需要做什么减法,我们的安装包也只有354k。

成长微信的快速增长,从2.0版本开始第一次爆发。从语音版,到附近的人、漂流瓶,再到摇一摇。这个阶段的我们,似乎将全部的时间和精力都放在新功能拓展上。新的Activity、新的NetScene加上新的Storage,在看似成熟的框架里,一个功能就这样完成了。简单、快速、暴力。随之而来的,是一些之前完全没有想到会可能出现的问题,让最开始接触Android开发的我们措手不及。

早期版本因为经验的问题,产品上很多功能不去想也不敢去想,版本开发的时间跨度也比较长。随着开发经验的积累和对产品方向的理解,3.0之后的每一个小版本都处在一到两周的高速迭代过程中。

追求更好的用户体验,更多丰富的功能是产品经理们永远不会放弃的事情,尤其是在新功能为微信的新增用户带来了一次次爆发式的增长之后,更是无法控制。功能的试错频率大大加速,机型覆盖量上升后的兼容性问题也逐渐暴露。代码量、内存占用、安装包体积迅速膨胀。而同样处于发展中的Android系统,也给我们埋下了很多坑,需要开发自己来实现、修复和优化。放在今天webview组件不再是什么问题,但在2.3之前的系统里面都会存在严重的内存泄露。内存问题为微信客户端架构的第一次进化埋下了伏笔。

变革在微信1.0时代的时候,我们的关注点更偏向功能,随着用户增长,性能和稳定性问题逐渐浮上水面。2.0版本后,用户反馈中微信消息推送不及时的比例在上升,作为一款目标替代短信的即时通讯应用,无法及时收取别人发来的消息,这一点是非常致命的。

Android 1.5、1.6、2.1在当时是主要的版本,那个时候是没有今天的GCM的,甚至连C2DM也是2.2系统之后才会有的。而谷歌服务在国内被屏蔽,在相当长一段时间内,无论是C2DM还是GCM都无法正常进行推送。没有像APNS一样稳定的推送通道可供Android平台的应用使用,怎么办?自己实现。

国内网络的特殊性,使得我们再实现微信推送机制时,需要维持准确的心跳周期。如果一段时间没有活动,运营商便会将长连接断开以回收资源,这时服务器发消息给客户端就接收不到了。进一步研究发现,运营商网络的时间限制各个地区不同,有的地区有两分钟,有的地区有半个小时,这种情况是不可接受的。我们的解决方案是缩短心跳间隔,在网络运营商把客户端到接入点之间的连接断开之前,我再发送一次心跳,主动维持住这个长连接的活性。这个我们称之为长连接的保活。关于长连接的保活策略,微信也做过多次优化,这里另文介绍,不再赘述。

还记得前面说微信的膨胀吗?代码、内存、apk大小都在膨胀,这其中,内存对消息收发的影响很关键。Android运行时的择优置换机制,会选取占用资源最多的程序结束掉,除了微信自己功能膨胀导致内存占用加大之外,前面说的不省心的webview,还会给我们在内存问题上挖坑。而结果就是在用户手机运行APP比较多的时候,微信会被系统杀掉回收资源,消息收取不及时的问题就出来了。

联系我们