迅雷下载JS-SDK正式上线!

2018年04月27日 16:37| 1,277,366 次浏览| 发布者 强伊文| 2 评论

迅雷下载JS-SDK官网:

http://open.thunderurl.com/

(由于缓存问题,如果你之前已经打开过http://open.thunderurl.com/ 可能需要Ctrl+F5强制刷新一下,才能看到最新版本的页面。)

目前开放的功能:

  1. 创建单个下载任务
  2. 定义单个下载任务的文件名
  3. 定义单个下载任务的下载目录
  4. 创建批量下载任务
  5. 定义批量下载任务的文件夹名
  6. 定义批量下载任务的下载目录
  7. 定义下载完成时,打开指定的安装文件(仅限通过安全性及用户体验审查的网站)

接下来是闲扯时间。。。

不知道为什么,自从有迅雷以来,迅雷从来没有对外开放过在网页中调用迅雷进行下载的SDK。唯一比较类似的东西,是以前给合作网站提供的迅雷专用链,但是这个东西以前只向合作伙伴提供技术支持,算不上真正的开放。

于是乎,想要在页面上调用迅雷下载的站长们,只好八仙过海各显神通了。有的站长把以前给合作网站提供的“迅雷专用链”,照葫芦画瓢拿来用。

更有技术能力比较强的站长研究了以前“迅雷快传”的调用方法,自己写脚本进行实现。甚至还有网站在通过古董级的IE浏览器插件API来调用迅雷下载(这种方式只支持IE内核浏览器),比如伊文也经常玩的“坦克世界、战舰世界”。

image

我们突然意识到,迅雷早就应该对外开放调用迅雷下载的SDK了。接着我们开始对目前正在通过各种方法调用迅雷下载的站点进行调研,也尽可能的联系站长进行访谈。初步了解到外界对于调用迅雷下载有哪些基本需求,以及目前的实现方式上存在哪些不足之处。

比如,我们发现许多网络游戏的安装包,是“一个安装程序+多个数据分块文件”的形式提供下载的。用户在安装时需要确保所有文件都在同一个文件夹内,否则就会造成安装失败。

因此我们在这次开放的迅雷下载JS-SDK中官方提供了一键创建批量下载任务的支持,同时能指定创建单独的文件夹来保存这些文件。

imageimage

而且我们的JS-SDK能够支持“IE、EDGE、Chrome、Firefox”等主流浏览器!

除此之外,我们还了解到许多站长都抱怨,我们以前的迅雷专用链js文件比较大,而且访问不稳定。因此我们对JS-SDK的代码进行优化,并且将js文件放到了更快更稳定的商业CDN上。

这些变化,仅仅是我们开放迅雷下载JS-SDK所迈出的第一步。未来我们还将提供更多强大的功能,来满足各种应用场景的需求。

欢迎大家加入我们的“迅雷下载JS-SDK讨论群(QQ群号:754251297)”,给我们提出问题或建议!

迅雷下载JS-SDK讨论群

Mac迅雷3.2.2.3574正式版发布!

2018年04月19日 17:03| 383,819 次浏览| 发布者 强伊文| 1 评论

下载地址:

http://down.sandai.net/mac/thunder_3.2.2.3574.dmg

更新信息:

  • 新增迅雷快鸟宽带提速和上行提速功能
  • 新建任务时新增“添加批量任务”功能
  • 新增’合并为任务组’功能
  • 播放器支持左右方向键持续快进/快退
  • 下载引擎升级与Bug修复
  • 已知Bug修复与细节优化

Mac迅雷3.2.1.3518正式版发布!

2018年03月22日 15:33| 399,489 次浏览| 发布者 强伊文| 2 评论

下载地址:

http://down.sandai.net/mac/thunder_3.2.1.3518.dmg

更新信息:

  • 试用会员加速改成流量模式
  • 分离下载进程跟用户界面进程
  • 更新chrome和firefox的浏览器插件
  • 重构应用页面,加入iOS迅雷安装入口
  • XLPlayer播放器功能优化
  • 修复一处下载引擎崩溃问题
  • 修复其他已知bug

Mac迅雷3.2.0.3446正式版发布!

2018年01月31日 15:08| 922,923 次浏览| 发布者 强伊文| 7 评论

下载地址:

http://down.sandai.net/mac/thunder_3.2.0.3450.dmg

更新信息:

  • 首页精选改版,加入迅雷影评
  • 导航栏增加迅雷影评入口
  • 播放器支持4K视频播放
  • 移除网络测速模块
  • 浏览器插件、下载引擎优化
  • 修复资源评论由于路由器劫持引起的崩溃问题
  • 修复其他已知问题

为什么迅雷限制不住上传速度?

2018年01月08日 19:04| 761,010 次浏览| 发布者 强伊文| 89 评论

自从伊文转行去做产品策划之后,好久没在阳台上写点什么了。恰逢临近年关手上的事情少了许多,就寻思着回到阳台再给大家写点有价值的东西。

就在刚才,伊文在微博上看到这么一条吐槽。

这位雷友将迅雷的上传速度限制为 33KB/s,但是左侧显示的“当前上传速度”为 213.44KB/s,于是他吐槽说“迅雷太坑人”。

Snipaste_2018-01-08_16-50-07

其实不少雷友,也对迅雷有着“限制不住上传”的传统印象,但实际上这是产品交互设计上的不足导致的误解。

为什么说是误解?

首先我们得从基础的下载原理说起。

我们都知道,下载是个接收信息的过程,而上传是个发送信息的过程。

如果做个拟人化的比喻,下载就是用耳朵听,上传则是用嘴巴说。

现在,假设A要给B念一句诗“苟利国家生死以”。

我们把A给B念这句诗的过程,想象成下载一个文件,这个过程是这样的。。。

A:“我要念诗了,你听到了吗?”

B:“我听到了,这句诗有几个字?”

A:“有7个字,你听到了吗?”

B:“我听到了,你念吧”

A:“第1个字 苟 你听到了吗?”

B:“我听到第1个字了”

A:“第2个字 利 你听到了吗?”

B:“我听到第2个字了”

A:“第3个字 国 你听到了吗?”

B:“我听到第3个字了”

A:“第4个字 家 你听到了吗?”

B:“我听到第4个字了”

A:“第5个字 生 你听到了吗?”

B:“我听到第5个字了”

A:“第6个字 死 你听到了吗?”

B:“我听到第6个字了”

A:“第7个字 以 你听到了吗?”

(A等了5秒还没收到B的回应,于是重复了一遍)

A:“第7个字 以 你听到了吗?”

B:“我听到第7个字了”

(你一定在想,为什么要这么麻烦呢?这是因为网络的可靠性并不总是很好,偶尔会发生A说了某句话,B没有听到的情况。这样虽然麻烦,却能避免信息在传输过程中丢失。)

由此可见,下载一个文件的过程,实际上是个对话过程。B在听到一个字之后,必须要说“我听到了”,A才会说出下一个字,并非简单的A说B听。

在这个对话过程中,“苟利国家生死以”这7个字是要传输的“文件数据”,除此以外的对话内容,我们可以称为“协议通讯”。

当你了解基本原理之后,你应该能够理解。下载文件数据的过程,必然会产生用于“协议通讯”的上传流量。下载速度越快,协议通讯产生的上传速度也越快。

这一原理,对于所有下载行为都是适用的。包括我们通过局域网复制文件时,也会观察到大量的上传。

Snipaste_2018-01-09_13-28-45

现在我们回头来看看吐槽的这位雷友,他虽然限制上传速度为 33KB/s,但是他同时在以5.55MB/s的高速进行下载,协议通讯肯定会产生不小的上传速度。

50d148f9gy1fms54cwjg5j21kw16o7wm

还记得我前面说过“这是产品交互设计上的不足导致的误解”吗?

这个不足就在于迅雷显示的“当前上传速度”是包含了“协议通讯”产生的上传速度的。

而限制上传速度的选项,只限制了上传“文件数据”的速度,不限制“协议通讯”的上传速度。

因为限制了“协议通讯”的上传速度,就会严重拖慢下载速度。

这才造成了“迅雷限制不住上传速度”的问题。

所以,在未来的迅雷版本中,我们会将协议通讯产生的上传速度单独展示并加以说明。

希望各位雷友能够理解,迅雷真的不是要坑你。。。