从23年开始，我们团队开始前端错误监控方向的开发。经历了一些列的迭代和发展，从监控SDK、上报、数据治理、看板集成、APM自研可视化初步完成了一条完整且适合B站前端监控。 截止目前(2024.08.01)，前端监控在B站85%以上的业务线，1700+项目中运行。今年初APM平台的落地接入了210+的项目，5月新推出的一键告警配置功能也达到了300+。
Index-1.9B-32K 是一个拥有 1.9B （19亿）参数并具备 32K 上下文长度的语言模型（这意味着，这个超小精灵可以一次性读完 3.5 万字以上的文档）。 在多项长文本评测任务中，该模型在相近尺寸的模型中表现突出。以极小的体积和算力开销（仅仅约为 GPT-4 的 2%），实现了出色的长文本处理能力。
在当下的直播业务中，实时音视频交互已经变成主播与主播，主播与用户之间的主要交流模式。 为了满足用户间互动的需求，B站提供了多种实时互动类产品，比如:语音聊天室，连麦连线，视频PK等功能。 但长期以来因为业务与技术快速发展，团队组织不停变革，系统技术债务不断积累等原因，导致不同互动业务间普遍存在能力重复建设,数据孤立等问题。 同时现有的技术架构已经无法满足我们的需求，作为互动业务负责团队，我们希望通过对互动中心进行平台化架构升级，来融合各种互动业务，降低系统复杂度同时提升系统性能。 以此提高交付效率来更好适应需求变化。
B站直播平台近年来迅猛发展，为了吸引更多观众和优质主播，直播平台通常会推出多样玩法（包括节日活动、任务、榜单、抽奖），以激励用户参与和创造高质量内容，拉动平台营收，丰富直播生态。诸多玩法都存在一个共同的场景：给用户发放奖励。为了满足奖品种类以及发放场景的多样性，我们设计了通用奖励系统，用于支撑各类上层业务。本文将介绍直播奖励系统的技术架构，从需求分析到实现细节，全面解析其背后的技术方案。
直播业务具有实时性强，复杂度高，排查链路长，影响面大等特征，线上问题如果不能立刻排查处理，分分秒秒都在影响用户的观看体验、主播的收入。 但各端的问题可能都只是表象，例如，一个看似简单的画面卡顿问题，可能涉及到编码器配置、网络带宽分配、服务器负载等多个方面，各个团队经常在等待合作方的反馈，一整套流程下来，一个线上问题的定位可能要消耗掉数小时的人力。 我们迫切的需要一套高效的跨端实时排障系统！
PC直播姬中的直播素材之一——投屏源可与安卓或iOS移动端应用（直播姬、粉版）配合使用，将移动端画面投射到PC直播姬中。投屏源最初仅支持无线投屏，即通过局域网 WiFi传输，但这样的链路会受到网络质量影响，而且如果Windows计算机和移动设备不在同一网段或者配置了局域网隔离，那么就无法投屏成功。 无线投屏的这些缺点，使用USB有线投屏即可克服。本文基于Windows平台，介绍计算机与安卓/iOS通过USB交换数据的实现方式。
2023年8月中旬文档画中画特性跟随chrome116版本发布，基于该功能特性，我们于2023年10月中旬启动了B站跨页面播放队列功能的开发与功能灰度，并于2024年6月中旬完成了灰度全量。目前该功能入口位于B站网页端的首页，点击首页右侧对应按钮即可打开跨页面播放队列小窗。队列中的视频为稍后再看列表中的视频，在小窗开启情况下，该列表内容会实时响应B站主场景网页中的添加/移除稍后再看操作。
视频场景分类算法是计算机视觉领域研究的热门内容，并作为复杂任务系统的前置算法，能够应用于我们多媒体实验室多项业务，如内容自适应转码、画质智能修复和视频质量评估（VQA）中。通过针对不同类型的图像自适应抉择不同的模型，从而精准有效提升算法在业务中的实际效果。语言、视觉是人类感知世界最基本的方法，也是人工智能理解世界的两大支柱。多模态是结合了图像、文本、音频等多种数据类型的一种技术方案。该技术不仅提高了模型的泛化能力，还扩展了人工智能技术的应用方向，如图像分类、图像问答、文本图像生成等。本文研究了多模态算法在多媒体系统中进行场景分类的应用，探讨了实施过程中的挑战并给出对应的解决方案。
OLAP场景是大数据应用中非常重要的一环，能够快速、灵活地满足业务各种分析需求，提供复杂的分析操作和决策支持。B站主流湖仓使用Iceberg存储，通过建表优化可以实现常规千万级的指标统计秒级查询，这样就能快速搭建可视化报表，但当数据量达到亿级、需要交叉分析维度复杂多表情况下，想要支持秒级就变得困难。因此B站数据分析或者数据开发同学为了能有秒级响应的报表，需要通过ETL grouping sets 提前设计要参与多维分析的维度和指标，然后在ADS层离线计算好对应的数据cube。这有点类似Kylin的预计算模式，区别是查询效率和查询SQL复杂度要更高，毕竟Kylin底层是KV存储并且做了SQL解释器，而原始grouping sets模式得让下游自己选cube切片。比如Push业务DWB表几十亿数据量，想要快速支持十几个维度和十几个指标秒级交叉分析，只能开发提前配置好要参与分析的维度组合，在可视化界面也需要提前说明只支持这几个维度组合。
在 2023 年的华为开发者大会（HDC）上，华为预告了一个全新的鸿蒙系统 Harmony Next 版本。与之前的鸿蒙系统不同，Harmony Next完全摒弃了对 AOSP 的兼容，彻底基于 OpenHarmony 开源鸿蒙实现。这意味着该系统将仅支持鸿蒙原生应用，Android 应用将不再允许在其上运行。 华为用户在哔哩哔哩的用户生态中一直占据着较大的比例。为了提供更好的用户体验，支持更多的应用生态，哔哩哔哩在去年年底启动了哔哩哔哩鸿蒙原生应用的开发。在对 Harmony Next 系统进行初步调研后，我们发现其从开发语言到运行环境到开发方式，都与 Android 平台完全不同。适配 Harmony Next 就意味着重新开发一个独立的 App 端，无论是短期开发还是长期迭代，这都是一件成本极高的事情。于是我们面临一个问题：是否有跨平台开发的手段来复用现有生态的代码，从而减少开发成本？
