火山引擎 RTC 音频 AI 降噪的应用与实践_ 字节跳动技术团队的博客-CSDN博客


本站和网页 https://blog.csdn.net/ByteDanceTech/article/details/126416564 的作者无关,不对其内容负责。快照谨为网络故障时之索引,不代表被搜索网站的即时页面。

火山引擎 RTC 音频 AI 降噪的应用与实践_ 字节跳动技术团队的博客-CSDN博客
火山引擎 RTC 音频 AI 降噪的应用与实践
字节跳动技术团队
于 2022-08-18 12:00:35 发布
1128
收藏
文章标签:
算法
游戏
机器学习
人工智能
深度学习
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/ByteDanceTech/article/details/126416564
版权
动手点关注 干货不迷路 👆
从视频会议到远程医疗,从连麦开黑到陪伴社交,疫情常态化加速了线下活动线上化,逐渐改变了人们的生产生活方式。其中,音频质量很大程度上影响着通话体验,而噪声又很大程度决定音频质量。比如,居家办公场景,就流传着“居家办公,必有邻居装修”的定律。也是因为装修声会很大程度影响参与效率,所以对居家办公的同学带来了很大的影响。火山引擎 RTC,集成了自研的深度学习降噪方案,来应对游戏、互娱、会议等实时音视频沟通场景下的噪声影响。
让我们看一下 RTC AI 降噪在会议、游戏、居家场景下的降噪效果对比。
会议场景
游戏场景
居家场景
通过上面的对比效果可以明显看到不同噪声对线上生产、生活场景的影响,以及通过 AI 降噪达到的降噪效果。RTC AI 音频降噪采用了经典的CRN网络结构【参考文献 1】作为降噪框架。CRN 网络结构由 Encoder、Recurrent Layer 和 Decoder 三部分组成。这种结构兼具了 CNN 的深层特征抽取能力和递归网络的记忆能力,表现出了比纯 CNN 网络或者纯 GRU 网络更好的降噪能力。
CRN网络结构
在具体落地到产品的过程中,我们在上述基础模型中,解决了实际场景中出现的五大问题:
如何应对各种复杂的设备,多样的环境如何在满足低延时条件下,提升模型效果如何在满足低计算量条件下,提升模型效果如何平衡强降噪和高保真如何应对对音乐的损伤
通过解决上述问题,可以有效提升算法的速度、实时性和稳定性,保证在语音无损伤的情况下最大程度地实现噪声抑制,提升实时音视频场景,特别是会议、音乐等复杂场景下的互动体验。下面具体展开讲下我们是分别如何解决上述五大问题的。
一、训练数据增广
在我们实际生活中,降噪算法所需要面临的场景是非常复杂多样的。
拿“会议”场景举例,开会环境的多样性给降噪算法带来了不少挑战:在座位上开会,设备会采集到邻座工位上的说话声,此时我们期望算法能去除一定的背景说话人声;在会议室中开会,由于说话人离麦克风的距离各不相同,此时降噪算法面临着多人声、远距离拾音、混响的难题;如果是在公交、地铁、高铁上开会,除了人声,还会引入车辆信号、报站等声音。还有比如在室内玩游戏使用游戏语音的例子,此时,场景中的噪声除了环境噪声,还有敲击屏幕或键盘、拍桌子等各类噪声,此时就需要降噪算法能够尽量抑制足够多类别的噪声。
不仅如此,在不同环境下常用的设备也是不尽相同的。常用设备主要可以归类为以下几类:
除了使用场所有所差别,另外一个主要差异点在于不同设备的采集特性不同,并且自带了不同的音频前处理算法,以现在主流的安卓手机为例,往往出厂就自带了强抑制降噪算法,但在实际体验中仍然存在噪声较多以及人声损伤问题,那么就需要我们的降噪算法去适配这一类“二手”音频数据,包括需要去覆盖残留形态的噪声数据,以及损伤形态的人声数据。
除此之外,个人外接设备也需要特别小心,比如有线耳机可能会带来高频噪声,而蓝牙耳机可能引入连接不稳定的问题,并且降噪耳机还携带有额外的音频处理能力。
下为耳机杂音噪声降噪前后的表现。
我们将在数据增广过程中着重应对这类问题。将增广中噪声的类型打上标签、对不同的场景使用不同的增广配置文件即可配置不同的训练增广方案。下面简单说明一下我们常用的训练数据增广手段。
基本增广手段包括:
音量调整:现实生活中采集到的音量大小往往不同,用于模拟不同采集音量的情况;高低通滤波:不同设备的有效频率不同,如蓝牙耳机往往只有 4k 的有效频段;削波模拟:模拟爆音之后的音频效果;房间冲击响应:模拟不同房间下的混响场景;破音信号模拟:增加对丢帧信号的模拟模拟噪声变化:模拟不同噪声环境,如常见场景的噪声叠加和变化;
我们近期针对语音中的啸叫信号着重进行了模拟和处理。通过线下采集,以及线上仿真模拟的方式生成了大量的不同啸叫周期、频率范围的啸叫语音,并以较低的信噪比融合进原始语音中。
啸叫语音线上模拟
在增加了上述啸叫数据的基础上,我们又单独对啸叫语音施加强抑制的损失函数,消除了大部分的啸叫语音。
我们测试了各种设备、各种场景下的 500+ 种噪声,均能实现理想的消除效果。
二、压缩模型计算量
实时率 (Real Time Factor) 是衡量算法的 CPU 消耗的指标。实时通信下场景,对模型算力要求极为苛刻。为了让模型在移动端可流畅运行,我们主要在特征压缩、模型精简和引擎加速三个方面进行了改进。
(1) 特征压缩
在原始的 CRN 的文章中,使用的是短时傅里叶 (STFT) 特征,如 WebRTC 中默认使用的 257 维的 STFT 特征。但是 STFT 在高频处包含的信息量已经较少,根据人耳听觉特性进行频谱压缩已经是常见的方案,如 RNNoise 中使用 ERB 方案。我们采用根据梅尔听觉特性设计的滤波器进行频谱压缩的方案。
通过将高维特征压缩到低维,能将计算量压缩为原来的 1/3。
(2) 模型精简
如前文所述,我们使用了 CRN 结构作为主要的结构。为了将整体的模型的计算量进行进一步的压缩,我们尝试了很多的策略,主要包括:
将其中的卷积或者转置卷积模块替换为深度可分离卷积或者可分离转置卷积使用空洞卷积,使用更少层数能够获得更长的感受野将 GRU 模块替换为分组 GRU 模块使用稀疏化工具,进一步压缩通道数的大小
通过上述一系列优化,模型的计算量被压缩到数十兆 MACS 的计算量级,模型的参数量在 100K 以内。
(3) 引擎加速
最后我们在字节跳动的推理引擎 ByteNN 上,与智创语音团队和 AI 平台团队合作,新增了适配音频算法的流式推理能力,来提升设备上的计算效率。主要包括:
架构支持子图推理 / 提前退出等流式推理能力节省算力包括卷积 / GRU 等流式算子的支持ARM / X86 等平台汇编级别优化加速
通过上述手段,目前将端到端的 48K 降噪模型的 RTF 指标在各端机型上都控制在 1% 以内。
三、降低延时
为了保证端到端延时在较低水平,AINR 直接使用 AEC 输出的频域特征作为输入,减少了一次 ISTFT 和一次 STFT 的计算时间以及引入的(窗长-步长)的延时(一般在 20ms 左右)。然而在实验中我们发现,由于 AEC 的非线性处理的操作是直接在频谱的操作,导致了 STFT 的不一致性,即原始的 STFT 经过 ISTFT 后再做 STFT 的值与原始值不一致。所以直接使用 AEC 的频域输出(频域特征 1 )作为模型的输入和使用频域特征 2 作为模型输入的处理结果略有不同,前者在个别场景会出现语音损伤。
我们通过一系列的工程手段,解决了这种不一致性,使得处理过程可以绕过上述的 ISTFT 和 STFT 过程,节省了 20 毫秒以上的时间。如此节省下来的时间,可用于增加模型的延时,但保证系统的总体延时不会增加。增加模型的延时对区分清辅音和噪音有很大的帮助。如左、中例子所示,清辅音在频谱和听感上和噪声十分接近,在不知道下文的情况下模型很难做出准确的判断。于是我们引入 20~40ms 不等的较短延时,利用未来的信息帮助模型做当前帧的判断,如右例子所示,加入延时后的非语音段要明显比优化前干净。
加入延时后,噪音消除能力提升
四、降噪与保真的平衡
降噪效果中,强降噪和高保真往往是天平的两端,尤其是针对小模型。强力的降噪往往会带来部分语音的损伤,对语音高保真往往会残留部分的小噪声。比如,在针对 babble 的降噪实验过程中发现,如果采用强力降噪模型,能够把办公室的 babble 类噪声都消除的很干净,但是针对会议室的远场语音就会带来损伤。为了平衡这两者,我们主要采取了如下的一些策略来改进:
剔除噪声脏样本:去掉包含“说话声”的噪声样本,避免噪声中包含内容清晰的语音,导致推理时将远场人声误判为噪声。输入特征进行幅度规整:保证不同幅度的语音提取的特征值是非常接近的,剔除幅度的影响。在静音段部分使用抑制力度大的损失函数,而在人声部分使用保护力度更大的损失函数。来保证非语音段强降噪、而语音段高保真的目的。针对小语音段,在计算损失函数时提升对于语音有损的惩罚力度。
我们以轻微带噪语音的 PESQ 指标作为语音保真的指标。以纯噪部分的残留噪声平均分贝作为噪声抑制的指标。下表列出了几次迭代在会议场景下的指标改进。
第一版第二版第三版语音保留3.723.763.85噪声残留(dB)-75.88-105.99-111.03
从几个版本降噪模型的客观指标来看,语音保护指标在较小的范围内波动,噪声残留则不断减少。可以看出 RTC AI 降噪模型在较大程度保护语音的前提下,噪声抑制力度不断提升。
五、实时音乐识别
在互娱场景,往往有较多的音乐场景。由于部分音乐元素和噪声的特点非常接近,如果直接应用深度学习降噪模型,音乐会被压制得很卡顿。如果把音乐保护加入模型训练,其他语料中的噪声压制的效果会受到影响。因此,准确识别出声音是音乐还是噪声就变得非常重要,能在识别出音乐之后关闭降噪,同时也不会影响正常场景下的降噪力度。
我们的音乐识别模型和【参考文献 2】方法非常相似。都是在 PANNS 【参考文献 3】的 527 类语音检测的基础上,使用语音、音乐和噪声三类数据进行微调。考虑这类方法的一个主要原因是利用 CNN 对长时语音(4 秒窗长)进行建模,以 0.33 秒为步长输出判别结果,来代替如 GRU 类模型帧级别的输出,从而增强识别的效果和稳定性。相对于原文,我们进一步对模型进行了压缩和裁剪,达到了 4M  FLOPS 的计算量 和 20KB 的参数量的尺寸,保证在低端的移动设备上可以运行。同时,在进入音乐时,增加 2 秒延时的多帧融合判断以及离开音乐时 4 秒延时的多帧融合判断,进一步提升了音乐识别的稳定性。在音乐误识别率为 0% 的情况下,召回率达到了 99.6%。
下图展示了 SIP 场景下的音乐共享场景的一个例子。因为 SIP 场景下,共享音乐和采集信号是混合后再传输的,所以共享的信号和采集的信号使用的是同样的处理通路。在实际测试中,我们发现即使用很轻量级的传统降噪方案也会对音乐产生损伤。通过使用音乐检测,保护相对应的音乐段,可以有效缓解该损伤问题。
六、
效果和指标
的对比
通过上述几点的改进,目前无论是主观听感,还是客观指标,火山引擎 RTC 中的降噪算法已经处于行业领先位置。
我们在高中低三种信噪比条件的白噪声、键盘声、babble 噪声、空调噪声四种噪声环境下以及 Windows 和 MAC 设备中,测试了火山引擎 RTC 和行业同类产品的降噪结果的 POLQA 分数。从表中可以看出,无论是在这四种噪声场景上,还是在不同设备上,我们的降噪算法均优于同类产品。
‍‍‍‍‍‍‍‍
在应用 AI 降噪之后,我们能够消除环境噪声带来的各种影响。但除了噪声影响之外,影响语音质量的还包括采集硬件的损伤、硬件处理算法的损伤、传输通道的损伤等等,后续我们会进一步在软件算法中缓解这些损伤,以期达到使用任何硬件均能达到类似录音棚的高音质效果。
参考文献
【1】Tan K, Wang D L. A convolutional recurrent neural network for real-time speech enhancement[C]//Interspeech. 2018, 2018: 3229-3233.
【2】Reddy C K A, Gopa V, Dubey H, et al. MusicNet: Compact Convolutional Neural Network for Real-time Background Music Detection[J]. arXiv preprint arXiv:2110.04331, 2021.
【3】Kong Q, Cao Y, Iqbal T, et al. Panns: Large-scale pretrained audio neural networks for audio pattern recognition[J]. IEEE/ACM Transactions on Audio, Speech, and Language Processing, 2020, 28: 2880-2894.
关于我们
火山引擎 RTC 团队,作为全球领先的音视频团队,我们致力于提供全球互联网范围内高品质、低延时的实时音视频通信能力,目前已经支撑了抖音、TikTok、清北网校、字节系游戏,视频会议等多个场景的应用,服务 10 亿用户,遍布全球每一个角落。 
我们是 RTC Lab 部门,负责 RTC 产品中音频、视频、网络等基础功能的研发,通过极致的工程和音视频算法,打磨顶级的实时音视频基础体验,期待优秀同学的加入!
🏃 扫描上方二维码,或点击阅读原文,赶紧加入我们吧!
字节跳动技术团队
关注
关注
点赞
收藏
评论
火山引擎 RTC 音频 AI 降噪的应用与实践
动手点关注干货不迷路????从视频会议到远程医疗,从连麦开黑到陪伴社交,疫情常态化加速了线下活动线上化,逐渐改变了人们的生产生活方式。其中,音频质量很大程度上影响着通话体验,而噪声又很大程度决定音频质量。比如,居家办公场景,就流传着“居家办公,必有邻居装修”的定律。也是因为装修声会很大程度影响参与效率,所以对居家办公的同学带来了很大的影响。火山引擎 RTC,集成了自研的深度学习降噪方案,来应对游戏、...
复制链接
扫一扫
参与评论
您还未登录,请先
登录
后发表或查看评论
博客
字节跳动一站式数据治理思考及实践
12-14
202
动手点关注干货不迷路导读:今天的分享主要分四个部分:机遇与挑战、数据治理思路、技术架构演进以及未来展望1. 机遇与挑战数据治理工作有很多挑战,最主要的一点是落地比较困难。首先,治理工作中与业务有一定的矛盾。第二,治理涉及的组织和管理难度大。第三,规范“人”的动作难度大,治理过程中,需要依靠人来推进和执行,人员能力参差不起,组织文化、目标也存在不对齐的情况。第四,缺乏适配性强的产品工具。因为治理工作...
博客
火山引擎 RTC 助力抖音百万并发“云侃球”
12-07
623
动手点关注干货不迷路1. 背景及技术挑战从电视看直播到手机电脑看直播,直播技术的发展让观众可以随时、随地观看自己喜欢的比赛,并且在看比赛时通过发送表情、发文字进行互动。但表情、文字承载的信息量较小、沟通效率低,我们无法像线下一起看比赛那样和好友边看边聊、一起为精彩的比赛呐喊,观赛体验大打折扣。为了让观众获得更好的观赛体验,抖音在 2022 世界杯比赛直播中推出了“边看边聊”的玩法:每个观众都可以邀...
博客
字节跳动数据中台的 Data Catalog 系统搜索实践
11-21
777
动手点关注干货不迷路1. 背景Data Catalog 能够帮助大公司更好地梳理和管理自己的资产,是 Data-drvien 公司的重要平台。一个通用的 Data Catalog 平台通常包含元数据管理,搜索,血缘,标签,术语等功能。其中,搜索是 Data Catalog 的入口功能,承担着让用户“找到数”的主要能力。在字节跳动数据中台的 Data Catalog 系统中,每天有 70% 以上的用...
博客
火山引擎 RTC 视频性能降级策略解析
11-16
445
动手点关注干货不迷路1. 背景随着 RTC 使用场景的不断复杂化,新特性不断增多,同时用户对清晰度提升的诉求也越来越强烈,这些都对客户端机器性能提出了越来越高的要求 (越来越高的分辨率,越来越复杂的编码器等)。但机器性能差异千差万别,同时用户的操作也不可预知,高级特性的使用和机器性能的矛盾客观存在。当用户机器负载过高时,我们需要适当降级视频特性来减轻系统复杂性,确保重要功能正常使用,提升用户体验...
博客
火山引擎工具技术分享:用 AI 完成数据挖掘,零门槛完成 SQL 撰写
11-14
413
动手点关注干货不迷路在使用 BI 工具的时候,经常遇到的问题是:“不会 SQL 怎么生产加工数据、不会算法可不可以做挖掘分析?”而专业算法团队在做数据挖掘时,数据分析及可视化也会呈现相对割裂的现象。流程化完成算法建模和数据分析工作,也是一个提效的好办法。同时,对于专业数仓团队来说,相同主题的数据内容面临“重复建设,使用和管理时相对分散”的问题——究竟有没有办法在一个任务里同时生产,同主题不同内容的...
博客
大规模分布式链路分析计算在字节跳动的实践
11-07
1025
动手点关注干货不迷路1. 综述微服务架构的快速发展使得分布式链路追踪系统成为观测体系中越来越重要的组件。字节跳动的分布式链路追踪系统经历了数年的发展后,已覆盖了字节的绝大部分在线业务,完成了对数万微服务和数百万微服务实例的在线链路追踪。在经典的指标观测分析和单请求链路追踪的基础上,如何从浩瀚如海的分布式链路数据中进一步挖掘出更高层次的信息,为业务的架构优化、服务治理、成本优化等场景提供更高效的数据...
博客
深度解析字节跳动开源数据集成引擎 BitSail
11-01
976
动手点关注干货不迷路1. 导读BitSail 是字节跳动开源数据集成引擎,支持多种异构数据源间的数据同步,并提供离线、实时、全量、增量场景下全域数据集成解决方案,目前支撑了字节内部和火山引擎多个客户的数据集成需求。经过字节跳动各大业务线海量数据的考验,在性能、稳定性上得到较好验证。10 月 26 日,字节跳动宣布 BitSail 项目正式在 GitHub 开源,为更多的企业和开发者带来便利,降低数...
博客
一文了解 DataLeap 中的 Notebook
10-27
1856
动手点关注干货不迷路一、概述Notebook 是一种支持 REPL 模式的开发环境。所谓「REPL」,即「读取-求值-输出」循环:输入一段代码,立刻得到相应的结果,并继续等待下一次输入。它通常使得探索性的开发和调试更加便捷。在 Notebook 环境,你可以交互式地在其中编写你的代码、运行代码、查看输出、可视化数据并查看结果,使用起来非常灵活。在数据开发领域,Notebook 广泛应用于数据清理和...
博客
火山引擎 RTC 全球化架构设计
10-24
1072
动手点关注干货不迷路1. 为什么 RTC 要做全球化RTC(Real Time Communication)是音视频基础设施,它已经融入了大家生活的方方面面:工作中,我们组织视频会议,即使团队成员身处异国,也能保证项目推进;休息时,我们打开抖音,看主播直播连麦;来一局游戏时,我们打开小队语音,大杀四方;学习时,我们相聚线上互动课堂,知识传播不再受距离的桎梏。RTC 拉近了大家的距离,丰富了大家的生...
博客
Spark AQE SkewedJoin 在字节跳动的实践和优化
10-12
1768
动手点关注干货不迷路1. 概述本文将首先介绍 Spark AQE SkewedJoin 的基本原理以及字节跳动在使用 AQE SkewedJoin 的实践中遇到的一些问题;其次介绍针对遇到的问题所做的相关优化和功能增强,以及相关优化在字节跳动的收益;此外,我们还将分享 SkewedJoin 的使用经验。2. 背景首先对 Spark AQE SkewedJoin 做一个简单的介绍。Spark Ada...
博客
深入理解 Android Studio Sync 流程
10-10
1958
动手点关注干货不迷路1. 初识 Sync我们一般会把 Sync 理解为 Android Studio 的准备阶段,包括解析工程配置信息、下载远程依赖到本地、更新代码索引等准备工作,当修改 gradle build 文件后,需要重新 Sync 将 Gradle 构建配置信息同步到 IDE,进而使 IDE 的功能及时应用新的构建配置,这些功能包括项目的 Gradle Task 列表展示、依赖信息展示等...
博客
火山引擎 RTC 自研音频编码器 NICO 实践之路
09-30
1683
动手点关注干货不迷路1. 前言随着互联网技术的不断发展,越来越多的人开始尝试使用或者依赖实时音视频产品解决团队沟通与协作问题。在通话过程中,我们时常会遇到因为网络波动(如拥塞、丢包、延时和抖动等)而导致的音频卡顿、掉字或者杂音等问题,影响工作效率。为解决此类音频弱网问题,业界一般采用前向纠错(Forward Error Correction,FEC)或者重传等网络策略优化方法,但这些方法存在冗余率...
博客
prompt 综述
09-28
1365
动手点关注干货不迷路1. 概述1.1 基本概念用一句话概括模板学习,即将原本的输入文本填入一个带有输入和输出槽位的模板,然后利用预训练语言模型预测整个句子,最终可以利用这个完整的句子导出最终需要的答案。模板学习最吸引人的关键在于其通过已有的预训练模型,定义合适的模板就能完成 few-shot 或者 zero-shot 任务,这样可以使得语言模型可以在预训练阶段利用尽可能多的信息进行训练,后续也能最...
博客
初探自然语言预训练技术演进之路
09-27
879
动手点关注干货不迷路人工智能的三个层次:运算职能:数据的存储和计算能力,机器远胜于人类。感知职能:视觉、听觉等能力,机器在语音识别、图像识别领域已经比肩人类。认知智能:自然语言处理、常识建模与推理等任务,机器还有很长的路要走。自然语言处理属于认知智能范畴,由于自然语言具有抽象性、组合性、歧义性、知识性、演化性等特点,为机器处理带来了极大的挑战,有人将自然语言处理称为人工智能皇冠上的明珠。近些年来,...
博客
Redis 持久化策略浅析
09-26
1298
动手点关注干货不迷路Redis(Remote Dictionary Server ),即远程字典服务,是一个开源的内存高速缓存数据存储服务。使用 ANSI C 语言编写,支持网络、可基于内存亦可持久化的日志型、Key-Value 数据存储,并提供多种语言的 API。▶ 简介Redis 是内存数据库,数据都是存储在内存中,为了避免进程退出导致数据的永久丢失,需要定期将 Redis 中的数据以某种形式...
博客
Babel 插件:30分钟从入门到实战
09-16
1515
动手点关注 干货不迷路 ????Babel 是一个 source to source(源码到源码)的 JavaScript 编译器,简单来说,你为 Babel 提供一些 JavaScript 代码,Babel 可以更改这些代码,然后返回给你新生成的代码。Babel 主要用于将 ECMAScript 2015+ 代码转换为能够向后兼容的 JavaScript 版本。Babel 使用插件系统进行代码转换,因...
博客
HiveServer2 内存泄漏问题定位与优化方案
09-09
1842
动手点关注 干货不迷路 ????前言HiveServer2 属于 Hive 组件的一个服务,主要提供 Hive 访问接口,例如可通过 JDBC 的方式提交 Hive 作业,HiveServer2 基于 Java 开发,整个服务运行过程中,内存的管理回收均由 JVM 进行控制。在 JVM 语言中的内存泄漏与 C/C++ 语言的内存泄漏会有些差异,JVM 的内存泄漏更多的是业务代码逻辑错误引起大量对象引用被...
博客
火山引擎在行为分析场景下的 ClickHouse JOIN 优化
09-05
1090
动手点关注 干货不迷路 ????1. 背景火山引擎增长分析 DataFinder 基于 ClickHouse 来进行行为日志的分析,ClickHouse 的主要版本是基于社区版改进开发的字节内部版本。主要的表结构:事件表:存储用户行为数据,以用户 ID分 shard 存储。--列出了主要的字段信息CREATETABLEtob_apps_all(`tea_app_id`...
博客
飞书 Android 升级 JDK 11 引发的 CI 构建性能问题
09-02
929
动手点关注干货不迷路????一、摘要本文从飞书 Android 升级 JDK 11 意外引发的 CI 构建性能劣化谈起,结合高版本 JDK 在 Docker 容器和 GC 方面的新特性,深挖 JVM 和 Gradle 的源码实现,抽丝剥茧地介绍了分析过程和修复方法,供其他升级 JDK 的团队参考。二、背景最近飞书适配 Android 12 时把 targetSdkVersion 和 compileSd...
博客
春节活动 - 高峰值奖励发放技术方案
08-30
1168
动手点关注 干货不迷路 ????1. 背景2022年春节活动在8款字节系 APP 上线,包含了红包雨、集年味卡和烟火大会等诸多玩法。红包雨、集卡开奖和烟火大会都存在高峰值突发流量。其中,红包雨活动会在10分钟内给几千万甚至上亿用户发放上亿现金奖励,且大多数请求集中在前3分钟。在项目启动时,红包雨活动作为最大的流量来源,预估的发红包峰值流量有180万 QPS 。为了保证用户体验、活动效果和资金安全,红包雨...
“相关推荐”对你有帮助么?
非常没帮助
没帮助
一般
有帮助
非常有帮助
提交
字节跳动技术团队
CSDN认证博客专家
CSDN认证企业博客
238
原创
9690
周排名
1719
总排名
128万+
访问
等级
8466
积分
5913
粉丝
656
获赞
369
评论
2165
收藏
私信
关注
热门文章
抖音品质建设 - iOS启动优化之原理篇
38182
字节跳动自研万亿级图数据库 & 图计算实践
31420
字节跳动技术团队年度 TOP10 技术干货,陪你度过不平凡的 2020
27557
字节跳动自研线上引流回放系统的架构演进
26426
字节跳动开源云原生机器学习平台 Klever
24539
最新评论
浅谈Linux设备虚拟化技术的演进之路
Bill_Xiang:
vdpa将virtio带入了容器领域,容器是说只能用内核驱动的网络设备,没有vdpa之前virtio应该是说只能虚拟机用,有了vdpa之后容器也能用virtio硬件设备了,然后vduse又进一步可以给容器提供软件的virtio设备,总的来说还是用在容器的场景里,可以这么理解吧
Android 系统 Bar 沉浸式完美兼容方案
huaqiangsina:
鸿蒙无效。
字节跳动智能创作团队多篇论文入选 CVPR 2022
小菜鸡加油:
Dressing in the Wild by Watching Dance Videos 这一篇没有代码吗
抖音Android无障碍开发知识总结
qiixiao:
所以,抖音app是和Mac一样,支持按键操作吗?
西瓜视频 iOS Voice Over 无障碍适配实践
LTOVE-CODE:
多音字怎么处理的
您愿意向朋友推荐“博客详情页”吗?
强烈不推荐
不推荐
一般般
推荐
强烈推荐
提交
最新文章
字节跳动一站式数据治理思考及实践
火山引擎 RTC 助力抖音百万并发“云侃球”
字节跳动数据中台的 Data Catalog 系统搜索实践
2022
12月
2篇
11月
5篇
10月
4篇
09月
8篇
08月
11篇
07月
14篇
06月
21篇
05月
17篇
04月
11篇
03月
6篇
02月
8篇
01月
8篇
2021年58篇
2020年47篇
2019年12篇
2017年6篇
目录
目录
最新文章
字节跳动一站式数据治理思考及实践
火山引擎 RTC 助力抖音百万并发“云侃球”
字节跳动数据中台的 Data Catalog 系统搜索实践
2022
12月
2篇
11月
5篇
10月
4篇
09月
8篇
08月
11篇
07月
14篇
06月
21篇
05月
17篇
04月
11篇
03月
6篇
02月
8篇
01月
8篇
2021年58篇
2020年47篇
2019年12篇
2017年6篇
目录
评论
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
查看更多评论
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额
抵扣说明:
1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。 2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。
余额充值