绿化区域的构建是大范围室外三维场景展示中不可或缺的一部分，本文提出了一种基于pix2pix模型的绿化区域生成方法，大幅提高了3D楼书项目制作的效率。

在以往的问卷调研中，有的同学总会问到两个关键性问题：

Q1.“做问卷调研，需要多少的目标用户？”

Q2.“调研的目标用户难以触达，只有X份问卷数量够吗？”（问卷数量少，不足百份）

通常来说，用户研究员的建议是根据调研要回答的问题，至少能回收384份有效问卷，有条件的话可以在此基础上提高回收量。那么“384”这个数字是怎么得出来的？问卷调研的回收量一定要达到这个标准吗？如果达不到这个标准，对调研的结果有什么影响？要回答这些问题，我们首先需要了解问卷调研是什么。

有效阅读时长和有效阅读屏数是分析内容质量的两个重要指标，一篇优质的内容理论上应该是被认真地阅读完成，产生的数据应该是在较合适的时间内完成高屏数的阅读。如果在短时间内阅读屏数非常高，则说明用户在刷数据或者对内容不感兴趣，随手滑，无法吸引眼球，从而说明当前内容质量差，需要进行更新，迭代，以更好的满足用户诉求，推动用户对APP内容有足够的兴趣和粘性。

本文就向大家介绍我们设计实现的一种对业务代码无侵入的页面网络请求预加载框架，能够在不修改原业务逻辑代码的情况下，让页面具备网络请求预加载的功能并且具有通用性。本框架适用于使用了路由框架（例如阿里ARouter）的页面。

随着实时音视频技术的发展，音视频聊天已经走入寻常百姓家，微信2017年每天有4.1亿次的音视频通话。贝壳找房IM作为线上商机来源，也实现了该功能，作为经纪人和客户沟通的便捷工具。除了IM音视频通话，实时音视频技术在贝壳还用到了直播自动审核、经纪人讲盘训练等各种场景，这些场景中都用到了实时音频流网关。以经纪人讲盘训练为例，通过构造一个虚拟人进入音频房间，可以和经纪人进行实时问答，模拟买房和讲盘，提高经纪人作业效率。要达到该效果，虚拟人需要能够识别经纪人讲话并且进行回答或者提问。

本文主要介绍了贝壳存储网关的使用场景、架构设计以及稳定性建设。

面对特殊场景、特定人群、特色业务的体验策略。

KeMonitor是贝壳找房服务端一站式监控报警平台。2018年～2020年是业务的快速发展阶段，在这期间陆陆续续研发了基于CAT、Prometheus、ELK、Skywalking、以及部分自研专有数据监控平台，大大小小攻击十余个监控系统，各系统均自行建设了各自的报警能力。报警发生之后，一线研发同学就会同时打开多个平台，去看基础设施监控、应用监控、日志等，五花八门的报警也给用户带来了最多的痛点。在此背景下具有一站式体验的KeMonitor平台就应运而生了。在2021年，由贝壳找房人店技术中心牵头，联合了多个部门，针对在报警环节进行了系统性的治理，治理报警的过程中也沉淀了一套完善的报警中心以及配套的报警响应SOP机制，下面会为大家详细介绍整体的建设经验。

前端构建工具vite基于原生ES提供了丰富的内建功能和快速的模块热更新，本文主要介绍了vite在本地提供服务的基本原理和处理流程，如何利用中间件和插件机制提供开箱即用的配置。

本文主要阐述了针对贝壳IM单聊群聊消息的优化思路，通过压测、寻找瓶颈点、提出优化方案、验证优化方案、代码实现的多轮次迭代，最终实现了20倍以上的性能提升。

贝壳作为房地产行业最早实现真房源的公司，也是行业内的TOP公司之一，同样面临着黑产的困扰。贝壳面临的黑产，既有传统互联网黑产迁移过来的黑产，也有针对房地产行业一直以来的黑产“线上化”。

hook 是 React 16.8 的新增特性。它可以让你在不编写 class 的情况下使用 state 以及其他的 React 特性。

本文通过对比react15与react16，帮助读者更好的理解React 16基于时间分片的任务调度方式，对于提升用户体验来说其显著优势在哪里，以及该方式是怎么实现的。

安装包瘦身是性能优化的重要一环，一个特别大的安装包带来的体验是非常糟糕的。通过本文，你可以了解到iOS比较全面的瘦身方案来查漏补缺、从技术角度如何降低各业务线的协作成本以及后续防止劣化的机制保证。

Flink作为新一代的实时计算引擎在贝壳越来越多的应用场景下被应用，本篇文章将会讲述贝壳实时计算团队基于Flink指标在任务监控报警、资源分析与调优、运维提效以及容器化相关的实践。

贝壳在IPD和Android平板上进行了大量的Flutter和Native混合开发实践。在这个过程中遇到了一个特殊场景：Flutter和Native在同一级页面并且可以来回切换。本文就实践中遇到的问题和解决思路进行讲解。