创意点的产品功能/使用场景介绍
场景1

在火车上、长途汽车上,没有免费的上网环境,移动2G3G信号又常常很弱很不稳定,临时想和身边的同学互相分享个电影看看,传点音乐听听。开3G传吧,感觉流量耗不起,一个月也才几百MB。狠狠心,反正流量也是拿来用的,开着传,传了一阵火车进山洞了。。。

场景2

公司同事一起去旅游,大家一起到了风景如画的地方,各自都拿出手机一阵狂按,互拍,几分钟下来少说有几十张照片,想发个空间朋友圈什么的,太多了。。。每张照片都有23MB,这又是一大流量杀手,网络不好发起来还贼慢。只能提醒:拍我的照片回去了发我,然后,往往就没有然后了。。。

近场0流量传文件功能介绍:

碰到类似上面两种类似的情况,大部分用户就歇菜了,要不因为心疼流量,要不因为信号实在太差,完全不具备可行性。

如果这个时候,有这么一种神奇的技术,能够让你和身边的人肆无忌惮地传送任意多、任意大小的文件也不耗费一丁点的移动网络流量,是不是狂拽酷炫屌炸天了呢?是的,这就是我们的“QQ文件近传”!

功能介绍:

0流量:

使用QQ文件近传向好友发送文件,接收好友发来的文件,均不耗费移动运营商的网络流量,两台设备间通过QQ文件近传通道可以0流量传送任意大小、数量的文件,节省流量。

高速传输:

使用QQ文件近传在好友之间发送文件,最快速度可达到5M/S(与手机性能或所接入的无线路由性能有关),相比普通传文件而言,更节省时间。

具体使用方法:

  1. 若文件收发双方已经处于同一个网络中(例如:连接到同一个路由中)

Step1.     打开对方的对话窗口,点击底部加号,在第二行按钮中选择文件近传

Step2.     自动进入近场传输能力判断界面

在这个界面中,会根据双方的网络环境判断是否具备近场传输的条件(同一wifi),在这个情况下同一wifi的两台手机会迅速通过条件判断,此界面会一闪而过

Step3.     选择要发送的文件

近场传输能力判断通过后,表示双方具备近场传输条件,可以直接像发送普通文件一样选择文件并发送给对方了

Step4.     等待对方接收

如图所示,发送方界面回到了对话窗口中,已经选择发送的文件生成了消息气泡,并等待对方接收。

同时文件接收方将会收到一条提醒:

对方点击接收即可以近场0流量的方式将文件传输给对方,同时对方接收过程也完全不耗费任何网络流量。

  1. 如果周围没有wifi,想与身边的好友进行文件近传

Step1.     与好友都进入文件近传搜索页

打开QQ,定位到动态标签页,选择文件/照片助手,即可看到文件近传的图标,点击进入搜索身边的好友:

Step2.     让对方也打开文件近传界面,在搜索页找到对方,并点击对方头像

在这个页面中,你将听到背景音乐表示正在搜索附近同时打开文件近传的好友。已经进入这个界面并且符合近传条件的人的头像将会出现在这个界面中。选择要发送文件的人即可。

Step3.     选择要发送的文件,支持批量发送

Step4.     点击发送后,如果是安卓用户,会提示将创建自建热点进行文件传输

点击继续,将自动调用手机系统能力创建自建热点(便携式热点),用户不需要手工做任何设置。

发送方点击继续后,接收方将收到一个近传文件提醒

接收方点接收,则将自动连接发送方所创建的自建热点(双方均是安卓系统)进行传输,不需要用户手动进行设置。

4、创新点的创新之处的具体描述

 创新点1:利用 LBS减少用户操作,隐藏复杂技术概念

竞品的问题:业界同类产品(快牙,茄子快传)通过自建热点来扫描身边的人。用户使用前必须选择“创建连接”或“加入连接”,一方面增多操作步骤,另一方面小白对这类专业名词“连接”“热点”不理解。

我们的方案:文件近传引入LBS技术,当用户打开功能后,将自动上传信息到后台,通过后台的计算,只要符合条件,则能互相发现,在这个过程中,用户无需任何操作就可发现身边的用户。在发送过程中如果需要建立手机热点,也完全自动进行,无需收发双方用户在系统设置中先进行复杂的设置。相比竞品,减少了操作步骤,更重要是把复杂的技术概念隐藏掉,降低使用门槛。

详细技术可查阅第六点中“6.1 相互发现,6.2.1 预传输(特定情况下)”

用户进入文件近传自动扫描附近用户

    

创新点2:利用LBS解决跨子网不能发现用户问题

问题:一些大型场所,如企业,机场,商场的局域网由多个路由器组建而成,如TencetFreeWiFiCMCC,当用户1连接到路由器A,用户2连接到路由器B,此时双方在附近也连到同一WIFI,但由于连接到不同路由器而不能发现对方,这是不符合现实使用需要的。理论上在同一局域网的用户是需要做到互相发现的。此时你可能会问:“为什么不根据WIFI的名称来发现,比如我们都加入到CMCC就显示出来”,这样是不行的,因为用户1可能加入的是深圳的CMCC,而用户2可能加入是北京CMCC,双方虽然在同名称的WIFI,但并不是同一个局域网。

方案:为了解决双方在同一个WIFI名称但处在天南地北的问题(不同MAC地址,WIFI名称相同),我们加入地理位置信息。比如用户1和用户2都加入到TencetFreeWiFi,但两者加入了不同的子网,此时如双方在附近,则认为他们是同一个局域网,而非“天南地北”的情况,从而解决上诉问题。

详细技术可查阅第六点中“6.1.2 局域网跨子网 ”

5、创意如何产生的

哎,一切都从流量说起

话说某天部门去东莞团建,东莞这个人杰地灵有山有水的地方,怎么能不拍照留念。于是,大家纷纷拿出高大上的手机,让同事帮忙拍照。那是,几乎每张图片都34M大小,拍完就随意吼了一句“回去记得发我!”然后,就没有然后了

貌似很多同事都存在类似的经历,无论是大家在户外一起分享照片,在公车上分享音乐,都因为流量问题而“回家发我”。于是我们想到了手机热点技术,为什么不把热点技术融入到QQ传输体系呢?经过半年时间的预研,我们强悍的开发GG终于将热点与WIFI直连技术融会贯通,再经过半年的产品规划与设计,做出了文件近传,满足用户在没有WIFI情况下,也能潇洒大方的传输大电影,大照片,大音乐。


6、怎么实现的

6.1.   相互发现

由于近场环境下会涉及到众多复杂网络,故针对不同网络,实现上需要采取不同的解决方案。

注:下图描述遵循

 

6.1.1.   局域网同子网

预期的表现:

  • 同子网内的多个AndroidCD)、iPhoneAB)手机都可以相互发现

技术点:

  • 局域网内局部(自身IP前后10IP地址范围)单点UDP扫描
  • 局域网内广播扫描

技术实现:

       在局域网内的任何一台设备,一旦设备进入了发现页,即进入近场发现模式,此模式下,设备会向网内的IP地址做局部单点扫描和广播扫描,扫描端口为预定义的固定端口组合,只要设备间能够相互收发UDP网络数据包,即可相互发现。

6.1.2.   局域网跨子网

预期的表现:

  • A、C同子网本身即可相互发现
  • B、D同子网本身亦可相互发现
  • A、C通过服务器S协助后,可与BD相互发现

技术点:

  • GPS、基站、网络更信息综合处理后计算距离
  • 通过服务器协助扫描

技术实现:

       A如果需要和BD实现相互发现的话,因为广播包一般无法跨子网,所以A的广播数据包无法到达BD所在网络,并且由于ABD不在同子网,所以也无法预估BDIP地址,因此在这种环境下,A必须上报自己的进场信息到服务器S,让S来计算ABD之间的距离,并确认他们之间是否属于同WIFI而分属不同子网的情况,如果实际情况确为合同局域网跨子网,则服务器SA请求后会返回BD,从而完成局域网跨子网的发现。

6.1.3.   移动网络

 

预期的表现:

  • C、D通过服务器S协助后,只要地理位置符合一定距离(如100米)要求,可以相互发现

技术点:

  • GPS、基站、网络更信息综合处理后计算距离
  • 通过服务器协助扫描

技术实现:

       由于CD使用的都是移动网络,无法通过同子网下的技术去相互发现,因此在这种环境下,C必须上报自己的进场信息到服务器S,让S来计算CD之间的距离,如果两者距离符合近场通讯的要求(距离符合,并且其中一个可以自动建热点),则服务器SC请求后会返回D,从而完成移动网络下的发现逻辑,反之D发现C也一样。

6.1.4.   移动网络+手机热点

 

预期的表现:

  • A、BD在手动连接C的热点后,ABCD可相互发现
  • B如果支持建热点,则B亦可充当C的角色

技术点:

  • 局域网内局部(自身IP前后10IP地址范围)单点UDP扫描
  • 局域网内广播扫描
  • 创建手机热点
  • 连接手机热点

技术实现:

       如果多台设备中,其中有一台(如上图的C)可以建热点,当热点建立后,ABD手动连接到C后,ABCD既已属于同子网情况(6.1.1已有详细描述),所有发现采用同子网的方法即可相互发现。

6.2.   文件传输

6.2.1.   预传输(特定情况下)

技术点:

  • 自动创建手机热点(一般为Android手机,iPhone当前不可自动创建)
  • 自动连接手机热点(一般为Android手机,iPhone当前不可程序内自动连接)

技术实现:

       当CD通过服务器得知两者符合近场收发条件时,C如果要给D发送文件,则C在给D发送文件信令(仅仅是文件的相关信息,不包括文件内容)后,C会在程序内自动创建一个热点,并且等待D过来连接。当D收到文件信令并确认接收文件后,程序内部会自动连接C的热点,一旦连接成功,既已完成预传输过程,后续即可通过HTTP协议来进行文件传输。

6.2.2.   文件传输

技术点:

  • HTTP服务器和客户端
  • HTTP断点续传

技术实现:

       当ABCD通过某种方法(参照6.2)相互发现后,经过预传输过程(如果有)后,即可通过HTTP协议进行文件传输,由于HTTP本身为公知协议,相应技术也属于公知技术,在此不做详细描述。

6.2.3.   信令交互

技术点:

  • 局域网内UDP通讯
  • 后台服务器信令转发

技术实现:

       当ABCD通过某种方法(参照6.2)相互发现后,经过预传输过程(如果有)后,即可让ABCD进入同子网或跨子网环境下,此环境下一般是可以通过UDP进行信令收发的。此时如果其中一台设备需要发送信令到另一台设备时,我们会采用“通过服务器转发”和“UDP近场通道”两条路径同时发送,只要其中一条路径可成功送达,即可成功,大大提高成功率,也缩短了信令在网络中传输的时间。

 

7、产品的意义对未来的展望

现在,我们通过近场能力,满足了点对点两人之间进行文件传输的需求。但相似的应用场景还不仅与此,基于近场发现、近场传输的场景还有较大的拓展空间。

将来,我们将探索在弱网或者无网络情况下,多人之间进行多媒体内容分享、 实时沟通的场景需求,例如多人进行0流量文件传输、近场发现附近的人并快速创建会话、近场进行异步的文件共享等,让移动端的用户在类似的场景下做到省时间、省流量、省心使用QQ的文件传输服务。