知鸦日报2021-08-20

如何从不同的生命周期进行用研重点拆解？除市场上比较通用的生命周期拆解外，不少公司内部会有一套更加适配业务的体现生命周期的分层。

在直播这个大趋势下，垂类平台可以怎么利用这个趋势来撬动用户，进行商业化。

在「打卡」社交充斥着生活的今天，原本鲜有人知的事物也有了在一夕之间被人们刷爆朋友圈的可能。但是，可能也有前提——良好的用户体验。

良好的用户体验意味着你与消费者接触的每分每秒都应当是令人满意的吗？

答案是否定的。举个例子，那些充斥在社交网络中的必打卡点总是能吸引到许多顾客，而当他们真正前往体验时，却会发现并不如想象中那么完美。

可是，消费者们却仍乐此不疲地分享着，是什么让他们对这段不完美的体验津津乐道？

随着严选业务、渠道的不断扩展，活动玩法千变万化，商品价格计算愈发复杂。原来的价格计算体系已无法快速有效的支撑新增玩法，需进行促销计价系统的独立建设，与交易、商城业务解耦。

一个较大的业务或系统改动，往往会影响整个产品的用户体验或操作流程。为了控制影响面，可以选取一批特定用户、流程、单据等，只允许这一部分用户或数据按照变更后的新逻辑在系统中流转，而另一部分用户仍然执行变更前的老逻辑。

随着深度学习浪潮的兴起，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。

我们的供应链场景有很多供应商，每个供应商都有物流、资产、仓储等多个域，而这些域我们的后端都基于 DDD 领域模型做了微服务化，此时前端在开发面向这些供应商使用的中后台应用时，遇到了以下问题：

页面显示需要请求多个域：比如一个商家的详情页，可能既需要请求仓储数据，还需要请求资产数据，才能将一个页面显示出来。

接口格式不满足前端需求：后端微服务化后，是面向多项目，通用性的，其接口格式不一定能满足前端需求，前端需要自己做转换，比如单位转换，字段裁减。

需求变化快：业务在快速迭代，需要接口的大量支持，而我们的后端域是面向多项目的，更改成本较大，需要投入更多的测试，此时如果在前端和后端中间存在一个中间层，来做这些事情，那么效率会有比较好的提高。

部门协作成本大：有些需求需要其它部门的后端同学支持，而其它部门的同学因为自己部门的需求紧张，排期较满，导致我们的需求迟迟无法排期，此时如果存在一个中间层，在中间层去请求其它部门提供的领域服务来组合数据提供给前端，此时就可以在其它部门同学不参与的情况下，前端自己完成需求开发，部门之间的协作成本会大大降低。

基于以上背景，前端这边引入了 BFF 架构，BFF 架构能做哪些事情：

业务编排：从后端域多接口获取数据合并输出给页面。比如一个商家详情页即需要仓储数据，也需要资产数据，此时我们在 BFF 层将仓储和资产数据请求回来组装吐给前端。

字段转换：字段过滤、数据格式化等工作。比如资产域的商户名字段叫 businessName，而仓储域的商户名字段叫 shopName，此时可以在BFF层统一掉，这样前端就不需要做判断了。

个性化数据：为前端提供个性化服务，如数据压缩，单位转换等。

Content quality is critical to the support experienced by Uber’s customers. Consider an Eater who reached out for help to cancel a very delayed order. The same resolution, such as refunding the charge, can be delivered alongside a robotic-sounding message, or one where the style and tone of the response conveys true empathy and acknowledges the user’s poor experience on our platform.

As the natural expression of the support experience, and a bearer of brand promise, support content affects how people feel, and plays a major part in how they perceive the Uber brand. In addition, support content plays the role of educating users about the product behavior and about our policies while moving them to action. Finally, support content (such as knowledge base articles) also serves to deflect commonly asked questions and reduce the number of contacts handled by our agents. In short, support content is what a disgruntled customer first sees, and hence it is imperative that this content can placate and soothe the customer, whilst also resolving the core issue, transforming customer ire into customer delight.

Uber’s Customer Care platform currently supports content across different business verticals including Uber Mobility (Rider, Driver), Uber Delivery (Eater, Courier, and Merchants), Uber For Business (Organizations and Employees), Uber Freight (Carrier, Shipper), etc.

In this blog post series, we’ll discuss Pinterest’s Analytics as a Platform on Druid and share some learnings on using Druid. This is the first of the blog post series with a short history on switching to Druid, system architecture with Druid, and learnings on optimizing host types for Mmap.

Reinventing how the world does work inevitably creates a lot of data. Each year, Slack’s scale has increased and the volume of data ingested and stored has kept pace. To make it possible to understand relationships within our data, we’ve invested heavily in an automated data lineage framework. This facilitates producer/consumer coordination, improves risk mitigation, impact analysis, and better execution of data programs here at Slack.

熟悉Apache Kafka的同学都知道，当Kafka集群负载到达瓶颈或者出现突发流量需要紧急扩容时，新加入集群的节点需要经过数据迁移才能均分集群压力。而数据迁移会因为数据堆积量，节点负载等因素的影响，导致迁移时间较长，甚至出现迁移不动的情况。同时数据迁移也会增大当前节点的压力，可能导致集群进一步崩溃。本文将探讨应对需要紧急扩容的技术方案。

美团的各个业务有着丰富的NLP场景，而这些场景中模型的构建需要很多的标注资源，成本很高。小样本学习致力于在数据资源稀少的情况下训练出比较好的模型。本文从主动学习、数据增强、半监督学习、领域迁移、集成学习&自训练几个方向介绍了现有的一些方法，并在美团场景进行了实验，效果上也取得了一定的提升。希望能对从事相关研究的同学有所帮助或者启发。

随着应用不断的迭代更新，目前端上的线程池设计已经无法满足需求，包括不限于网络请求、本地db操作、业务轮询等任务容易导致线程队列堆积，最终造成“操作卡顿”现象。本文章通过线程分离、轮询统一、线程监控等手段解决了大部分线程阻塞难题～

WebRTC 进行端对端进行实时音视频通讯时，常常一方或者双方都是隐藏在 NAT 之后的内网地址。ICE 则用于寻找一条传输数据通道连接。本文介绍了 NAT 穿越和 ICE 框架的基础知识和主要步骤。

本文整理自火山引擎开发者社区 Meetup 第四期同名演讲，主要为大家介绍了为什么要做 A/B 测试、火山引擎 A/B 测试系统架构及最佳实践。

这篇将重点介绍前台展示逻辑，主要从客户端的角度阐述自定义布局如何从数据解析到界面渲染，最后完成内容更新。

在庞大的数据系统中，往往会有大量的计算需求。传统的方式便是直接在代码写各种计算逻辑判断，这导致了代码非常臃肿，计算维护的成本变大。所以想着编写一套DSL，定义专用的语法去实现对数据的计算，并将其独立成为底层基础服务。

随着 Android App 开发的技术栈不断向 native 层扩展，native hook 已经被用于越来越多的技术场景中。Android native hook 的实现方式有很多种，其中使用最广泛，并且通用性最强的是 inline hook 和 PLT hook。

inline hook 的功能无疑是最强大的，它受到的限制很少，几乎可以 hook 任何地方。inline hook 在线下场景中使用的比较多，业内现有的通用的 inline hook 开源方案或多或少都存在一些稳定性问题，而且基本都缺乏大规模的线上验证。

PLT hook 的优点是稳定性可控，可以真正的在线上全量使用。但 PLT hook 只能 hook 通过 PLT 表跳转的函数调用，这在一定程度上限制了它的使用场景。

在真实的线上环境中，经常是 PLT hook 和 inline hook 并存的，这样它们可以各自扬长避短，在不同的场景中发挥作用。

数据指标，并不是数据分析和业务同学的专属模块。日常会用到数据指标的，还包括开发(比如机器资源利用率，选仓选配计算平均时长等)，产品（自动罚款功能使用率，自动调拨推荐转换率等），以及测试、设计等等。

精准的指标，能提供好的方向，明确目标，更好的指导工作。优秀指标解读思维，能让自己辨识重要度，抓住问题关键。以及系统的指标体系，能够全面完整的覆盖关注范围，以及精准快捷的定位问题。数据分析指标篇会分为三篇：指标设计、指标解读、指标体系建设，进行介绍和案例分析，帮助大家在这几个方面有更加深入的了解和提升。

游戏现在似乎已经成为了大家绕不开的一个娱乐方式，从大型端游到手游，到页游，再到各种 APP 里面的 H5 小游戏，它以各种方式入侵了我们的生活。那么在享受游戏的同时，作为一名前端开发，也开始思考如何开发一款游戏，在技术层面它应当具备什么？

除了基本的游戏画面、动效开发、渲染功能，还有一项值得探究的东西，那就是物理引擎。一个好的物理引擎，保证了游戏内的交互体验和现实中相似，给人提供了更优质的体验。

现在好用的物理引擎有很多，大部分都是开箱即用，但物理引擎的基础和底层逻辑是什么样子的，可能有些人并不了解。从这期开始我们将分多个部分介绍物理引擎的基础，让大家对此更加了解。以下的内容部分参考自《游戏物理引擎开发》。

缓存命中率的高低直接影响客户体验。在本文中我们就一起探讨CDN 缓存命中率的概念、影响因素以及优化策略。

Our engineers have the responsibility of ensuring a consistent and positive experience for our riders, drivers, eaters, and delivery/restaurant partners.

Ensuring such an experience requires reliable systems: our apps have to work when anyone needs them. A major component of reliability is having engineers on call to deal with problems immediately as they arise. We set up our on-call engineers for success through training, tools, and processes.

In this article we will provide an overview of how we at the Eats Safety team ensure that our engineers are fully equipped to provide prompt, high-quality service—anywhere in the world, 24/7.