ITPub博客

在 iOS16 上，苹果推出了实时活动( Live Activities )。实时活动可以出现在用户锁屏界面，并可实时展示用户关心的一些核心信息。由于使用远程推送通道更新实时活动不需要主 app 保持开启，并且相比小组件需要用户手动添加到桌面这个门槛，实时活动功能是默认开启的，所以这一机制保证了信息的触达概率会远高于小组件。

随着自动化测试左移实践深入，越来越多不同类型的需求开始用自动化测试左移来实践，在实践的过程中也有了新的提效诉求，比如技改类的服务拆分项目或者BC流量拆分的项目，在实践过程中，这类需求会期望不同染色环境在相同的配置条件下，拆分后的代码和基准release代码的接口响应response有全量对比结果才能更好达到需求验证点。

滴滴网约车致力于让出行更美好，平台为司乘提供良好体验的同时承载了广大群众的出行服务，致使我们对服务可用性的要求较高。更快地发现系统bug，可以让更少的司乘用户受影响。发现bug的能力更精细，可以让一些不易被用户感知但实际影响用户产品使用的bug更容易被发现。网约车服务端承接了网约车核心交易流程整体链路串联工作，其涵盖交易场景达百万级别，核心交易链路涉及几百个下游服务调用，这对我们的质量保障工作有了更高的挑战。本文提出了测试流量触发与测试结果分离的思想，并基于该思想做了两次实践，分别是在线上以更快召回代码bug为目标的线上流量巡检，在线下以提高测试效率为目标的测试流量验收。

机器扩容后瞬间被高流量击穿，背后发生了什么？本文从实际案例入手，探讨在冷启动的场景下如何保护系统不被瞬间流量压垮。

B站游戏中心是一个游戏分发平台，它提供游戏下载、游戏评测、游戏攻略和游戏活动等相关内容，用户可以在这里找到各种优秀的游戏作品，预约测试，下载资源，以及参与游戏社区的互动。游戏中心首页如图1-1所示：

1 背景 2 设计思路 2.1 将"可变"的配置化 2.2 将"不变"的系统化 3 实现细节 3.1 速度控制 3.2 资源分配策略 3.3 问题解决 4 上线效果 5 总结

网约车业务作为滴滴的核心业务，系统架构复杂、整个订单链路涉及众多下游服务，整体迭代频率高，同时在产品形态上通过不同品类提供差异化服务能力，整体品类从最初的专车、快车延展到如今多个品类，这就导致在日常的功能迭代中需要实现特定品类场景或者特定功能测试的成本非常高。举几个典型的例子：

随着业务日益复杂，应用微服务化已成为主流趋势，业务领域通常在多个微服务应用中实现。DevOps 工程从应用角度，虽实现了应用流水线和项目流水线，但也面临着测试阶段管理多套应用流水线的复杂场景。通常情况下，这些业务会存在多套互相隔离的环境，而这些环境的构建也依赖人工处理资源申请和部署。由于构建不易，这些环境通常被长期反复使用，并需要定期与生产环境同步以确保开发和测试的有效准确。这些工作要求工程师对业务的应用架构熟悉且有时间频繁进行操作，但实际上这些工作大多落在项目资深的 DEV 或 QA 身上，浪费了宝贵的人力资源。因此，我们可以考虑建立“环境构建平台”，实现环境即用即建，让 DEV 和 QA 专注于自己擅长的事情，并最终节约人力资源提升效率。Qunar 的基础平台团队对此问题进行了长期实践，本文将分享 Qunar 在测试环境治理领域的实践经验和思考。

希望大家通过阅读本文之后可以打造属于自己的前端监控系统用来保证自己应用的用户体验

CAS单点登录技术是一种用于解决多个应用程序之间身份验证和授权问题的集中式认证系统。它通过引入认证中心，实现了用户只需登录一次即可访问多个应用程序的便利性和安全性。CAS单点登录技术的优势在于集中管理、安全可靠、可扩展性强等特点，使其成为企业和机构身份管理系统中的首选解决方案。本文尝试通过一种深入浅出的方式，通过解析笔者亲身案例给读者分享CAS架构开发所需要关注的技术点。

百度APP iOS端包体积优化系列文章的前三篇重点介绍了包体积优化整体方案、图片优化和资源优化，图片优化是从无用图片、Asset Catalog和HEIC格式三个角度做深度优化，资源优化包括大资源优化、无用配置文件和重复资源优化，本文重点介绍代码优化，在百度APP实践中，代码优化包括无用类优化、无用模块瘦身、无用方法瘦身、精简重复代码、工具类瘦身和AB实验固化。在代码优化过程，需要分析Mach-O和Link Map，在前面的文章我们已经针对Mach-O文件做过了分析，本文先介绍Link Map文件，然后再详细介绍代码优化方案。

在过去的十年里，移动端技术飞速发展，移动应用逐渐成为主要的便捷访问和使用互联网的方式，承接了越来越多的业务和功能，这也意味着对移动端和服务器之间的通信效率和稳定性提出了更高的要求。为了实现更高效的实时通信和数据同步，长连接逐渐成为一种关键技术，通过维持客户端和服务器之间的持久连接，实现了双方实时数据交换，避免了频繁的建连和断连开销，从而提高用户体验、服务稳定性、可靠性等方面的表现。

在去年，正式上线了对N品类的质检能力。质检中心也有一套标准可以来拓展越来越多N品类，实现用户闭眼打包寄卖，在系统维度上可以认为转转官方验没有不能质检的品类。

目前，前端平台探索大仓研发模式，通过Monorepo大仓的技术，整合前端平台现有应用的仓库代码，使得各业务域应用质量衡量标准统一，通用基础组件以及工具函数能够快速复用，当基础通用功能出现问题的时候，能快速地在各应用中升级，提升研发工作效率，节省人效。

搜索慢慢的被大模型渗透，那么很自然很多人想到了推荐，但是推荐是不是真的可以被大模型渗透呢？大模型能改变推荐的范式吗？

在电商场景的日常导购过程中，大家都比较熟悉的是，各大电商往往会在各种导购场景的用户操作路径上有不断获得权益的领取机会，这些机会根据用户的路径和行为习惯综合考虑，从电商平台侧甚至商家侧从补贴成本综合考虑权衡之后，会主动给用户在导购操作路径上寻找比较容易流失的机会点，主动派发领取补贴权益的机会，进而加强用户操作的欲望，避免用户流失，最终激励用户尽可能快地达成交易。

Java虽然在市场份额占比巨大，但是在万物云原生下，因它启动时长，资源消耗较大，不易水平扩展等方面都成为了明显的短板，导致市场份额也逐渐减少。而GraalVM弥补了这些缺陷，本文将从实战方向带你打开，原生镜像之路。

重点介绍了Redis的LRU与LFU算法实现，并分析总结了两种算法的实现效果以及存在的问题。

语音识别技术，是将语音信号转换为文本内容的技术。目前比较流行的语音识别技术主要有两种。一种是基于Kaldi的传统语音识别技术，另一种是目前流行的基于深度学习模型的端到端语音识别技术。Kaldi是一种大而全的语音识别处理框架，集成了数据预处理、特征提取、声学模型建模、语言模型建模、解码等，识别效果上能够满足大多数的语音识别场景。但是Kaldi是自成一体的框架，没有现在流行的pytorch、tensorflow框架的支持，需要开发者自行开发能应用到生产环境中的服务。基于深度学习模型的端到端语音识别框架是指将语音信号直接输入到深度学习模型中，通过端到端的方式进行语音识别，无需使用传统的声学模型和语言模型，常见的基于深度学习的端到端语音识别框架有很多，比如EspNet，WeNet等，这类语音识别框架有更通用的模型训练和部署框架支持，有着更好的识别性能和识别效果。

客户端崩溃治理长效机制是一套系统化的方案，属于基础架构可观测性指标的一部分，用于对客户异常崩溃、卡顿、错误等快速发现、第一时间预警提醒、快速协助定位分析，从而帮助开发人员快速及时发现和解决客户端相关问题，从而提高用户体验，保障业务服务高可用，减少因使用过程中出现异常而导致的用户流失，提升品牌技术价值。