以手机QQ为例探讨移动端IM中的“轻应用”

原作者：周蔚(arthaszhou)， 腾讯专家工程师，产品部平台开发组组长。

1、导语

2015年，借着公众号“动态消息”的东风我们把沉寂多年的应用开发框架Ark（开发代号）移植到了全平台QQ中。基于新框架带来的能力，我们可以将服务以页卡的形式嵌入到消息流中，使用户在多个平台下获得一致的产品体验。QQ中因此诞生了新形态的“轻应用”。此后我们持续在完善Ark框架的应用开发能力。期望基于QQ构建一个开放的场景化“轻应用”平台，并探索未来新的互联网服务形式。

2、“轻应用”展示

“轻应用”暂没有正式的名称。团队内部基于习惯把这种内嵌在QQ中的应用称为“轻应用”，蕴含应用轻小，使用轻便之意。有时候我们也把“轻应用”称为“轻App”或“Ark应用”。和QQ中承载的大量全屏体验的Web应用不同，“轻应用”更多是以碎片化的方式内嵌在QQ中。

支撑“轻应用”的Ark（开发代号）是我们自研的框架。基于使用脚本语言开发带来的优势，“轻应用”可以像Web应用一样动态更新，无需随QQ版本发布。且具备多平台（iOS、Android、Windows）体验一致性，一次开发，多平台运行（Write Once, Run Anywhere）。

3、“轻应用”的技术特点

1动态更新

动态更新是“轻应用”最基本的技术能力。“轻应用”既可基于app包的形式整体更新，也可基于视图局部更新。虽然以Web技术为代表的方案也可以使应用获得动态运营能力，但主要应用在全屏场景下，而“轻应用”将这一能力拓展到了消息流等新的嵌入式场景。


▲ QQ运动基于“轻应用”提供的动态运营能力无需发布新版本QQ即可切换模版风格

2轻量

对比其他技术方案（Web、React Native等），“轻应用”在加载速度和内存占用方面有明显优势。所以“轻应用”可以在不影响基础体验的情况下内嵌在消息流中使用，同时打开数十个甚至上百个视图实例。


▲ QQ运动打开前后内存变化（iPhone 4）

为了达成上述轻量化的目标，我们在技术方案选型和实现上都向“轻”的方向有所倾斜。首先我们选择了Lua作为第一个支持的开发语言。Lua的 VM非常小，充分保证了初始化时间和内存开销的可控。而其基于寄存器的VM实现也使得脚本程序在性能方面表现优异。另外在UI部分，Ark中没有提供控件库，只是提供构建UI的原子能力。开发者可以在上层通过模板装配出可复用的UI（控件）。这使Ark核心的UI部分非常简约。而在工程实现部分，我们在开发Ark时尽可能的复用了各个操作系统提供的差异化的源生能力。虽然这导致了框架的工程实现部分会更繁琐（如增加一些中间层的设计，同样的基础模块实现多份等），但在体积控制上具备明显的优势。

3可交互

消息流中的图文消息主要用于呈现静态的文字和图片内容。集成Ark后，消息内容具备了更丰富的互动能力。从而使消息流从服务入口的容器升级为了服务本身的容器，嵌入在消息里中的服务可以更短路径被用户使用。


▲ 基于“轻应用”实现的时钟/计算器/小游戏，可直接在消息流中完成交互

为了实现上述能力升级，Ark提供了丰富的基础能力API供开发者使用。同时也将部分QQ的平台能力进行了封装，使“轻应用”可以更好的融入QQ中。



随着应用开发能力的逐步完善，部分团队已经开始尝试基于Ark开发更复杂的全屏“轻应用”。


▲ 全屏方式打开的腾讯地图“轻应用”

4、“轻应用”升级场景化应用

移动互联网时代，手机携带的便利性促使了场景化应用的出现和普及。无处不在的二维码以及诸多基于微信公众号的服务都很好的诠释了场景化应用的价值。基于二维码打开的Web应用（小程序）用户在吃饭、唱KTV、看电影等诸多场景中都能非常方便的用上相关的互联网服务。场景化应用的普及进一步促进了互联网融入用户的现实生活，极大提升了用户获取使用服务的效率。基于场景化应用的价值和潜力，我们期望能基于“轻应用”构建场景化应用的平台来充分发挥它的价值。但需要注意到，QQ中并不存在如微信公众号一样强大的开放生态，同时用户看到二维码也不会条件反射般的选择QQ扫码。所以关于QQ中如何建设场景化应用平台需要我们选择和微信不同的切入点和发展思路。

我们当前选择的产品方向是根据用户行为（狭义来说就是对话语义）和用户属性识别场景，匹配场景化的服务嵌入消息流使用。作出这种选择主要基于两方面因素：首先是对用户的价值。消息流是人与人沟通的核心载体。如果服务能自然的融合到消息流中，所有以沟通为起点的服务都能最短路径获取和使用。其次是技术实现上的考虑。消息流中的对话内容很多时候也正是当前用户所处场景相关的语言表达，有助于平台识别用户所处场景。



QQ中现有的场景化应用主要通过两种被动方式触发：

• 识别用户输入内容触发应用入口，点击后在键盘区展示；
• 识别聊天内容在消息流中插入应用入口，点击后在消息流中展示。
  

▲ 地图


▲ 音乐、自选股、动漫、天气

基于被动方式场景作为切入点有两个原因：一是客观上现有的语义分析技术能力不足（出于对用户隐私的尊重无法使用更成熟的服务器方案，手机设备的资源有限使技术选择有较大局限性），被动方式触发对召回率的要求没有主动搜索那么高。二是主观上策略选择，基于消息流内容的被动触发可以为服务提供方带来增量的流量。为了获得被动触发的机会，需要“轻应用”主动的标注所具备的能力。而主动标注再结合模式识别、自然语言理解等技术手段，用户行为、用户画像、服务三者均转化为可计算的数据。基于计算使用户行为动态关联到个性化的服务，这正是我们建设场景化“轻应用”平台的基础。

注：导流量是把双刃剑，过度的导流必然会伤害用户体验。所以这需要平台团队有更强的克制力。被动场景的“轻应用”接入需要尽量规避带有推荐广告性质的服务，更多局限在和场景有直接关联偏工具属性的服务上。

除了用户行为被动触发“轻应用”所需的应用能力标注以外，我们也期望所有“轻应用”的输出都能是统一的标准化语义化的元数据。结合知识图谱，所有的“轻应用”能聚合成一个有机的整体，使用户从任意场景切入使用“轻应用”，都能伴随着使用“轻应用”的行为自然的切换到下一个场景继续使用其他“轻应用”。




场景化应用并不局限于单个用户到服务的单向连接，基于IM平台自身的分享能力，可以实现多人和服务的连接关系。群投票、聚餐时点菜、AA买单、KTV点歌等等都是生活中经常发生的多人共同使用服务场景。而基于消息流内嵌“轻应用”来实现，沟通、服务交互、信息反馈都直接在消息流中完成，使用服务的整体体验更流畅更直观。


▲ 基于“轻应用”实现的游戏组队，消息流中可实时更新组队状态和组队人数

5、“轻应用”的未来

数年前，使用互联网还是局限在特定地点（家、公司、网吧）使用特定设备（PC）上网。在移动互联网时代智能手机的普及打破了时空的桎梏，使人们可以随时随地的使用互联网，淡化了“上网”概念。未来随着物联网等基础设施的完善，穿戴式设备（AR眼镜）、汽车、家用电器（电视、冰箱）、家居设备等都会成为接入互联网的节点。现实世界和虚拟网络世界之间的边界会逐渐模糊。而场景化应用正是促进现实生活和互联网服务融合的重要桥梁。

基于以上判断，“轻应用”未来发展的大方向也可以基本确定。首先在表现层面，我们期望基于“轻应用”能构建标准化的容器，可在手机之外的其他设备中展示，帮助服务以碎片化的方式更方便的嵌入到各种场景中使用。其次是数据层面，我们期望能把“轻应用”标准化语义化的元数据标注拓展到设备层面，使设备能力融合到“轻应用”的服务网络中，构成完整的服务闭环提供给用户使用。



除此之外，和AI技术的结合同样也是“轻应用”未来需要努力的方向。AI可以充当现实世界和互联网服务之间的翻译，提升用户使用服务的效率。同时AI也可以承担数据过滤器的角色，解决信息过载问题。对场景化“轻应用”平台来说，AI技术的价值具体可以体现在以下几个方面：

• 挖掘更多数据生成精确的场景描述，给用户更个性化的服务界面；
• 改善人机交互方式，使用户可以更高效的使用服务；
• 辅助用户在使用服务时更高效的做决策。
  

“连接一切”是腾讯公司未来发展的大战略。“轻应用”的发展方向和这个大战略也是一致的。我们期望 “轻应用”在未来能更好的扮演连接器的角色，连接用户和服务。能让用户拥有更加便捷高效的生活。

更多有关微信、QQ的文章

[1] 有关QQ、微信的技术文章：
《以手机QQ为例探讨移动端IM中的“轻应用”》
《一篇文章get微信开源移动端数据库组件WCDB的一切！》
《微信客户端团队负责人技术访谈：如何着手客户端性能监控和优化》
《微信后台基于时间序的海量数据冷热分级架构设计实践》
《微信团队原创分享：Android版微信的臃肿之困与模块化实践之路》
《微信后台团队：微信后台异步消息队列的优化升级实践分享》
《微信团队原创分享：微信客户端SQLite数据库损坏修复实践》
《腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（下篇）》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
《微信Mars：微信内部正在使用的网络层封装库，即将开源》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《开源libco库：单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》
《微信团队原创分享：Android版微信从300KB到30MB的技术演进》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
《微信异步化改造实践：8亿月活、单机千万连接背后的后台解决方案》
《微信朋友圈海量技术之道PPT [附件下载]》
《微信对网络影响的技术试验及分析（论文全文）》
《一份微信后台技术架构的总结性笔记》
《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《快速裂变：见证微信强大后台架构从0到1的演进历程（二）》
《微信团队原创分享：Android内存泄漏监控和优化技巧总结》
《全面总结iOS版微信升级iOS9遇到的各种“坑”》
《微信团队原创资源混淆工具：让你的APK立减1M》
《微信团队原创Android资源混淆工具：AndResGuard [有源码]》
《Android版微信安装包“减肥”实战记录》
《iOS版微信安装包“减肥”实战记录》
《移动端IM实践：iOS版微信界面卡顿监测方案》
《微信“红包照片”背后的技术难题》
《移动端IM实践：iOS版微信小视频功能技术方案实录》
《移动端IM实践：Android版微信如何大幅提升交互性能（一）》
《移动端IM实践：Android版微信如何大幅提升交互性能（二）》
《移动端IM实践：实现Android版微信的智能心跳机制》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《移动端IM实践：iOS版微信的多设备字体适配方案探讨》
《信鸽团队原创：一起走过 iOS10 上消息推送(APNS)的坑》
《腾讯信鸽技术分享：百亿级实时消息推送的实战经验》
>> 更多同类文章 ……

[2] 有关QQ、微信的技术故事：
《技术往事：创业初期的腾讯——16年前的冬天，谁动了马化腾的代码》
《技术往事：史上最全QQ图标变迁过程，追寻IM巨人的演进历史》
《技术往事：“QQ群”和“微信红包”是怎么来的？》
《开发往事：深度讲述2010到2015，微信一路风雨的背后》
《开发往事：微信千年不变的那张闪屏图片的由来》
《开发往事：记录微信3.0版背后的故事（距微信1.0发布9个月时）》
《一个微信实习生自述：我眼中的微信开发团队》
《首次揭秘：QQ实时视频聊天背后的神秘组织》
>> 更多同类文章 ……

没想到手机QQ里的这些东西是这么玩的。。。