QQ 的时候就有「一起听歌」功能会是多么有趣的一件事,实现系统到 APP 的通信

摘要QQ 最新版本 8.1.3 上线的一个新功能——“一起听歌”。简单来说就是你和 QQ
好友在聊天的时候,直接点击右上角的选项按钮并开启「一起听歌」功能,就可以任选一首喜欢的音乐,和对象一边听歌一边聊
QQ。引言听说 95
后已经不知道这是什么了?「耳机分线器」这个听起来有点质朴的名字,已经是十几年前流行的玩意儿,那时候同学、朋友甚至情侣之间最亲密的举动,无非就是一人一副耳塞,同步听着同一首歌。这么多年过去了,一起听歌依旧亲密友好的象征,只不过现在的年轻人,有了更多有趣的玩法——比如用
QQ 一起听。为什么
QQ「一起听歌」如此受用户喜爱?QQ「一起听歌」是什么?其实这是 QQ 最新版本
8.1.3 上线的一个新功能。简单来说就是你和 QQ
好友在聊天的时候,直接点击右上角的选项按钮并开启「一起听歌」功能,就可以任选一首喜欢的音乐,和对象一边听歌一边聊
QQ。你们可以通过这个功能一起回忆往昔金曲,也可以快速安利最近的心头所好。当然,有人也许会问「我直接把音乐分享给对方不就好了吗?」,然而直接分享面临的一个问题是——你如何知道对方真的点开来听来呢?又怎么保证他听的进度和你保持一致呢?同时、同步、同一首歌,这是
QQ 「一起听歌」功能的一个重要特性,我想这些产品细节也正是
QQ「一起听歌」功能受到用户喜爱的重要原因。据说,「一起听歌」功能在灰度测试期间就受到了许多恋爱中的年轻人的喜爱。什么,你说你没有对象?那么
A
君建议你,和好朋友一起听首《柠檬树》也是一个不错的选择。说来也巧,其实这不就和我们以前听着
MP3
也要买一个「一分二耳机线」一样吗?总是忍不住想把自己喜欢的音乐和喜欢的人分享,只不过那时的技术还没有强大到在线上就能一边聊天一边分享音乐。现在想想,如果我们当初用
QQ 的时候就有「一起听歌」功能会是多么有趣的一件事。不得不说,QQ
总是能够准确地捕捉到年轻群体的需求。

摘要微信自用的安卓APP与系统间通信解决方案——Hardcoder已开源,该方案能让微信的整体性能提升10%-30%。1、Hardcoder
的诞生随着微信越来越复杂,性能优化变得越来越难做,优化所带来的效果提升也越来越不明显。所以我们⼀直在思考,该如何突破这个优化的极限?直到有一次与厂商的交流我们了解到,部分厂商会针对微信做一些小改动,其中比较典型的就是“暴力提频”。系统在识别到微信启动,页面切换等场景时,会粗暴地提高
CPU 频率,从而提升 APP
运行的性能。但由于厂商无法准确判断微信场景,暴力提频效果并不理想;而如果过多地提高
CPU
频率,又对手机的功耗有影响。这一方案启发了我们,我们何不跳出软件的范畴,在手机硬件的层面上挖掘更多的性能优化空间呢?于是
Hardcoder 框架应运而生。2、Hardcoder
是什么厂商暴力提频效果不理想是由于在目前 Android
框架下,手机没有办法准确获知 APP
需要资源的时机。如果我们需要挖掘手机硬件层面的性能优化,就需要跳过
Android
操作系统的应用框架,在应用开发者和硬件之间打开一个通道,让硬件可以直接根据应用开发者的需要进行资源的调度。Hardcoder
构建了 APP 与系统(ROM)之间可靠的通信框架,突破了 APP 只能调用系统标准
API,无法直接调用系统底层硬件资源的问题,让 Android APP
和系统能实时通信。利用 Hardcoder,APP 能充分调度系统资源如 CPU
频率,大小核,GPU 频率等来提升 APP 性能,系统能够从 APP
侧获取更多信息以便更合理提供各项系统资源。同时,对于 Android
缺乏标准接口实现的功能,APP
和系统间也可以通过该框架实现机型适配和功能拓展。3、Hardcoder
框架通信流程Hardcoder 框架分为 Server 端和 Client 端。其中 Server
端在厂商系统侧实现,Client 端以 aar 形式合入到 APP中。APP
在需要资源的时候,向 Hardcoder 的 Client 端发出请求。Hardcoder Client
端接收到请求后向 Hardcoder Server 端发出请求。Server
端接受到请求后会根据请求参数向硬件申请不同的资源,比如调整 CPU
频率,把线程绑定到大核运行等,实现了 APP
到系统的通信。同时系统也可把当前系统的状态通过 Hardcoder Client 在
Server 端注册的接口回调通知到 Client 端,从而 APP
可以获取到系统状态,实现系统到 APP 的通信。Hardcoder Client 端与 Server
端采用的是 LocalSocket 的通信方式,由于 Hardcoder 采用 Native
实现,因而在 C 层使用 Linux 的 socket 接口实现了一套 LocalSocket
机制作为 Client 端与 Server 端之间的通信方式。Hardcoder
通信框架有以下特点:1)系统服务为
optional,实现上可以完全支持或者部分支持;2)框架实现不依赖于特定
Android 系统,如 API level 限制;3)APP
的功能和业务特性不依赖于该框架。4、Hardcoder 适用场景和效果Hardcoder
框架有效提升了微信启动、发送视频、小程序启动等重度场景的速度,朋友圈的滑动流畅性也明显提升,平均优化效果达
10%-30%。此外,由于微信作为主动请求方可以在场景资源把控上做得更精细和准确,Hardcoder
在性能得到提升的同时仅增加了 2% 的电量消耗,相当于用 2% 的功耗换取平均
20% 的性能提升。Hardcoder 框架目前已接入
OPPO、vivo、华为、小米、三星、魅族等主流手机厂商,覆盖 4.6 亿+
设备量。5、Hardcoder
开源从微信技术开放共享的理念出发,我们在腾讯内部进行了 Hardcoder
框架的宣传和推广,包括手机
QQ、企业微信、天天快报等多个应用团队接入。其中手机 QQ 接入 Hardcoder
后,在启动、打开聊天界面、发送图片等场景的平均优化效果达
10%-50%。我们现将 Hardcoder 框架开源,让更多 Android 开发者享受到
Hardcoder 框架的价值,解决大家在性能优化和机型适配上的烦恼。欢迎大家查阅
github 网址:
Hardcoder一、通过 Hardcoder 技术方案介绍,了解 Hardcoder
实现原理以及框架;二、使用工程自带 testapp 快速使用 Hardcoder
并验证效果,具体请见 Hardcoder Testapp 测试指南;三、APP 接入
Hardcoder,具体请参见 Hardcoder 接入指南:1)下载 Hardcoder 工程编译
aar;2)项目 build.gradle 引入 Hardcoder aar;3)进程启动时调用
initHardCoder 建立 socket
连接(一般进程启动时需要请求资源,因而推荐在进程启动时调用)。每个进程都是独立的,都需要调用
initHardCoder 建立 socket 连接,建立连接后每个进程维持一个
socket,进程退出时 socket 也会断开;4)initHardCoder 回调成功后调用
checkPermission,传入 APP
已申请的各个厂商鉴权值;5)在需要请求资源的场景调用
startPerformance,传入请求资源的参数。若场景位于进程启动阶段,比如 APP
启动,需要在 initHardCoder 的回调成功以后再调用
startPerformance,确保连接已成功建立,或者判断 HardCoderJNI 的
isConnect() 检查 socket 是否已连接。6)场景结束时主动调用
stopPerformance,传入对应场景 startPerformance 时的返回值 hashCode
作为参数,停止本次请求。7)测试性能,APP 可对打开/关闭 Hardcoder
的情况做对比实验,测试性能是否有提升。四、向厂商申请线上权限,具体请见常见问题;五、发布带
Hardcoder 功能的 APP。附录: github的wiki
文档链接Hardcoder产品方案介绍:
技术方案介绍:
testapp
测试指南:
接入指南:

摘要因认为“吹牛”软件使用了与微信相似的红包界面和聊天表情,腾讯该软件运营公司告上法庭。1、引言因认为“吹牛”聊天软件使用了与微信相似的红包界面和聊天表情,腾讯科技(深圳)有限公司(简称腾讯科技公司)和深圳市腾讯计算机系统有限公司(简称腾讯计算机公司)将“吹牛”软件的开发运营方北京青曙网络科技有限公司(简称青曙公司)告上法庭,并分别索赔450万元和50万元。2019年7月19日,北京互联网法院分别对“微信红包”和“微信表情”两案进行一审宣判:“微信红包”案判决书原文:
“微信”应用软件中,“微信红包聊天气泡”和“微信红包开启页”2)被告辩称:电子红包的创作设计来源于生活中的实物红包,“微信红包”不具有独创性;“微信红包”相关页面及微信整体页面不构成有一定影响的装潢。被告辩称,原告进行作品登记前有大量与之相同或相似的作品发表,涉案“微信红包聊天气泡和开启页”不具有独创性;被告使用的电子红包与涉案作品存在差异。因此,被告未实施著作权侵权行为。“微信红包”相关页面及微信整体页面不构成有一定影响的装潢,被告未以任何形式宣传其软件与“微信”应用软件存在关联,相关公众不会产生混淆或误认。因此,被告未实施不正当竞争行为。▲“吹牛”聊天软件中被控侵权“红包聊天气泡”和“红包开启页”5、“微信表情”案双方的主要论点1)原告诉称:涉案微信表情具有独创性,构成美术作品,原告对其享有著作权。被告未经许可,在其经营的“吹牛”应用软件中提供与涉案微信表情完全相同的聊天表情,侵害了原告享有的信息网络传播权。据此,原告请求:被告赔偿原告经济损失及合理开支共计50万元。▲涉案微信表情2)被告辩称:原告不享有涉案微信表情的著作权。被告辩称,虽然涉案聊天表情构成美术作品,但是在案证据不能证明原告对其享有著作权;被告已经停止使用涉案微信表情;原告主张的经济损失和合理开支过高,缺乏法律依据。▲被控侵权表情6、主要争议焦点及裁判要旨“微信红包”案的主要争议焦点:1)“微信红包聊天气泡和开启页”是否构成作品,被告是否侵犯原告的信息网络传播权;2)“微信红包”相关页面及微信整体页面是否构成“有一定影响的装潢”,被告是否实施了不正当竞争行为。“微信红包”案的裁判要旨(详见判决书):1.1
“微信红包聊天气泡和开启页”的颜色与线条的搭配比例、图形与文字的排列组合,体现了创作者的选择、判断和取舍,展现了一定程度的美感,具有独创性,构成美术作品;其与被告提出的相似或相近的电子红包在颜色搭配与变化,文字、线条、图形的排列组合与位置设计等方面均存在明显差异,具有独创性。1.2
被告的电子红包聊天气泡和开启页与原告主张的“微信红包聊天气泡和开启页”分别构成实质性相似,被告未经许可进行使用,使用户可以在其选定的时间和地点使用原告的“微信红包聊天气泡和开启页”,侵犯了原告的信息网络传播权。2.1
“微信红包”相关页面,是“微信红包服务”的整体形象,其相关页面附加的文字、图案、色彩及其排列组合,具有美化服务的作用,且其已具有良好的宣传效应,受到用户的广泛欢迎,应当属于“有一定影响的服务装潢”。但微信整体页面仅是软件类产品的常规设计,没有体现独特性,不构成“有一定影响的服务装潢”。2.2
被控侵权页面与“微信红包”相关页面整体视觉效果上构成近似,容易造成公众的混淆和误认,系不正当地利用他人的劳动成果攫取竞争优势,损害了正常的市场竞争秩序,构成不正当竞争。“微信表情”案的主要争议焦点:1)腾讯科技公司是否对涉案微信表情享有著作权;2)被告行为是否侵犯了原告的信息网络传播权。“微信表情”案的裁判要旨(详见判决书):1.1
涉案微信表情涉案微信表情均为采用“黄脸表情”设计理念的卡通形象设计,即用圆形黄色表示面部,在此基本造型的基础上,通过眼部、嘴部、手势等神态的变化来反映人物的不同情绪,生动、形象、富有趣味,在线条、色彩运用等方面体现出一定的个性化选择和独创性表达,具有审美意义,构成美术作品;腾讯科技公司系涉案微信表情的作者,涉案微信表情的创作完成时间为2016年8月29日,故腾讯科技公司自该日起对涉案微信表情享有著作权。1.2
关于被告提出的“奸笑”表情与百度团队在先设计的“滑稽”表情相同或构成实质性相似的抗辩主张,法院认为两表情在眉毛的位置、长短和形状,眼睛的位置、大小和形状,以及腮红的深浅等方面均存在客观可识别的明显差异,且两表情传递出的情绪和含义明显不同,因此“奸笑”表情具有独创性。1.3
关于被告提出的涉案“捂脸”表情与金召平申请注册的商标一致,且金召平申请注册商标时间早于涉案“捂脸”表情登记时间的抗辩主张,法院认为涉案“捂脸”表情的创作完成时间和发表时间均早于金召平申请商标注册的时间,且被告并未提交证据证明该商标由金召平创作完成,不能证明金召平是涉案“捂脸”表情的作者。1.4
关于被告提出涉案“嘿哈”表情的原型来自卢正雨表情包的抗辩主张,法院认为,在案证据不能证明卢正雨的表情包早于“嘿哈”表情的创作完成时间,且二者的表现形式并不相同,从真实人物的表情到聊天表情美术作品的创作,需要作者对线条、颜色等进行选择、判断和取舍,凝结了其独创性的智力劳动,不能证明原告不是涉案“嘿哈”表情的著作权人。1.5
关于被告提出部分涉案微信表情来自于微信表情开放平台投稿的抗辩主张,法院认为来自开放平台的聊天表情的提交时间和上架时间均晚于涉案微信表情的发表时间,不能证明原告不是涉案微信表情的著作权人。2.1
被告未经许可在其经营的“吹牛”应用软件中使用了与涉案微信表情完全相同的聊天表情,被告的行为使该软件的用户可以在其个人选定的时间和地点获得涉案微信表情,侵犯了原告依法享有的信息网络传播权,应当承担相应的民事责任。7、“吹件”聊天软件现状及其运营分司现状不知是否与此两起判决有关,“吹件”聊天软件的运营公司已处于异常名录中:该公司所属的网站和APP已通通不可访问:

发表评论

电子邮件地址不会被公开。 必填项已用*标注

相关文章

网站地图xml地图