推荐系统通常由多个阶段组成，比如，有的推荐系统分为Recall、PreRanking、Ranking、ReRanking等四个阶段。在爱奇艺，我们的推荐系统在非常多的场景中都有应用，推荐的内容也不尽相同(如长视频、短视频、主题、影人等)。但是万变不离其宗，在这些场景中，推荐系统的核心工作方式有一定的共性。为节约开发成本，同时也要保障不同场景下推荐系统的稳定性，我们将不同推荐场景排序模型中相似的部分成体系地提炼出来，并加以标准化、组件化，进而针对推荐场景排序问题提供了通用化的解决方案。这也是我们提出爱奇艺通用排序框架的初衷。目前这一框架已经在爱奇艺多端多个场景落地——长视频推荐：主APP首页猜你喜欢、TV端首页猜你想看，短视频推荐：主APP短视频播放器，长短视频混合推荐：主APP频道页瀑布流、TV端首页Feed等。正所谓，推荐的复杂性如黑夜迷雾，希望能破晓见黎明。

国际站后端业务不断扩展，支撑的服务实例规模也越来越大。并且在此过程中，支持了双云及多地部署。

基于需求粒度的精细化代码测试覆盖率的探索实践。

希望借本文跟大家分享爱奇艺移动实验室在【iOS稳定性测试】实践和优化过程中的心得和体会。

从埋点的定义、规范以及数据质量要求开始，介绍爱奇艺在治理埋点数据、提高埋点数据质量工作中的一些实践经验。

如何平衡？SourceMap正是解决这个矛盾的利器。

面对不同原因的数据异常，从监控角度我们怎么去管控呢？

本文分享了爱奇艺深度学习平台在实践中发现的两个TensorFlow Serving内存泄漏问题，并修复和提交了 PR 到社区，这里将详细介绍问题的背景以及解决的过程，希望能够有所帮助。

最终实现了分钟级自动调度，且链路可用率从99.524%提升到99.9999%。

针对现有Cloud KMS进行二次封装，将数据加密和密钥管理与业务运行相结合，有效提升了会员数据的安全性。

本文将详细讲解爱奇艺TV后台分布式实时本地Cache实践方案，给大家解决高并发问题提供一个参考。

本文将介绍爱奇艺移动端后台如何通过灰度环境优化解决以上的问题。

APP DIFF方案利用deeplink、mock提升了UI自动化稳定率和效率，并结合AUI图像匹配算法，达到接近人工的验证效果，在收藏、card等业务推进落地，以较低成本持续产生收益，在移动端UI自动化方向实现了突破与创新。

随着互联网公司的产品和业务越来越多样，利用数据来驱动业务决策成为必然，而AB实验正是以数据指标来判断产品功能和运营策略迭代效果的方法和工具，其可以在保证样本同时性和同质性基础上，对比两个或多个实验组在同一应用场景下的效果。

随着深度学习浪潮的兴起，embedding技术也随之快速发展。embedding自身表达能力的增强使得直接利用embedding生成推荐列表成了可行的选择。因此，利用embedding向量的相似性，将embedding作为推荐系统召回层的方案逐渐被推广开来。我们在了解了embedding生成的常用算法模型之余，对于推荐系统的实现而言，了解其工程化实践也非常重要，本文将介绍在线向量召回服务在爱奇艺的工程化实践。

我们都知道日常开发的Android App是运行在Java虚拟机的环境中，Java虚拟机会自动进行垃圾回收（garbage collection，以下简称gc），但gc发生时有可能会造成一定程度的卡顿，而Java大内存对象的创建更易引发gc，对应到Android中即Bitmap对象，所以需要尽可能的减少新Bitmap的创建。

在Android 8.0及以上版本，Bitmap的数据是存储在native内存，创建Bitmap不会影响gc。而Android 3.0-7.1版本上，Bitmap的像素数据(byte[])是存储在java堆中的，一张500*500 ARGB8888格式的图片，其内存占用约为1m，如果频繁地创建和销毁Bitmap很容易引起gc，造成页面卡顿。

Android有提供inBitmap机制，来复用不再使用的Bitmap，但是，如何方便地收集不再使用的Bitmap，如何高效的存储管理收集的Bitmap，Android并没有提供系统的解决方案。

基于这些问题，本文提供一套高效的图片复用方案，此方案只需配置较低的内存缓存，即可达到很高的图片复用率，从而有效减少图片相关的gc。