话题公司 › 知乎

公司:知乎

知乎是一家中国大陆的问答网站,创立于2011年1月26日,产品形态与美国在线问答网站Quora类似。“知乎”在文言文中意为“知道吗”。2012年2月底,知乎使用“发现更大的世界”作为其宣传口号。截至2017年9月20日,知乎注册用户数超1亿,日活跃用户量达2600万,人均日访问时长1小时,月浏览量180亿。截至2016年5月,知乎累计产生了1000万个提问、3400万个回答和3500万个赞同。2021年至纽交所上市,在挖掘优质创作会员与投入自有内容的同时,随着多样性的社群文化增加,知乎越来越类似于reddit等同好论坛。

知乎由北京智者天下科技有限公司(法律性质为有限责任公司)所持有,其法律代表人是李大海。智者天下亦开发了包括Android、iOS平台的手机“知乎客户端”、“知乎群组”、“知乎日报”与“公益壹点通”四款手机应用程序。

使用 SugarAdapter 快速构建 Android 列表页面

知乎 App需要一个易上手、可维护的列表脚手架来支撑业务需求。SugarAdapter是一种简化RecyclerView使用的方案,通过annotationProcessor生成冗余代码,不需要复写Adapter。SugarHolder是一个简化RecyclerView创建多种列表视图的解决方案,通过Layout-ViewType-Data的模式简化使用。ViewHolder可以视为列表中细粒度的Controller。

知乎推荐系统的实践及重构之路

知乎是一个综合性知识内容平台,用户数超过2.2亿,提出了超过3000万个问题并获得了1.3亿个回答。除了首页推荐外,知乎还有20多个推荐场景,因此需要构建一个通用的推荐系统。推荐系统通常包括召回层和ranking层,召回层从候选集合中选择待排序集合,然后经过排序模型选出推荐结果。对于通用的推荐系统,需要考虑用户的多维度需求,采用多个不同队列进行排序并通过融合策略满足不同需求。知乎的推荐系统已经包含了召回层、ranking层和二次排序。

知乎 AI 用户模型服务性能优化实践

知乎的AI用户模型服务主要为知乎用户提供数据和服务,包括首页个性化Feed的召回和排序、相关回答的用户长期兴趣特征、问题路由和回答排序中的作者创作权威度,以及广告定向投放用到的基础属性等。该服务提供的数据和功能包括用户兴趣、用户Embedding表示、用户社交属性、用户实时属性和用户基础属性等。服务架构主要分为Streaming/离线计算、在线服务和HBase多集群同步三部分组成。其中,Streaming计算主要涉及实时兴趣的计算流程,包括相应日志获取、映射到对应的内容维度、用户-内容维度汇总和计算兴趣等。

知乎 Android 客户端 Hybrid 调试实战

知乎客户端中的Hybrid框架存在联调问题,调试工具不完备。为了方便调试,可以使用通信日志和全局日志记录问题。通信日志通过在两端打印约定格式的日志,使得前端能够了解通信过程。全局日志可以通过adb命令获取,也可以使用flipper工具查看。这些工具能够帮助解决前端和客户端开发的联调问题。另外,还提供了本地模拟和远程调用两种方式来测试客户端接口。本地模拟通过在手机上打开一个网页,点击模拟调用按钮实现。而远程调用则通过在PC网页上调用客户端接口,通过扫描二维码进入Hybrid页面来实现。这样可以更方便地进行接口测试,特别是针对特定页面才可以调用的接口。

仪表盘场景的前端优化

这篇文章介绍了一个中台系统中仪表盘页面的设计思路。仪表盘由不同的图表卡片组成,支持多种类型的图表展现。为了实现动态添加、删除和编辑卡片的功能,将仪表盘信息分为仪表盘和卡片两个实体,并约定了两类接口供前端使用。前端代码实现简单,通过一个自治的思想,仪表盘组件只负责摆放卡片,而卡片的加载、查询和渲染由卡片自己负责。使用了react-refetch类库来简化数据加载过程。然而,这种自治的解决方案在某些情况下导致仪表盘页面卡死或交互滞后的问题。原因是某些仪表盘的卡片数量较多且需要渲染大量数据,导致页面性能下降。

知乎实时数仓实践及架构演进

这篇文章介绍了知乎在实时数仓中的稳定性实践。2016年初,知乎选择了Spark Streaming作为实时数据处理框架,考虑了日志量和实时性需求。为了保证数据正确性,知乎在Spark Streaming层实现了At-least-once语义,并在下游做了去重逻辑。文章还提到了通用的ETL逻辑与埋点数据结构的关系。

知乎 HBase 实践

知乎选择使用HBase作为在线存储的支撑组件。之前的离线计算集群中,HBase的日常计算和数据读写受到其他系统影响。为了满足在线服务的需求,需要构建一套适用于在线服务的HBase系统。需求包括隔离性、资源利用率、成本控制等。为此,团队参考基础设施平台化经验,目标是将HBase服务打造成基础组件服务平台,提供给上游业务使用。

数据分析在知乎商业质量保障中的初步实践

知乎客户端发版周期短,商业功能易受第三方改动影响。为减少故障,商业化测试团队运用核心数据进行验证。核心指标包括广告的填充率、加载率、可见率、点击率、转化率等,以及客户端和服务端的性能和资源占用情况。在需求评审阶段关注埋点设计,灰度阶段对比版本核心数据判断功能是否正常。服务端上线时观察监控,项目上线后及时分析数据是否达预期。

Android DataBinding 编译变慢之谜

知乎 Android 客户端在进行组件化拆分时,发现编译时间突然增长。经排查发现,一个组件拆分导致 setter_stores.bin 文件体积增加,与编译时间增长相关。体积和编译时间的增长与依赖树中 databinding 组件数量有指数关系。即使有新增普通库的依赖层级,编译时间不变;但如果有启用 databinding 的库,编译时间会增加。解决方案是去除一些组件的 databinding。

为知乎增加快捷键

知乎最近在桌面端增加了一些快捷键,包括在浏览页面时的选中、展开和赞同功能,以及播放视频时的全屏和静音等功能。文章分享了开发快捷键的经验,提到了快捷键被重复定义和实现的问题。作者提出了一种解决方案,通过在父组件中注册快捷键,在回调时调用子组件实例方法来实现功能。这种实现在知乎的组件结构中最多只能在层级中部的AnswerItem范围内进行。

Griffith - 知乎视频播放器

Griffith是一个基于React的视频播放器,适用于知乎网页和移动网页。它具有简洁易用的用户界面和快捷键支持。该播放器使用React开发,支持通过组件调用,并使用Context API进行状态管理。它可以通过MSE实现动态平滑切换视频清晰度,节省视频CDN带宽。Griffith还提供了免构建的standalone模式,可以直接在浏览器中使用。它还具有丰富的事件系统,支持滑出窗口暂停功能。

「知乎画报」的移动端动态化工程实践

这篇文章主要介绍了知乎在移动端推广落地页上的动态化方案实践经验。文章提到了落地页加载速度缓慢、支持预加载实现秒开、转化信息的全面采集和用户体验升级、支持样式实验提升转化效果等问题。他们通过开发名为"Morph"的动态化基础能力,采用Flexbox布局编写样式文件并保存在云端样式数据库,通过独立的样式服务实现信息流广告卡片的展现。移动端已实现的动态化基础能力主要应用于信息流广告卡片的展示。

知乎移动端云测试平台实践(一)—— 系统设计

知乎移动云测平台是为了解决公司移动设备管理和测试效率问题而开发的。平台主要功能包括设备管理、远程调试、自动化测试、兼容性测试和定向稳定性测试等。架构上分为web前端、后端server和agent client三个部分。agent client使用Java开发,通过adb和libimobiledevice管理PC上挂载的Android和iOS设备,支持USB或WiFi连接。平台采用Netty和Protobuf进行Socket通信。在设备远程调试中,采用WebSocket实现实时数据推送,减少网络流量和延迟。实现UI自动化测试使用Appium工具,稳定性测试采用Monkey和指令生成方案。

知乎搜索评测实践

本文介绍了软件测试中效果评测的难点和重要性,特别是在搜索领域。知乎的搜索评测处于起步阶段,正在探索优化打分策略,并建立了自己的评测平台。评测方法包括抓取搜索结果进行对比、人工标注与质检评分,并生成测试报告。统计分析与短板review也是评测过程中的重要环节。文章还提到了希望通过实践优化评测方法,并扩大平台覆盖面。

知乎视频高可用设计

这篇文章主要是一系列图片的集合,内容涉及多个领域。图片中包括建筑、风景、动物等各种不同的主题。文章没有提供任何具体的解释或描述,只是简单展示了这些图片。

知乎 Druid 集群优化实践

这篇文章主要讲述了知乎在Druid集群建设中遇到的问题以及如何提升稳定性。文章介绍了Druid在知乎的应用场景和集群规模,以及Druid的整体架构和各节点的职责。通过阅读文章可以了解到集群从发展到不稳定再到稳定运行的历程,对于Druid初学者也有简单介绍。

首页 - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.1. UTC+08:00, 2024-11-15 10:31
浙ICP备14020137号-1 $访客地图$