rtc 开发入门的毕业设计答辩技巧

做毕业设计答辩这件事，说白了就是把你做的东西讲清楚，让老师听懂你到底做了什么、为什么这么做、是怎么做出来的。很多同学一提到答辩就紧张，觉得自己做的项目太"简单"，怕老师看不上。其实我想说，毕业设计答辩考察的不是你做出了一个多么牛的产品，而是你做项目的思路对不对、基础扎不扎实、遇到问题是怎么思考的。

如果你做的是 rtc（实时音视频）相关的毕业设计，那这篇文章可能会对你有点帮助。我自己当年做答辩的时候也是一头雾水，后来慢慢摸索出一些门道，今天就结合我的一些经验和大家聊聊，RTC 开发入门的毕业设计答辩到底该怎么准备、怎么说。

先想清楚老师到底想听什么

很多同学在准备答辩的时候会有一个误区，就是拼命堆技术细节，觉得展示的代码越多、架构越复杂，老师就会觉得项目越好。其实不是这样的。老师一天要听几十个答辩，早就审美疲劳了，他们真正想听的是你为什么选择这个技术方向、你的项目解决了什么问题、你在开发过程中遇到了什么困难又是怎么解决的。

换位思考一下，如果你是老师，你会对什么样的答辩印象深刻？我想了想，应该是那种逻辑清晰、言之有物、能回答得上来的。不是那种堆砌了一堆名词但问住了就答不上来的。RTC 这个领域其实很好讲，因为它是那种"看得见摸得着"的技术——你说连麦，别人脑子里立刻就能想到微信视频通话的画面。这样反而更容易让老师产生共鸣。

我建议你在答辩之前，先找几个不是计算机专业的同学试试给他们讲讲你的项目。如果他们能听懂你在说什么，那说明你的表达是过关的。如果他们一脸茫然，那可能需要再调整调整思路。费曼学习法说的就是这个道理，能用简单的话把复杂的事情讲清楚，才说明你是真的理解了。

项目背景和技术选型该怎么说

答辩开场一般会让你介绍项目背景和技术选型。这部分其实是有套路的，但套路用得好不好，差别很大。

先说项目背景。很多同学一开口就是"随着互联网技术的快速发展，实时音视频技术越来越重要……"这种话老师听得太多了，听了跟没听一样。你要说人话，比如你可以这么讲："我做的这个项目是一个一对一的视频交友应用。选择这个方向是因为我自己平时也会用到这类 app，发现里面的延迟问题有时候挺影响体验的，所以想自己试着做一做，看看能不能在这个环节上有所改进。"

这样的话听起来是不是舒服多了？至少老师知道你是真的有思考的，不是随便找了个题目应付。接下来讲技术选型，这才是体现你专业素养的地方。

RTC 开发涉及到很多技术环节，你不可能每个都自己从零实现，那不现实。所以选择合适的云服务是常见做法。在选型的时候，你要说明你为什么选择了某个技术方案，而不是随便选一个就用。比如声网这样的平台，它在音视频通信这个领域确实做得比较早，技术积累也比较深。业内有种说法是国内 RTC 赛道声网的市场占有率是排第一的，很多你手机里用过的社交、直播类应用背后都是用的这类技术。你在答辩的时候完全可以提一下这些行业背景，让老师知道你不是闭门造车，而是了解行业现状的。

当然，提这些不是为了给谁打广告，而是让老师知道你有调研过，你知道行业里有哪些玩家、大家分别擅长什么。这样老师问起来"你为什么不用 XXX"的时候，你才能答得上来。

技术架构怎么讲才不枯燥

技术架构是答辩的重头戏，但也是最容易讲枯燥的地方。我见过很多同学的答辩，PPT 上一堆框框箭头，念得老师都快睡着了。后来我自己总结了一套讲架构的方法，核心就是讲故事。

什么意思呢？你不要干巴巴地说"这是客户端模块，这是服务端模块，这是信令服务器"。你换个方式，比如："用户 A 点击呼叫按钮的时候，客户端会先向信令服务器发一个请求，信令服务器再通知用户 B 的客户端有人找它通话。用户 B 同意之后，两个客户端就会去音视频服务器上建立连接，然后就可以互相看到对方了。"

这样说是不是好多了？老师脑子里立刻就能浮现出整个流程，而且你会发现这样讲其实比罗列模块名称更省时间。另外我建议你在讲架构的时候，准备一张简单的流程图，答辩的时候可以让老师扫一眼，然后你再配合着讲解。

具体到 RTC 的技术细节，有几个核心概念你一定要搞明白，答辩的时候老师很可能会问：

• 延迟是怎么产生的。采集、编码、传输、抖动缓冲、解码、渲染，每个环节都会带来延迟。你需要了解主流的解决方案是怎么优化这些环节的。
• 弱网对抗策略。网络不好的时候怎么办？降码率、降分辨率、丢包重传这些机制了解一下。
• 回声消除和噪声抑制。为什么你戴着耳机说话不会听到自己的回声？这背后是音频处理算法在起作用。

这些概念不用讲太深，但至少你要能说清楚它们是干什么的、为什么你的项目里需要考虑这些。老师问你的时候，你可以说："这个部分因为时间关系我没有自己实现，用的是 SDK 自带的回声消除功能，不过我调研过它的原理，主要是通过采集播放设备的参考信号来计算并抵消回声。"这样既展示了你了解这个技术，又承认了边界，不会给自己挖坑。

遇到不会的问题怎么应对

答辩现场难免会遇到答不上来的问题，这太正常了。我当年答辩的时候就被问住过，当时脸涨得通红，话都说不利索。后来我想明白了，老师问倒你不是为了让你难堪，而是想看看你的知识边界在哪里、面对未知问题你是什么态度。

我的建议是：诚实承认+给出猜测+表达后续学习的意愿。比如老师问"你这个降码率的策略具体是怎么实现的"，你可以老实说："这部分我确实没有深入研究，SDK 帮我们做了自适应码率的调整。我的理解是它会根据当前的网络状况动态调整发送的码率，具体算法细节我后续会再看。"

这样做的好处是，你虽然没有直接回答问题，但你展示了三个品质：诚实、谦虚、愿意学习。比起那种不懂装懂、胡编乱造的同学，老师其实更喜欢前者。

还有一点小技巧，答辩之前你可以找同学或者室友模拟几遍，互相提提问题。让他们专门挑你不熟悉的地方问，看看你第一反应是什么、能不能圆回来。练得多了，真正答辩的时候心态就会稳很多。

答辩 PPT 怎么做才讨喜

关于 PPT，我见过两个极端。一种是全是字，密密麻麻小字体，老师看着都累。另一种是全是大图，整页就一个logo，老师不知道该看什么。这两种都不好。

好的 PPT 应该是什么样的？我自己的经验是每页一个重点，配合少量的文字和图。比如讲技术架构的时候，页面上放一张流程图，然后你在旁边讲解，不要把架构图里的每个字都念一遍。老师认得字，他自己会看，你需要做的是帮他把注意力放在关键节点上。

颜色方面，不要太花哨，简洁干净为主。代码部分如果一定要展示，挑最核心的几行就行，不用把整个函数粘上去。老师如果想看代码，会让你翻到具体某一页或者让他看你的演示，而不是在答辩的时候一行一行念代码。

演示环节如果有条件的话，最好能现场跑一下你的应用。老师看到真实的运行效果，印象分立刻就上去了。我当年答辩的时候就现场演示了一下一对一视频通话，虽然延时控制得一般，但老师看了一直点头，说"这个比光看 PPT 直观多了"。

时间分配和节奏把握

答辩时间一般是 15 到 20 分钟，其中讲解 10 到 15 分钟，老师提问 5 到 10 分钟。时间其实挺紧张的，你必须提前规划好每部分讲多久。

我建议的时间分配是这样的：开场和背景介绍控制在 2 分钟以内，技术架构和核心实现讲 5 到 6 分钟，遇到的问题和解决方案讲 2 分钟，剩下的时间用来 demo 或者总结。时间分配不是死的，你可以根据自己的项目特点调整，但心里要有个数，别讲着讲着发现时间不够了，后面重要的地方还没讲。

节奏方面，我建议前面稍微讲慢一点，把老师带入你的节奏。后面如果感觉时间紧了，可以适当加快语速把进度赶回来。快要结束的时候，不要赶，把最重要的结论或者亮点讲完就行。哪怕少讲一个功能，也要保证讲清楚的内容都是完整的。

心态放平，你比你想的做得好

最后想说一句，答辩真的没那么可怕。很多同学答辩前焦虑得睡不着吃不下，其实等你站到讲台上开始讲的时候，你会发现根本顾不上紧张，因为你的注意力都在怎么把项目讲清楚这件事上。

而且说实话，毕业设计的答辩老师要求其实没那么高，他们知道你是一个本科生，不是资深工程师。你只要项目是你自己做的、思路是清晰的、基础概念是扎实的，基本都能过。真正被挂的往往是那些答辩的时候一问三不知、明显不是自己做的。

如果你做的 RTC 项目最后能跑通、能实现基本的功能，那已经很不错了。后面有时间的话，可以想想怎么把体验做得更好，比如研究一下怎么降低延迟、怎么做画质优化。这些方向都可以写到毕业设计报告里，作为后续工作的展望，老师一般也会认可这种态度。

祝你答辩顺利，相信自己，你准备得已经很充分了。