内容编辑: 小木箱
内容原创: 快手小红书 Android 架构与开发流程对比
引言
Hello，我们是让知识变得更简单的BaguTree ，欢迎来到BaguTree周六茶话系列教程。
今天BaguTree分享的主题是 《 小红书、快手的技术沉淀 & 架构思考 》 ，BaguTree从五个方面将 《 小红书、快手的技术沉淀 & 架构思考 》 解释清楚。
第一个方面是分享人介绍。 第二个方面是分享的原因。 第三个方面是小红书、快手技术沉淀。 第四个方面是架构思考。 最后一个方面是Q&A。
如果你吃透了 《 小红书、快手的技术沉淀 & 架构思考 》 ， 那么将会帮助你更轻松的从互联网小厂过渡到互联网中大厂。
一、分享人介绍
Flywith24一开始不在知名互联网公司工作， 通过持续性学习，不断提升个人行业影响力，于2021年，顺利加入快手。于2023年，顺利加入小红书。
二、分享的原因
Flywith24在BaguTree分享 《 小红书、快手的技术沉淀 & 架构思考 》 主题主要有两个原因。
第一个原因是: Flywith24刚毕业时一直想了解大公司的开发流程以及架构，但网上资料寥寥无几。 现在也是经历了一些大型互联网公司， 希望通过对外输出提炼， 帮助大家达到学以致用的目的，技术上少走弯路。
第二个原因是: BaguTree是一个大佬云集的平台，通过BaguTree分享自己在互联网中厂工作心得，可以认识更多志同道合的Android朋友。
三、小红书、快手技术沉淀
开发语言
小红书的 Android App 的上架时间比快手晚三年半，因此两个 App 的技术选型有着非常大的区别，从开发语言上来说:
快手Kotlin渗透率
快手大量老代码是 Java 写的，新增代码鼓励（不强制）使用 Kotlin。
小红书Kotlin渗透率
小红书代码全 Kotlin（部分自研库内使用的是 Java），新增代码强制使用 Kotlin，全面拥抱JetPack组件。
研发流程
因为快手和小红书Android研发流程比较接近， 所以我们不去刻意的区分。 统一的说一下: 快手和小红书研发流程主要分为产品、研发、版本三个维度。
产品
首先， 产品根据优先级可以从需求池筛选需求，并确定哪些需求可以入版。
然后， 每周固定时间， 产品会和Team Leader进行需求预评。
最后， Team Leader给R&D分配需求任务， 产品和对应R&D拉会进行需求详评。
研发
R&D参加完需求详评后， R&D会提供需求排期包括: 开始时间、DeadLine等等。
如果需求开发周期较长， 那么R&D要额外开需求技术评审会议。
如果需求开发周期较短， 那么R&D直接进入开发阶段。
在开发阶段中， R&D需要注意Git协作规范、CodeReview规范。
关于Git协作规范:
首先， 个人需求分支是基于develop分支进行衍变。
然后， 基于需求分支进行开发、自测、提测， 提测完毕，需求分支才能合到feature分支。
其次， 使用Gitlab的MR功能将feature分支合入dev分支。
接着， 挑选一个合适的时间，配合产品、QA、UI等进行showCase，确保主链路功能完整性。
showCase完毕前， 开发要进行自测， 自测完毕后，再提测。
showCase通过后，如果涉及到UI改动， 那么产品、UI会进行走查。
最后， 走查完毕， 产品设计认为功能OK， 进入CodeReview环节。
关于CodeReview规范:
CodeReview有几个很重要的原则
- 功能完整性
- 功能安全性
- 可拓展性
- 可修改性
- 可重用性
.......
进入提测阶段， 测试通过测试平台不断地提Bug， 如果没有发现严重的Bug， 那么才能合入版本分支。
最后， 在某个固定时间， 快手会封版，并将Dev分支改成Release分支。
一旦封版，那么非特定情况不允许合并需求。
版本
版本的迭代需要开发、测试、产品等各个方面的资源支持。快手、小红书迭代周期是一周一迭代， 也就是班车制。
为什么叫班车制呢?
比如像我们的公交车， 如果赶不上这一趟公交车， 那么我们就必须等下一辆公交车。
版本迭代也类似， 如果需求赶不上发版节奏的话， 那么就需要流动到下一个版本。
在发版流程， 因为App的体量较大， 每次发版首先走灰度流程， 灰度期间进行小范围的放量。
在灰度期间， 我们要观测是否有严重的Bug。 如果有严重的Bug， 那么就要进行紧急修复， 提升用户体验。
灰度流程分为灰度1、灰度2和对比灰度等。如果灰度期间没有阻塞性问题， 那么可以提交市场审核。
如果市场审核通过后, 那么进行全量发布。
开发框架
接下来， 我们说一下快手和小红书的自研开发框架。 快手开发框架用的是MVPs， 小红书开发框架用的是LCBs， MVPs和LCBs核心思想都是组合。
快手MVPs
优点
快手内部基于MVP思想封装的研发框架MVPs， MVPs框架中的Presenter数据来源， 基于依赖注入框架去实现的。
最核心的地方是Presenter， Presenter是一个Tree。 父Presenter可以有子Presenter的， Presenter内部封装了对View的持有， 父Presenter内部是作为一个最小的逻辑单元， 这样实现的优点是更方便的进行ABTest。
缺点
View处理比较分散
MVPs最大的缺点是View处理比较离散。
快手MVPs是基于多个Presenter对不同View进行处理， 因为View的操作比较离散的。
Presenter职责并不明确，而Presenter内部View逻辑写在一块儿。如果某个View的状态出现了异常，那么难以追溯。
案例
比如在快手上下滑动的业务模块里面， 基于我们业务组创建了一个叫"形态复用"的功能。
目的是将UI页面的UI元素进行抽象， 比如快手状态栏底部有一些描述文案、音乐信息、信息区等。
我们把所有Element抽象成一个Group， Group职责是组织Element， 控制Element的优先级、数据联通等。 这样就符合了Java设计原则的依赖倒置原则。
比如头像区域可以抽象成一个AvatarAndFollow， 这里面有三个概念我们要去理解， 第一个概念我们叫ElementView， 第二个概念我们叫Model， 第三个概念我们叫Element。
其中， ElementView是UI上可复用最小单元， 内部持有了View的引用。
其中， Model使用了单向数据流， Model和View进行绑定。
其中， Element实现了上层的业务到Model的转换， 数据流向是单向的， 涉及到一个事件流向。
最后， 通过点击事件、长按事件和双击事件等可观察事件进行监听， 实现数据和UI的绑定。
小红书LCBs
原理
小红书的LCBs架构主要分为三个部分
- Linker: 导航、页面跳转
- Controller: 处理业务逻辑
-
Rx观察数据流
-
- Builder: 构建LCB的角色
在小红书的编辑页面， 顶部导航是一个节点， 内容区域是一个节点， 图片列表是一个节点， 底部菜单栏是一个节点。通过一个个页面节点， 串联起来成为一个页面， 核心思想借鉴了Uber-RIBs
缺点
- 内部使用Dagger， Dagger不是针对Android移动平台设计的框架， Dagger会生产各种临时文件， 使包体积变大
- LCBs节点的颗粒度较粗
- LCBs无标准的通讯逻辑
- 架构组设计的LCBs V1不兼容LCBs V2
四、架构思考
WHAT: 什么是架构模式?
用百科全书来说: 架构模式(architecturalpattern)是软件架构中在给定环境下，针对常遇到的问题的、通用且可重用的解决方案。类似于软件设计模式但覆盖范围更广，致力于软件工程中不同问题，如计算机硬件性能限制、 高可用性、业务风险极小化。一些架构模式会通过过软件框架实现。
而软件框架， 通常是指为了实现某个业界标准或完成特定基本任务的软件组件规范， 也指为了实现某个软件组件开发时， 提供规范所要求之基础功能的软件产品。
常见的架构（Architecture）有:
- MVC
- MVP
- MVI
- MVVM
- Clean Architecture
- VIPER
常见的软件框架（Framework）有：
WHY: 为什么自研业务架构?
大型的互联网公司是一个多元化合作的过程， 合作无处不在，例如：道路上的司机/行人在规则限制下与其他司机/行人合作，实现安全驾驶。
所以一个适合的框架应该满足以下两点：
- 适应业务需求，提升效率
- 限制老司机们的骚操作，降低犯错概率
规模越大互联网公司， 如果没有合适的业务架构， 那么风险性越高。
比如: 快手光Android大概有几百人， 几百人会同时往一个仓库里面提交代码。
如果几百个人开发经验、编码风格都不一样，代码没有强制性的限制， 那么代码质量不会太高。
这也是FlyWith24认为一个互联网公司要自研业务架构的根本原因。
WHAT: 什么样的业务架构适合企业?
没有最佳实践， 只有更加合适。当前业务架构不一定满足未来的业务架构。业务架构需要随着业务的不断迭代， 不断优化。
WHEN: 什么时候要去优化业务架构?
当我们业务遇到通用性的问题需要去解决， 为了解决这样通用性问题， 我们需要优化和改造适合企业的业务架构。
五、Q&A
gaolhjy Say: 项目管理中， 如何避免需求延期?
Flywith24 Say: R&D评估任务做多久？要求R&D有一定的业务评估能力，如果产品不遵守规则，需求不断变更，导致R&D研发时间拉长， 需求延期导致提测异常， 那么会触发复盘流程。
如果R&D引入了三方库， 导致线上问题， 那么也会触发复盘流程 & CodeReview机制。
如果没有在DeadLine完成业务需求， 那么也会触发复盘流程。
! Say: CodeReview的形式和流程是怎样的?
Flywith24 Say: CodeReview， R&D可以说又爱有恨， 大家希望别人的代码注释完整， 逻辑严谨， 但是自己开发的时候， 不希望去理解别人的代码。
快手， 首先gitLab提交MR的时候， 触发pine line动作， 流水线有很多节点，每一个节点都是阻塞式的操作， 如果有一个节点无法通过， 那么下面的节点没办法正常进行。具体节点包括: 编译检查、代码质量检查、包体积检查、语言文案检查等等， CodeReview是作为流水线中的其中一个节点去做的。一般是放在提测之后进行的。然后CodeReview会根据版本Owner、TL等进行+1操作。测试完毕后会有+2操作。
小红书， 使用的是Uber的传统CR机制， 提完MR之后， 会交给同组的同事进行CR。
匿名 Say: 排期周期是否允许刻意拉长?
Flywith24 Say: 在快手， 我学到一个关键词: Buffer， 排期时间留Buffer， 因为中间可能有修Bug、开会打断自己， 要给自己留一下缓冲时间， 避免延期。
ShaJia Say: 小红书招人吗?
Flywith24 Say: 小红书目前还有几个Android HC， 感兴趣可以联系我， Base地在广州和北京。
gaolhjy Say: 刚刚提到研发周期类似于班车，那请问：如果本周因为放假补班、休假，怎么办呢？如果开发延期了，怎么办呢？
Flywith24 Say: 从年初的时候，快手整个一年所有版本是有规划的，是自动跳过节假日的。
春节的春节活动会进行一些延迟的一些发展，会保证春节活动的周期内代码的一个稳定性。
至于开发延期了怎么办？作为开发保证不延期， 即保质保量保交付是基本的要求。
gaolhjy Say: 小红书、快手工作时间段，开会与研发的时间比例大概是怎么样的？
Flywith24 Say: 其实有很多会议对R&D来说是无用会议。 但是周会、周报和晨会， 其实是很有必要的。
我在快手那个小组是没有周会的， 我在小红书的周会是在一个会议室里面进行沟通。
沟通内容包括但不限于主动抛出风险点、OKR进度跟进和技术点分享等。
gaolhjy Say: 对于研发不遵循开发规范，小红书、快手有哪些软管理及硬性管理呢?
Flywith24 Say:
快手会有一些强制性规范， 比如多语言文案， 前期会在xml里面手动添加， 后期产品通过平台配置文案， R&D远程获取配置后， 去跑本地的脚本， 相当于强制性规范， 包体积规范、图标的规范等等也算是。
咖啡洒在键盘上 Say: Bug需要建任务，并且维护任务状态吗？提测有对Bug率有要求吗？
Flywith24 Say: 需要! 据我所知快手OKR是没有Bug率的考核的， 但是有平台会去专门的统计Bug率。
不知所云 Say: 在快手和小红书的工作时间是怎样的？
Flywith24 Say:
快手是双休的，员工手册说是非弹性工作日，早上打卡的时间区间为 9:30 - 10:30，午休去除 1.5小时，合计满 8 小时即可。
小红书是大小周，周六是双倍工资，一般是10:00到22:30左右。
总结&规划
本次分享， Flywith24在BaguTree讲解了 《 小红书、快手的技术沉淀 & 架构思考 》 的方方面面， 包括Kotlin渗透率、研发流程、MVPs 和 LCBs开发框架。 也通过4H方法论思考了一个合理的业务架构模型需要具备的特质。
如果你想加入BaguTree周六茶话， 那么可以通过BaguTree官网、B站、抖音、 掘金、微信公众号和知识星球找到我们。
如果你对Flywith24的成长经历感兴趣， 那么你可以通过github、B站、掘金、微信公众号、博客、小专栏、语雀、CSDN 、微博和知识星球找到他。
我们是让知识变得更简单的BaguTree ，下周六将是肖会给我们带来的AI相关课程， 我们不见不散~
