背景

APP推送是触达用户的一个非常重要的手段，对于提高产品活跃度、提高功能使用体验、提升用户粘性、提升用户留存率都会起到重要作用。伴鱼旗下多款APP，支持丰富的用户交互体验，对推送的依赖上表现的尤为突出。随着公司业务的快速发展，伴鱼旗下的app也在与日俱增，对推送场景的需求也开始多样化，推送量的需求更是飞速增长，这些都对伴鱼推送平台提出了更高的要求。本文就伴鱼推送平台在实践中遇到问题的思考以及相应的技术方案进行详细说明，以期给读者带来一些思考以及解决类似问题的思路。

推送平台通常会遇到的问题，在伴鱼这里也都同样遇到，最具有代表的问题：

• 高吞吐。推送巨大的流量如何支撑，尤其在运营集中做活动时候表现的尤为突出，动辄是千万量级 亦或是亿级别的量级，怎么能够很好的支撑？
• 低延迟。推送任务要能以最快的速度让用户收到。运营集中做活动的时间很短，要在这有限的时间内，尽可能快的触达用户。

同时伴鱼推送平台也遇到了我们业务特有的推送问题：

• 多客户端推送。伴鱼旗下的诸多app，在业务上有着强的关联关系，业务上的同一功能可能要给多个app下发推送，比如：家长都很关心学生的学习情况，学生若在学生端获得一个奖励，需要推送学生端，也需要及时通知家长端
• 多种推送场景。伴鱼诸多业务中比较突出的有三种场景的推送，一种是业务实时推送，在线课堂的交互实时推送就是比较典型的示例，这类推送用户多为在线用户，推送时效性要求很高，否则会影响用户的上课体验；一种是类似站内信的系统通知，这类推送用户多为离线用户，推送消息可靠性很高；一种是营销推送，这类推送用户多为离线用户，可靠性要求没有前两种高。第一种场景的流量曲线跟业务高峰期的曲线相同，每天量相对稳定，后两种场景流量是典型的脉冲式流量，有推送时流量会瞬间陡增。
• 推送相互隔离。推送平台是面向伴鱼所有业务线的，不能因为某个业务线的推送量过大，影响到别的业务的使用，如何能够按业务隔离，按推送类型隔离？

带着这些问题我们技术中台协力打造了一个高吞吐、低延迟、多业务隔离的的伴鱼推送平台

随着伴鱼业务的快速发展，公司内部越来越多的业务团队希望通过更加科学的 AB 实验( 以下简称「实验」)来进行产品方案的决策。起初公司 AB 平台(以下简称「平台」)的技术方案参考借鉴于 google 论文以及业界分享的实践案例，详细设计和实现可参阅：AB 测试平台的设计与实现。平台上线后，通过不断收集用户的使用反馈，总结试验周期内各环节存在的问题，我们归纳出平台下一步需要重点改进的方向，主要包括：

• 支持客户端的接入渠道：前期只提供了服务端实验的接入渠道，客户端的实验接入成本高。
• 统一收敛分流逻辑：定向实验的流量过滤逻辑散落在接入方的业务代码中，一方面增加了业务接入的成本，另一方面过滤条件也难以在平台进行直观展示。
• 优化分流及存储方案：提供多样化的分流方式，摒弃持久化的存储方案，解决同层实验饥饿现象。
• 打造平台数据闭环：从业务方提出实验需求到进行实验再到结果分析，整个链路的数据都能够在平台上做到统一流转，避免一对一的线下沟通，减少人力成本，提升用户体验。
• 优化实验结果表达：基于统计学原理，对各项实验结果进行科学的数据分析，并给出相应的量化指标，真实准确地反映实验效果。
• 支持事件通知机制：实验周期内的关键节点通知责任人，做到实验报告生成、实验关闭等事件的及时感知。
• 开放 API 能力：支持业务系统快速创建实验，降低人力成本。

为此，我们结合业务特点，对现有的框架进行了重构。目前新版平台已经上线投入使用。

引言

各大知名互联网公司都自己的职级体系，现在越来多的公司开始意识到建设职级体系是一件重要的事情，那么作为一家公司我们应该怎样建设自己的职级体系？是直接在网络上找 Google、Facebook、百度或者阿里的职级体系，稍微修改一下变成公司的职级体系，还是根据公司的情况重新设计一份职级体系？

我觉得这个问题的答案不在问题本身，需要要深入这个问题的本质去寻找答案，那就是职级体系是干什么的，它能给公司带来什么价值？如果能回答这个问题，那我们对怎么建设自己公司的职级体系将不再有疑惑了。

下面我们通过伴鱼对职级体系这个主题的思考，以及伴鱼职级体系的设计理念来回答这个问题。

职级体系应该是公司人才观的事实标准

所有的公司都宣称渴望优秀的人才加入，但对优秀人才的标准则很少谈起，其实人才的能力模型是多种多样的，每一个公司对于优秀人才的定义可能都不尽相同，这会导致公司招聘出现问题——招聘到优秀但是不合适的人才；也会容易让员工出现怀才不遇的困惑——我明明拥有出色的能力，但是在公司好像并没有被重用。

在伴鱼发展早期，四端的系统发布实践比较简单、直接：web 端直接登录线上机器替换静态文件；服务端所有项目共用一个仓库，直接利用脚本部署不同仓库子目录到固定机器，并且在发布的时候才尝试解决代码冲突；移动端从打包到发版流程基本靠手动保证。尽管比较粗糙，但是在公司早期人员少、产品迭代频繁的大背景下，这些实践方案的确起到很大的作用。

随着公司业务逐步稳定，技术团队扩张，早期的发布实践方案逐渐暴露出问题：

• 直接登录线上机器替换文件是高危操作，运维团队也开始逐步收回所有主机访问权限
• 服务端共享一个仓库，一个 go.mod，随着人员增加，代码冲突的概率也呈指数增加
• 各端都有公共基础代码，这些基础库的版本控制、灰度控制问题需要各自解决
• 测试环境需要支持不同泳道，生产环境中需要新增预发布环境，方便测试人员回归、冒烟
• 生产环境除了全量发布，还需支持灰度发布，以减少新版本的影响范围，保证服务质量
• …

一个统一各端的发布系统呼之欲出，这便是技术中台各组通力协作，共同打造的东风发布系统。目前东风发布系统已经逐步接管各端的日常发布需求，成为伴鱼全体研发每天都需要访问的系统之一。

一、背景介绍

项目背景是在界面中弹出一个浮层动画，同时播放一个音效。

二、当前实现

实现思路比较简单：继承一个DialogFragment，在相关的生命周期方法onViewCreated中调用startLottieAnim进行动画播放，同时监听lottie动画播放的回调事件，在动画开始播放时播放音效文件；动画播放结束时关闭DialogFragment。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

private void startLottieAnim(String assetFolder, final Uri voiceUri) {
    lottieAnimationView.setImageAssetsFolder(assetFolder + "/images");
    lottieAnimationView.setAnimation(assetFolder + "/anim.json");
    lottieAnimationView.setRepeatCount(0);
    lottieAnimationView.addAnimatorListener(new Animator.AnimatorListener() {
        @Override
        public void onAnimationStart(Animator animation) {
            playAnimVoice(voiceUri);
        }

        @Override
        public void onAnimationEnd(Animator animation) {
            stopAnimVoice();
            dismiss();
        }

        @Override
        public void onAnimationCancel(Animator animation) {
            stopAnimVoice();
            dismiss();
        }

        @Override
        public void onAnimationRepeat(Animator animation) {
            playAnimVoice(voiceUri);
        }
    });
    lottieAnimationView.playAnimation();
}

一、背景介绍

目前公司的Android项目都使用了WebP插件进行图片的优化。该插件主要是在线上打包系统进行build时才会进行的一个图片优化的动作。通过将PNG图片转换成webp格式减少包体积大小。目前最新的插件版本是1.0.4

二、当前WebP插件的实现

插件的实现机制比较简单，主要是通过三个Gradle Task来完成：

1. DownloadLibTask
   从https://storage.googleapis.com/downloads.webmproject.org/releases/webp/下载对应操作系统的webp工具包。
2. DecompressTask
   将下载的压缩包解压到特定目录
3. ConvertTask
   在对drawable资源遍历过程中，使用cwebp命令行工具，对其进行格式转换

   1	cwebpPath + " -q " + getQuality() + " " + srcFilePath + " -o " + dstFilePath;

简介

本文介绍伴鱼内部服务报警平台中匹配器模块的演进，及其利用 Lex 和 Yacc 同类工具构建 DSL 编译器的过程。

背景

报警平台是伴鱼内部各端、应用、基础设施等服务异常状态信息的集散中心。整体流程如下图所示：

背景介绍

因为Android设备的种类繁多，屏幕的尺寸也是五花八门，结果同一个设计方案在不同的设备上的显示效果就会有所差异。所以，就需要对不同的设备做适配，以获取在不同尺寸的设备上有相同显示效果的能力。

引入一个公式

• 像素：px，物理单位，一般系统设备上显示的尺寸如：1280X768用的就是像素单位；
• 设备独立像素：dp，一般以dp为尺寸单位的控件；
• 像素密度：dpi，指的是在系统软件上指定的单位尺寸的像素数量，它往往是写在系统出厂配置文件的一个固定值。

这里要注意的是，dpi都是软件意义上的单位，在特定的机型上它是系统软件上的一个配置项，并不是一成不变的，是可以修改的。下面要说的“今日头条方案”就是基于修改这个值来实现的。

Android系统上一块屏幕上像素的个数和DP的数量之间有个对应关系：

引言

千里马常有，而伯乐不常有，优秀人才不会畏惧工作的挑战，但是会沮丧于不能实现自己的价值，一个设计良好、公开、公平、公正的上升通道是将伯乐的工作流程化和制度化，让伯乐无处不在，这对优秀人才的吸引力是巨大的。所以，从某种意义上说，上升通道是一个公司、组织乃至社会最关键的机制之一，它从各个方面影响公司、组织和社会的发展与进化。

举一个大家耳熟能详的例子，美国梦从狭义来说其实描述的是美国社会的上升通道是开放的，能让有才能的人脱颖而出实现自己梦想，从而不断吸引着一批又一批优秀的人才不惜远渡重洋移民到美国的故事，这也正说明了上升通道对于人才的吸引力和对于一个国家发展的重要程度。

对于一个公司来说，上升通道就是公司的晋升机制，下面从晋升机制的意义、流程，以及怎么来保障晋升机制的公开、公正和公平等方面来阐述伴鱼对于晋升机制的思考和设计理念。

晋升机制对于员工和公司的意义是什么？

现在几乎所有的公司都开始意识并且强调招聘的重要性，但对于晋升机制的重视程度是不够的，其实对一家公司人才资源的影响，晋升机制的重要程度是不亚于招聘的。优秀人才可以选择的机会是非常多的，如果不能给他们提供一个设计良好的上升通道，那么离开就变成了一个很好的选择，反之，如果公司提供了一个设计良好的上次通道，那么对招聘也是一个很好的支撑和帮助。

本文介绍 FB 基于 memcached 构建统一缓存层的最佳实践。全文递进式地讲述 单集群 (Single Front-end Cluster)、多集群 (Multiple Front-end Clusters)、多区域 (Multiple Regions) 环境下遇到的问题和相应的解决方案。尽管整个解决方案以 memcached 为基本单元，但我们可以任意地将 memcached 替换成 redis、boltDB、levelDB 等其它服务作为缓存单元。

在下文中，需要注意两个词语的区别：

• memcached：指 memcached 源码或运行时，即单机版
• memcache：指基于 memcached 构建的分布式缓存系统，即分布式版

Background

与大部分互联网公司的读写流量特点类似，FB 的整体业务呈现出明显读多写少的特点，其读请求量比写请求量高出若 2 个数量级 (数据来自于 slides)，因此增加缓存层可以显著提高业务稳定性，保护 DB。