公司:哔哩哔哩
bilibili,音译哔哩哔哩,是总部位于中华人民共和国上海市的一个以ACG相关内容起家的弹幕视频分享网站,故简称及通称B站[f]。此外,bilibili的前身为视频分享网站Mikufans,并由网友“⑨bishi”(徐逸)于2009年6月26日创建。Mikufans建站的初衷是为用户提供一个稳定的弹幕视频分享网站,其后于2010年1月24日改为“bilibili”。
bilibili的内容随着发展渐渐不仅限于ACG,主要分区分为番剧、国创、放映厅、纪录片、漫画、专栏、直播、课堂、动画、音乐、舞蹈、游戏、知识、数码、生活、美食、VLOG、鬼畜、时尚、娱乐、影视、电影、电视剧、音频,除此之外亦有会员购、专题中心、全区排行榜、活动中心、能量加油站、社区中心、工坊集市、小黑屋、音乐PLUS、游戏中心(特指由哔哩哔哩代理登陆接口的游戏发布平台)、游戏赛事的区域。除了视频外哔哩哔哩还运营有《命运/冠位指定》、《崩坏学园2》等多部游戏。而现在网站标题中含有“( ゜- ゜)つロ 干杯~”的颜文字以做宣传。除此之外bilibili也被用户称为小破站、小电视。至2015年,75%的用户年龄在24岁以下,是年轻人的聚集地。
至2023年3月31日,B站月均活跃用户达3.15亿,移动端月均活跃用户达2.76亿,分别增加31%及33%。在用户健康增长的基础上,B站也在不断加快商业基础设施建设,提高社群服务管控能力。B站月均付费用户增长至2,720万,同比增长33%,付费率提升至9.3%。不过做大的同时,bilibili的成长空间也逐渐饱和,影视会员与视频业务在2022年营运呈现亏损扩大状态,年轻新人大量涌入却未能利用,而部分老用户指B站感觉变了,对现在的评论管理与风气感到不满,同时其up主也因为投稿不顺、分成不足等问题,开始出现部分停更现象。对此B站开始进行裁员降本增效,重新把精力投入游戏与商业制作上,项目2024年达到盈亏平衡。
内容生产全链路业务观测体系建设
UP主创作的视频内容最终会以"稿件"为载体进行打包投稿。一个稿件从创作到最终用户能观看到,需要经过非常多的环节。这些创作工作,都可以通过B站的集成创作工具来闭环完成。
稿件生产业务并发竞争场景下的安全性保障
视频业务作为B站内容生态的心脏,承载了海量的视频内容和用户互动。
技术怎样支撑和游戏主播一起云玩游戏
游戏直播是玩家通过互联网平台实时分享其游戏过程和技巧的一种媒介。
B站前端错误监控实践
从23年开始,团队开始前端错误监控方向的开发。经历了一些列的迭代和发展,从监控SDK、上报、数据治理、看板集成、APM自研可视化初步完成了一条完整且适合B站前端监控。
B站开源长文本大模型:我很小但很能“装”
Index-1.9B-32K 是一个拥有 1.9B (19亿)参数并具备 32K 上下文长度的语言模型。
互动中心平台演进
在当下的直播业务中,实时音视频交互已经变成主播与主播,主播与用户之间的主要交流模式。
哔哩哔哩直播通用奖励系统揭秘
本文介绍了B站直播奖励系统的技术架构,从需求分析到实现细节,全面解析其背后的技术方案。
B站直播的极速排障建设-全链路Trace追踪
直播业务具有实时性强,复杂度高,排查链路长,影响面大等特征,线上问题如果不能立刻排查处理,分分秒秒都在影响用户的观看体验、主播的收入。
安卓/iOS 和 Windows 的 USB 有线投屏
本文基于Windows平台,介绍计算机与安卓/iOS通过USB交换数据的实现方式。
文档画中画之跨页面播放队列
2023年8月中旬文档画中画特性跟随chrome116版本发布,基于该功能特性,我们于2023年10月中旬启动了B站跨页面播放队列功能的开发与功能灰度,并于2024年6月中旬完成了灰度全量。
B站故障应急与业务1-5-10摸排:如何实现超95%故障自发现率?
2023下半年B站已实现了推搜业务故障自发现率95%+,社区相关故障自发现率80%+。
用多模态技术在多媒体系统中实现场景分类
多模态是结合了图像、文本、音频等多种数据类型的一种技术方案。该技术不仅提高了模型的泛化能力,还扩展了人工智能技术的应用方向,如图像分类、图像问答、文本图像生成等。
基于改进字典的大数据多维分析加速实践
OLAP场景是大数据应用中非常重要的一环,能够快速、灵活地满足业务各种分析需求,提供复杂的分析操作和决策支持。
基于Kotlin Multiplatform的鸿蒙跨平台开发实践
为了提供更好的用户体验,支持更多的应用生态,哔哩哔哩在去年年底启动了哔哩哔哩鸿蒙原生应用的开发。
漫谈SDL之三方库漏洞检测与运营
第三方组件具有开放、共享、自由等特性,在软件开发中扮演着越来越重要的角色,也是软件供应链的重要组成部分,它的使用大大提高企业中软件研发的效率、缩短上线时间,能有效降低开发成本。但这些组件,可能会存在一些安全问题,所以对开发使用的这些组件进行监控,是很有必要的。之前我们写过一篇文章《漫谈SDL之三方库漏洞检测与CICD》,文章介绍了如何在CI/CD流程中接入第三方组件漏洞检测工具。紧接上一篇文章,再介绍一下我们使用的检测工具的检测原理以及后续漏洞修复的运营工作。目前我们公司使用的是自研第三方组件检测工具,现在整个工具正处于起步阶段,所以这篇文章也是起到一个抛砖引玉的作用,欢迎大佬们来分享交流关于第三方组件漏洞检测工具的见解。
漫谈SDL之三方库漏洞检测与CICD
最近有小伙伴在做落地、推动三方包漏洞检测时遇到了一些问题:与devops工具侧同学以及业务线研发同学沟通时,存在双方不理解对方表述,鸡同鸭讲的情况。
解答了几次相关问题后,发现这些问题有一些共性:都会涉及到研发流程、CICD、工程化的一些点,比如CICD具体是哪些,commit、build这些阶段是属于哪个阶段,具体是什么含义,哪个是合适的安全检测触发点,有实现安全左移么?工具侧同学说的gitlab-ci、runner、.gitlab-ci.yml、pipeline又是什么,安全检测与这些又是什么关系等等)。这些知识对安全同学一定程度上来说是陌生的,但又是研发安全在企业里落地推动时的基础。在网上查到的资料一般是对于这些名词概念的单独描述,并没有与安全结合。所以稍作整理,或许可以提供参考价值。