我是如何做技术分享的 ？

1. 前言

一直想在 2021 年给大家做一期分享，以解决咱们客户端团队分享频次多，但质量上还有些参差不齐的问题，名字就叫：如何做一个优秀的技术分享？ 于是我回顾了一下我过去的分享，大大小小分享了 30 多次，真正称之优秀的分享在我看来却 1 次都没有，于是我偷梁换柱，改了一个标题：如何做技术分享？

但考虑我也在摸索阶段，所以又改了一下标题为：我是如何做技术分享的？

为什么我挑战了这个分享任务呢？其实还是因为自己也希望能在质上有一个明显的提升，于是自己也四处登门拜访，比如朱凯，在分享之道上给我讲了很多，听后受益匪浅，也争取能在本次分享上就能有一次印证。

2. 现状

在分享之前，对客户端的一些同学进行了问卷调查，大家都非常给力，给我提供了非常多的思路。从反馈来看，我们有一些暂且可以称为好分享的例子：

2.1 好分享的加油站

• 听众有收获

第一个是听众有收获，典型的例子就是如何写自定义 Plugin，或者是 HenCoder 的自定义 View 和属性动画系列，大家给了高度的认可评价，主要原因是知识点非常实用，一看就会，一练就行。

• 分享有明确目的，有具体的示例

这一块大家认可比较多的是最近的设计模式，整体都是遵循：生活中的设计模式 => 程序中的设计模式 => 一个示例引出问题 => 用设计模式解决问题 => 拓展和应用 这样的节奏。

• 分享有深度，有代入感

这一块主要是之前分享的 UI 基础界面，大家一致认为知识点有深度，触及了大家的认知盲区，尤其是精心选取的视频，讲述的非常有代入感。

2.2 坏分享的罪魁祸首

• 代码细节过多

这个让我想到了我之前的有个分享，讲的是 Android 音视频架构，全文下来 80% 的时间在追究代码细节，导致反馈和体验都很不好，有相关 Android 经验的同学都不能迅速消化，组内的其他同学，就更加懵逼了。

• 没有背景知识

第二个是没有背景知识，此前在分享一个工具接入的时候，分享半小时下来我都没有明白这个工具的作用是什么，等我终于明白作用的时候，我却已经错过了很多关键内容，再也跟不上作者的分享。

• 语速越来越快

这个是比较多的同学的通病，尤其是最开始做分享的同学，容易因为紧张或者迫切想完成分享任务，而存在这个问题。

• 无控场

这个问题目前来说已经好了很多，这里就不多提了。

2.3 分享之路的绊脚石

大多数技术团队都会提倡做技术的同时能够有一些技术分享的产出，但大多数客户端团队都没有分享氛围，或者说是没有分享基因，始终热衷分享的同学依旧是那么几位。于是做这次分享之前我也收集了一下大家不愿意分享的原因，从通病来看依次是：

• 没有时间做准备

相当一部分的同学给的反馈都是没有时间做准备，人的时间都是有限的，如果确实遇到了时间问题，可以给自己的 Leader 求助

• 听众的水平都比自己高

“听众的水平比我高”，这是一个伪命题。若分享人充分准备至少比 90% 的听众更加深入了解某一领域。台下若有 1-2 个大佬，能帮助分享人指正、完善也是极好的。无论怎样，收益最多的还是分享人本人！

• 不知道分享什么

这一块我的建议是：

首先分享你熟悉和擅长的东西，不要管别人懂不懂或不要去想有没有必要分享这个，如果别人刚好是懂的，他是可以选择不参加的，所以这个顾虑是多余的。

分享自己最近所学所得。我们总是会学习一些新东西，而这些东西大多数情况下其他同学都是了解的层面，只要你做了准备，肯定可以碾压 90% 的听众，一人学习全组受用，这个非常好用。

别把分享当任务，分享的时间你，你要充分相信你就是那个领域的大牛。当你做多了，你会发现你可分享的 Topic 会越来越多。

• 不知道怎么做分享

今天我们的讨论核心就是解决最后这个问题：到底应该怎么做分享。

3. 分享的价值与质量

3.1 分享心态

要做好分享，首先要有一个分享的心态。通常我们很少会去主动把知识传递给大家。背后的原因可能比较复杂，不够自信，或者有压力等等。而往往分享来自于工作任务。如果应付了事，那只能是浪费时间，一定要有做有价值的分享的心态。

3.2 分享价值

不论一个分享的背景是什么，分享价值的衡量都只能根据听众的受益来衡量，听众才是整个分享的核心，如果听众不能从分享中受益，那这个分享将毫无意义。

我认为分享的核心并不是我们讲了什么，而是观众听到了什么，理解了什么，记住了什么。

从信息发出到接收，有无数的干扰因素，分享者的任务就是要把干扰、噪音最小化，把真正重要的信息传达出去。

对于每一个同学来说，时间都是非常宝贵的，如果我们花上 1 个小时时间听了一个分享，没有任何收获，那无疑就是浪费时间。久而久之，对分享者的分享自然也就会缺乏信任感，继而团队的分享也就陷入了死局。

显然，分享者是有义务和责任的。 当然，分享者也能从分享中获益，但是这个是分享的附加价值，不是核心价值。所以，分享的价值高低取决于听众的受益程度。

3.3 分享质量

分享的价值取决于听众的受益程度，而分享的质量想必是取决于分享者准备的认真程度了。一个认真准备过的分享，加上一些技巧，一定是足够有质量的。

4. 技术分享的道与术

4.1 分享之道

我认为做一个分享之前，首先我们应该想清楚，自己这个分享的目的是什么？是要介绍某个技术过程？还是说服大家采用自己的技术方案？你讲的东西和方案对听众而言，到底有什么意义和价值。所以我们应该多讲目标听众不知道／感兴趣的内容。 听众投入最宝贵的时间来听分享，分享者的一个起码责任是保证听众在这段时间的收获。分享之道其实就是站在听众的角度想几件事：

• 听众的知识边界是什么？（知道什么，不知道什么，这个是最终把对方讲懂而不是只让对方觉得你牛逼的关键。）

• 我要怎么讲才可以吸引他一直听？

• 我希望传达给对方的核心知识是什么？（主题）

如果一个分享者在分享之前已经想明白了这 3 件事，其实就已经可以是一个不错的分享了。

类比第 1 件事，大家的知识边界应该是属于全组的内功普及，经验从 0 到 10 年不等，所以内容不能难，但也不能太简单，总的来说我觉得应该是在新意，所以不应该是网上能搜到或者书上写的套路。大家在讲的时候不应该忽略很多你已经知道但听众不知道的知识前提，把一次技术分享变成一次技术答辩。

对于第 2 件事，应该是每 1 个分享都需要考虑的事情，对于我来说，我觉得应该是：1 个例子抛出问题 => 引出思考 => 循序渐进，或者说：背景 => 特点 => 应用 => 延伸，总之，你需要抱着一种每时每刻听众都会因为太乏味而走开的觉悟去准备。对于这个思路大家可以回忆一下我之前的设计模式分享，其实就是这样的。我会先不使用设计模式让大家感受到代码设计的问题之处，引出大家的思考，再循序渐进地引入设计模式的主题。

对于核心知识点，每 1 次分享都应该有一个核心知识点，这个核心知识点应该是可以用足够简洁的文字概述的。比如责任链模式，我认为核心就是：多个对象形成一条链，沿着链条传递请求，直到有对象处理为止。只要我时刻心中记住这个核心知识点，我有自己的主题，我就不会跑题。

4.2 分享之术

分享之道是战略，分享之术是战术。我们应该有战略上的远见，也应该有战术上的储备。

• 有一个简洁明了的主题

技术分享通常有大量细节和繁琐信息，如果没有一个关键观点的提炼和归纳总结，观众和演讲人都可能陷在细节里，而偏离主线。因此，建议在分享的一开始，就提出这个主题。

• 设计一个有创意的开头

这是提升自信的良方，好的开头会影响观众对分享者的第一印象，也使听众更容易包容后来可能出现的失误。比如我在设计模式分享中举的例子，听到大家的笑声，我就知道我这次会是一个接受度蛮高的分享了。

• 准备有开头有结尾的故事

大多数分享，都可以遵循：先提出问题，再给出解决方案，最后有小结的枝干。切记，分享不是写文章，最好不要去过多的提自己解决问题中的思路和详细方案。

• 精心准备故事的衔接（反复承上启下）

每个人都有惰性，很少有观众会在一个小时的技术分享过程中真正不断思考总结。所以，为了确保信息真实呈现，必须 反复帮他们归纳已经听到了什么， 告诉他们将要听到什么， 比如 "我刚刚讲了....现在我们来介绍...." 这个思路大家可以回忆一下我在讲 Kotlin 的泛型的思路。

• 一图胜千文

能用图表的一定用图表，能用文字的通俗易懂的文字讲懂的，千万不要举代码。希望能和大家一起约定，每次分享的例子代码能不超过 10 行。如果不得以超过，分享者一定要注意控场，不要因为一个代码例子分散了大家的注意力。

• 避免常见错误或者明显缺陷

没有切身体验的死记硬背和摸爬滚打后的娓娓道来，听众的收获和感觉是不大一样的，所以在做一次技术分享之前，最好有自己长时间的沉淀，比如我一直在准备 Android 稳定性相关的分享，但我总觉得沉淀不够，所以希望等二期优化做出了成绩再和大家交流。

• 最好有排练

其实我很少有分享做排练，除了我此前在外重复做的一个分享，很明显下来后，我的那个同样的分享越做越好。

• 可以的话，我们站着分享。

听众大多是坐着的，站起来有利于建立自信，营造一种对场面的无形控制力。大家可以试试，这可能也是渝钧大多数时候和大家分享都是站着的原因。

• 事先说明你是否乐意被听众打断

被一根筋的听众缠上是很麻烦的事情，如果你觉得你解释不清楚，不妨大胆告诉她，你们下来再讨论，如果你觉得你是一个比较习惯一次到底的同学，最好分享开始讲清楚，QA 部分在最后。

• 可以的话，把做分享搞成说段子

有点幽默感大家都会很喜欢的，印象很深之前讲设计模式，大家就因为我开头举的例子，而更愿意接受听下去。

5. 技术分享的架构模板

很多同学分享容易跑题，或者是本身没有自己的分享脉络，这里就根据目前大家习惯做的分享类型，简单分享一些常见的架构。这样的脉络架出来的分享，一定是不会太差的。

5.1 需求实现类

此类内容，重在介绍实现具体业务需求过程中的技术实践。要让听众能够在了解背景的情况下，了解分享者的思考过程、具体实践、实践结果。

典型的分享架构：

• 介绍业务背景，分析业务特点

• 技术选型过程，讲解选择原因

• 架构设计方案

• 重点问题解决

• 总结

5.2 技术优化类

代码优化、架构优化、工具优化等技术优化总结，需要让分享者明白，为什么要做优化，怎么做的，最后效果怎么样，如果可以的话，还可以进行升华总结，指出哪些特定环境可以采用同样的优化效果。

比如包体积优化、稳定性优化、启动优化。

典型的分享架构为：

• 背景介绍，重点介绍技术急需升级的原因

• 技术选型

• 总体设计

• 细节设计

• 效果总结

5.3 理念实践类

对某一技术方向、架构思想，或者说是技术理念的实践。比如 Deeplink 的使用，Flutter 引入开言项目的实践，Android Compose 的引入实践。

典型的分享架构为：

• 技术理念的诞生背景

• 技术理念的发展现状

• 能解决什么实际问题

• 实践过程的落地方案

• 总结与展望

6. 最后

需要记住的是，技巧只是辅助，表达都是可以训练出来的，注意几个要点即可不断提高。

但是要分享给别人真正觉得很赞的东西、有价值的东西，在于自己平时的积累和思考，在于你做的事情是否是真正有价值（就是干货），在于你思考总结的内容是否有深度有高度（方法论、思维模式），这才是根本。换句话说，要分享给受众 Level 1 的一个知识，你需要有 10 个 Level 为 2 的储备，否则你的分享只能是空洞而贫乏的，缺乏实质和高度。

推荐阅读：

看了那么多推荐，最后还是选择了这款便携式

做了五年 Android，我顿悟了...

这 14 款 APP，违法，违规！

腾讯开源：Kotlin 高性能特效动画组件！

摆脱 Android 和 iOS：七款免费开源移动操作系统的尝试

#公众号：code小生