通知设置 新通知
【有奖调研】Geek Online 2020 编程挑战赛参赛调研 置顶
放肆小青年 回复了问题 • 28 人关注 • 27 个回复 • 437 次浏览 • 2 天前
“这些项目不是什么赚大钱的项目，但是它们足够有趣。”丨关于 Geek Online 2020 编程挑战赛，选手们如是说
梅川酷子 发表了文章 • 0 个评论 • 12 次浏览 • 1 天前
Geek Online 2020 编程挑战赛是融云 面向全球 IM 和 RTC 开发者、编程爱好者与极客举办的一场在线黑客马拉松。融云作为全球领先的互联网通信云厂商，一直致力于 IM 和 RTC 技术的创新和发展，希望与全球开发者一道，共同寻找 IM 和 RTC 技术的更多落地场景，开辟更多使用途径。
这次比赛中取得的成绩，对于这些参赛选手来说都只是个开始，但正如他们所说，Geek Online 2020 编程挑战赛的这一经历，一定会是他们人生中的一次宝贵经验。
Geek Online 2020 编程挑战赛虽然是第一次举办，但已经收获了参赛选手以及观看决赛路演直播观众们的一致好评，融云作为专注于通信的 PaaS 云服务平台，想要通过底层的基础模块支持，帮助企业与开发者构建「云通信」的能力。
举办此次编程挑战赛的目的，也是希望让开发者们碰撞出技术的思维火花，加速潮流技术的应用创新，也为开发者们搭建了一个沟通、交流、合作的平台，希望能够掀起一股通信技术应用的探索与实践热潮。
也希望全球 IM 和 RTC 开发者、编程爱好者与极客
2 个月激烈角逐，15 支队伍突围决赛路演！Geek Online 2020 编程挑战赛完美收官！
梅川酷子 发表了文章 • 0 个评论 • 8 次浏览 • 1 天前
iOS 性能优化：优化 App 启动速度
大神庵 发表了文章 • 0 个评论 • 13 次浏览 • 2 天前
作者：Damonwong，iOS 开发者
来源公众号丨老司机技术周报（ID：LSJCoding）
Sessions: https://developer.apple.com/videos/play/wwdc2019/423/
苹果是一家特别注重用户体验的公司，过去几年一直在优化 App 的启动时间，特别是去年的 WWDC 2019 keynote[1] 上提到，在过去一年苹果开发团队对启动时间提升了 200%
虽然说是提升了 200%，但是有些问题还是没有说清楚，比如：
为什么优化了这么多时间？
作为开发者的我们，我们还可以做哪些针对启动速度的优化？
所以我们今天结合 WWDC2019 - 423 - Optimizing App Launch[2] 聊一下和启动相关的东西
名词解释
先介绍一些和启动相关的名词。
Mach-O
Mach-O 是 iOS 系统不同运行时期可执行的文件的文件类型统称。主要分以下三类:
Executable - 可执行文件，是 App 中的主要二进制文件
Dylib - 动态库，在其他平台也叫 DSO 或者 DLL
Bundle - 苹果平台特有的类型，是无法被连接的 Dylib。只能在运行时通过 dlopen() 加载
Mach-O 的基本结构如下图所示，分为三个部分：
Header 包含了 Mach-O 文件的基本信息，如 CPU 架构，文件类型，加载指令数量等
Load Commands 是跟在 Header 后面的加载命令区，包含文件的组织架构和在虚拟内存中的布局方式，在调用的时候知道如何设置和加载二进制数据
Data 包含 Load Commands 中需要的各个 Segment 的数据。
绝大多数 Mach-O 文件包括以下三种 Segment：
__TEXT - 代码段，包括头文件、代码和常量。只读不可修改。
__DATA - 数据段，包括全局变量, 静态变量等。可读可写。
__LINKEDIT - 如何加载程序, 包含了方法和变量的元数据（位置，偏移量），以及代码签名等信息。只读不可修改。
Image
指的是 Executable，Dylib 或者 Bundle 的一种。
Framework
有很多东西都叫做 Framework，但在本文中，Framework 指的是一个 dylib，它周围有一个特殊的目录结构来保存该 dylib 所需的文件。
虚拟内存（Virtual Memory）
虚拟内存是建立在物理内存和进程之间的中间层。是一个连续的逻辑地址空间，而且逻辑地址可以没有对应的实际物理内存地址，也可以让多个逻辑地址对应到一个物理内存地址上。
Page Fault
当进程访问一个没有对应物理地址的逻辑地址时，会发生 Page Fault
Lazy Reading
某个想要读取的页没有在内存中就会触发 Page Fault，系统通过调用 mmap() 函数读取指定页，这个过程叫做 Lazy Reading
COW（Copy-On-Write）
当进程需要对某一页内容进行修改时，内核会把需要修改的部分先复制一份，然后再修改，并把逻辑地址重新映射到新的物理内存去。这个过程叫做 Copy-On-Write
Dirty Page & Clean Page
Image 加载后，被修改过内容的 Page 叫做 Dirty Page，会包含着进程特定的信息。与之相对的叫 Clean Page，可以从磁盘重新生成。
共享内存（Share RAM）
当多个 Mach-O 都依赖同一个 Dylib（eg. UIKit）时，系统会让这几个 Mach-O 的调用 Dylib 的逻辑地址都指向同一块物理内存区域，从而实现内存共享。Dirty Page 为进程独有，不能被共享。
地址空间布局随机化（ASLR）
当 Image 加载到逻辑地址空间的时候，系统会利用 ASLR 技术，使得 Image 的起始地址总是随机的，以避免黑客通过起始地址+偏移量找到函数的地址
当系统利用 ASLR 分配了随机地址后，从 0 到该地址的整个区间会被标记为不可访问，意味着不可读，不可写，不可被执行。这个区域就是 __PAGEZERO 段，它的大小在 32 位系统是 4KB+，而在 64 位系统是 4GB+
代码签名（Code Sign）
代码签名可以让 iOS 系统确保要被加载的 Image 的安全性，用 Code Sign 设置签名时，每页内容都会生成一个单独的加密散列值，并存储到 __LINKEDIT 中去，系统在加载时会校验每页内容确保没有被篡改。
dyld（dynamic loader）
dyld 是 iOS 上的二进制加载器，用于加载 Image。有不少人认为 dyld 只负责加载应用依赖的所有动态链接库，这个理解是错误的。dyld 工作的具体流程如下：参考：dyld启动流程[3]
Load dylibs
dyld 在加载 Mach-O 之前会先解析 Header 和 Load Commands, 然后就知道了这个 Mach-O 所依赖的 dylibs，以此类推，通过递归的方式把全部需要的 dylib 都加载进来。
一般来说，一个 App 所依赖的 dylib 在 100 - 400 左右，其中大多数都是系统的 dylib，因为有缓存和共享的缘故，读取速度比较高。
Fix-ups
因为 ASLR 和 Code Sign 的原因，刚被加载进来的 dylib 都处于相对独立的状态，为了把它们绑定起来，需要经过一个 Fix-ups 过程。Fix-ups 主要有两种类型：Rebase 和 Bind。
PIC（Position Independent Code）
因为代码签名的原因，dyld 无法直接修改指令，但是为了实现在运行时可以 Fix-ups，在 code gen 时，通过动态 PIC（Position Independent Code）技术，使本来因为代码签名限制不能再修改的代码，可以被加载到间接地址上。当要调用一个方法时，会先在 __DATA 段中建立一个指针指向这个方法，再通过这个指针实现间接调用。
Rebase
Rebase 就是针对“因为 ASLR 导致 Mach-O 在加载到内存中是一个随机的首地址”这一个问题做一个数据修正的过程。会将内部指针地址都加上一个偏移量，偏移量的计算方法如下：
Slide = actual_address - preferred_address
所有需要 Rebase 的指针信息已经被编码到 __LINKEDIT 里。然后就是不断重复地对 __DATA 中需要 Rebase 的指针加上这个偏移量。这个过程中可能会不断发生 Page Fault 和 COW，从而导致 I/0 的性能损耗问题，不过因为 Rebase 处理的是连续地址，所以内核会预先读取数据，减少 I/O 的消耗。
Binding
Binding 就是对调用的外部符号进行绑定的过程。比如我们要使用到 UITableView，即符号 _OBJC_CLASS_$_UITableView, 但这个符号又不在 Mach-O 中，需要从 UIKit.framework 中获取，因此需要通过 Binding 把这个对应关系绑定到一起。
在运行时，dyld 需要找到符号名对应的实现。而这需要很多计算，包括去符号表里找。找到后就会将对应的值记录到 __DATA 的那个指针里。Binding 的计算量虽然比 Rebasing 更多，但实际需要的 I/O 操作很少，因为之前 Rebasing 已经做过了。
dyld2 & dyld3
在 iOS 13 之前，所有的第三方 App 都是通过 dyld 2 来启动 App 的，主要过程如下：
解析 Mach-O 的 Header 和 Load Commands，找到其依赖的库，并递归找到所有依赖的库
加载 Mach-O 文件
进行符号查找
绑定和变基
运行初始化程序
上面的所有过程都发生在 App 启动时，包含了大量的计算和I/O，所以苹果开发团队为了加快启动速度，在 WWDC2017 - 413 - App Startup Time: Past, Present, and Future[4] 上正式提出了 dyld3。
dyld3 被分为了三个组件：
一个进程外的 MachO 解析器
预先处理了所有可能影响启动速度的 search path、@rpaths 和环境变量
然后分析 Mach-O 的 Header 和依赖，并完成了所有符号查找的工作
最后将这些结果创建成了一个启动闭包
这是一个普通的 daemon 进程，可以使用通常的测试架构
一个进程内的引擎，用来运行启动闭包
这部分在进程中处理
验证启动闭包的安全性，然后映射到 dylib 之中，再跳转到 main 函数
不需要解析 Mach-O 的 Header 和依赖，也不需要符号查找。
一个启动闭包缓存服务
系统 App 的启动闭包被构建在一个 Shared Cache 中， 我们甚至不需要打开一个单独的文件
对于第三方的 App，我们会在 App 安装或者升级的时候构建这个启动闭包。
在 iOS、tvOS、watchOS中，这这一切都是 App 启动之前完成的。在 macOS 上，由于有 Side Load App，进程内引擎会在首次启动的时候启动一个 daemon 进程，之后就可以使用启动闭包启动了。
dyld 3 把很多耗时的查找、计算和 I/O 的事前都预先处理好了，这使得启动速度有了很大的提升。
App 启动
介绍完上面这一大堆名词之后，我们正式进入主题。
App 启动为什么这么重要？
App 启动是和用户的第一个交互过程，所以要尽量缩短这个过程的时间，给用户一个良好的第一印象
启动代表了你的代码的整体性能，如果启动的性能不好，其他部分的性能可能也不会太好
启动会占用 CPU 和内存，从而影响系统性能和电池
所以我们要好好优化启动时间。
启动类型
App 的启动类型分为三类
Cold Launch 也就是冷启动，冷启动需要满足以下几个条件：
重启之后
App 不在内存中
没有相关的进程存在
Warm Launch 也就是热启动，热启动需要满足以下几个条件：
App 刚被终止
App 还没完全从内存中移除
没有相关的进程存在
Resume Launch 指的是被挂起的 App 继续的过程，需要满足以下几个条件：
App 被挂起
App 还全部都在内存中
还存在相关的进程
App 启动阶段
App 启动分为三个阶段
初始化 App 的准备工作
绘制第一帧 App 的准备工作及绘制（这里的第一帧并不是获取到数据之后的第一帧，可以是一张占位视图），这时候用户与App已经可以交互了，比如 tabbar 切换
获取到页面的所有数据之后的完整的绘制第一帧页面
在这个地方，苹果再次强调了一下，建议「用户从点击 App 图标到可以再次交互，也就是第二阶段结束」的时间最好在 400ms 以内。目前来看，大部分 App 都没有达到这个目标。
下面，我们把上面三个阶段分成下面这 6 个部分，讲一下这几个阶段做了什么以及有什么可以优化的地方。
System Interface
初始化 App 的准备工作，系统主要做了两个事情：Load dylibs 和 libSystem init
在 2017 年苹果介绍过 dyld3 给系统 App 带来了多少优化，今年 dyld3 正式开发给开发者使用，这意味着 iOS 系统会将你热启动的运行时依赖给缓存起来。以达到减少启动时间的目的。这也就是提升 200% 的原因之一。
视频中只说优化了热启动时间，理论上对于 iOS 系统来说 dyld3 应该还可以优化冷启动时间，所以不知道是因为给 iPad 增加了多任务功能的原因，还是没有把所有功能开放的原因，作者只提了热启动这个原因暂时还不太清楚。
除此之外，在 Load dylibs 阶段，开发者还可以做以下优化：
避免链接无用的 frameworks，在 Xcode 中检查一下项目中的「Linked Frameworks and Librares」部分是否有无用的链接。
避免在启动时加载动态库，将项目的 Pods 以静态编译的方式打包，尤其是 Swift 项目，这地方的时间损耗是很大的。
硬链接你的依赖项，这里做了缓存优化。
也许有人会困惑是不是使用了 dyld3 了，我们就不需要做 Static Link 了，其实还是需要的，感兴趣的可以看一下 Static linking vs dyld3[5] 这篇文章，里面有一个详细的数据对比。
libSystem init 部分，主要是加载一些优先级比较低的系统组件，这部分时间是一个固定的成本，所以我们开发人员不需要关心。
Static Runtime Initializaiton
这个阶段主要是 Objective-C 和 Swift Runtime 的初始化，会调用所有的 +load 方法，将类的信息注册到 runtime 中。
在这个阶段，原则上不建议开发者做任何事情，所以为了避免一些启动时间的损耗，你可以做以下几个事情：
在 framework 开发时，公开专有的初始化 API
减少在
+load中做的事情使用
initialize进行懒加载初始化工作
UIKit Initializaiton
这个阶段主要做了两个事情：
实例化 UIApplication 和 UIApplicationDelegate
开始事件处理和系统集成
所以这个阶段的优化也比较简单，你需要做两个事情：
最大限度的减少 UIApplication 子类初始化时候的工作，更甚至与不子类化 UIApplication
减少 UIApplicationDelegate 的初始化工作
Application Initializaiton
这个阶段主要是生命周期方法的回调，也正是开发者最熟悉的部分。
调用 UIApplicationDelegate 的 App 生命周期方法：
application:willFinishLaunchingWithOptions:
application:didFinishLaunchingWithOptions:
和 UIApplicationDelegate 的 UI 生命周期方法：
applicationDidBecomeActive:
同时，iOS 13 针对 UISceneDelegate 增加了新的回调：
scene:willConnectToSession:options:
sceneWillEnterForeground:
sceneDidBecomeActive:
也会在这个阶段调用。感兴趣的可以关注一下 Getting the Most out of Multitasking 这个 Session，暂时没有视频资源，怀疑是现场演示翻车了，所以没有把视频资源放出来。
在这个阶段，开发者可以做的优化：
推迟和启动时无关的工作
Senens 之间共享资源
Fisrt Frame Render
这个阶段主要做了创建、布局和绘制视图的工作，并把准备好的第一帧提交给渲染层渲染。会频繁调用以下几个函数：
loadView
viewDidLoad
layoutSubviews
在这个阶段，开发者可以做的优化：
减少视图层级，懒加载一些不需要的视图
优化布局，减少约束
更多细节可以从 WWDC2018 - 220 - High Performance Auto Layout[6] 中了解
Extend
大部分 App 都会通过异步的方式获取数据，并最终呈现给用户。我们把这一部分称为 Extend。
因为这一部分每个 App 的表现都不一样，所以苹果建议开发者使用 os_signpost 进行测量然后慢慢分析慢慢优化。
测量 App 启动时间
要找到启动过程中的问题，就要进行多次测量并前后比较。但是如果变量没有控制好，就会导致误差。
所以为了保证测量的数据能够真实的反应问题，我们要减少不稳定性因素，保证在可控的相近的环境下进行测量。最后使用一致的结果来分析。
条件一致性
为了保证环境一致，我们可以做下面这几个事情:
重启手机，并等待 2-3 分钟
启用飞行模式或者使用模拟网络
不使用或者不变更 iCloud 的账户
使用 release 模式进行 build
测量热启动时间
iColud 账户切换会影响性能，所以不要切换账号或者不开启 iCloud。
测量注意点
尽可能的使用具有代表性的数据进行测试
如果不使用具有代表性的数据进行测试，就会出现偏差
使用不同的新旧设备进行测试
最后你还可以使用 XCTest 来测试，多运行几次，取平均结果
关于使用 XCTest 测试启动时间的信息，可以看一下 WWDC2019 - 417 - Improving Battery Life and Performance[7]，但是我测试了一下，目前好像还有一部分 API 还没有开放出来，暂时还不能使用。
使用 Instruments 分析和优化 App 启动过程
优化方式
苹果给了我们三个优化方式的建议，整体思想和前面提到的各个阶段的优化差不多
Minimize Work
推迟与第一帧无关的工作
从主线程移开阻塞工作
减少内存使用量
Prioritize Work
定义好任务的优先级。
利用好 GCD 来优化你的启动速度。
让重要的事情保持优先
更深入的了解有关 GCD 的内容，可以看一下 WWDC2017 - 706 - Modernizing Grand Central Dispatch Usage[8]
Optimize Work
简化现有工作，比如只请求必要的数据。
优化算法和数据结构
缓存资源和计算
使用 Instruments 分析 App 启动过程
当知道如何优化之后，我们需要针对我们的启动过程进行分析。Xcode 11 的 Instruments 为此新增了一个 App launch 模板，让开发者可以更好的分析自己 App 的启动速度。
运行后可以看到各个阶段的具体时间，根据数据进行优化，还能看到耗时的函数调用。
系统优化
去年苹果做了很多优化，下面这几个高亮的是和启动速度有关的优化
但是不知道是不是时间原因，在 session 中对于这部分的解释特别少，很难理解 200% 到底做了什么。
但是 Craig Federighi 在 The Talk Show Live From WWDC 2019, With Craig Federighi and Greg Joswiak[9] 中针对为什么优化了 200% 说了这样一段话：
Isn’t that crazy that was quite a discovery for us. No it turns out that over times as in terms of the way the apps were encrypted and the way fair play worked and so forth. The encryption became part of the critical path actually of launching the apps. I mean the processors are capable or up and through the thing that actually it was a problem. And then there are other optimizations that based on what was visible to system at certain things. And so it actually cut out optimization opportunities and so when we really identified that opportunity we said okay. We can actually come up with better format that’s gonna eliminate that being on the critical path, It’s going to enable all these pre-binding things. And then we did a whole bunch of other work to optimize the objective-c runtime to optimize the linker the dynamic linker a bunch of other things and you put it all together. And yeah that I mean a cold launch this is we’ve never had a win like this to launch time in a single release.
从这段话中，除了 dyld3 的功劳之外，减少对代码签名加密也是优化之一。
监控线上用户 App 的启动
Xcode 11 在 Xcode Organizer 新增了一个监控面板，在这个面板里面可以查看多个维度的用户数据，其中还包括平均启动时间。
当你通过 Instruments 分析完你的启动过程，并做了大量优化之后，你就可以通过 Xcode Organizer 来分析你这次优化效果到底怎么样。
当然你可以通过去年新出的 MetricKit[10] 获取一些自定义的数据，具体参照 WWDC2019 - 417 -Improving Battery Life and Performance[11]
总结
今年苹果提的很多优化建议其实在早几年都已经说过一遍了，属于老生常谈了。但是值得点赞的是新出的 Instruments 的 App launch 和 Xcode Organizer 的性能监控。
启动优化是一个需要经常反复做的事情，越早发现问题，越容易解决问题，如果你想给你的用户一个良好的第一印象，就赶快行动起来吧。
参考资料
[1]
WWDC 2019 keynote: https://developer.apple.com/videos/play/wwdc2019/101/
[2]
WWDC2019 - 423 - Optimizing App Launch: https://developer.apple.com/videos/play/wwdc2019/423/
[3]
dyld启动流程: https://leylfl.github.io/2018/05/28/dyld启动流程/
[4]
WWDC2017 - 413 - App Startup Time: Past, Present, and Future: https://developer.apple.com/videos/play/wwdc2017/413/
[5]
Static linking vs dyld3: https://allegro.tech/2018/05/Static-linking-vs-dyld3.html
[6]
WWDC2018 - 220 - High Performance Auto Layout: https://developer.apple.com/videos/play/wwdc2018/220/
[7]
WWDC2019 - 417 - Improving Battery Life and Performance: https://developer.apple.com/videos/play/wwdc2019/417/
[8]
WWDC2017 - 706 - Modernizing Grand Central Dispatch Usage: https://developer.apple.com/videos/play/wwdc2017/706/
[9]
The Talk Show Live From WWDC 2019, With Craig Federighi and Greg Joswiak: https://daringfireball.net/2019/06/the_talk_show_live_from_wwdc_2019
[10]
MetricKit: https://developer.apple.com/documentation/metrickit
[11]
WWDC2019 - 417 -Improving Battery Life and Performance: https://developer.apple.com/videos/play/wwdc2019/417/
一个APP如何适配多个Andiroid终端？
大兴 发表了文章 • 0 个评论 • 19 次浏览 • 6 天前
响应式的核心是拉通多终端的适配规则，开发一套界面，一个APP兼容多尺寸终端设备的显示，能够根据用户的行为以及设备的环境(屏幕尺寸、屏幕方向、是否分屏等)进行相应的页面布局以及容器尺寸的调整，为用户提供更加舒适的界面和更好的用户体验。
1 响应式SDK
2 加载流程设计
用户请求数据
屏幕尺寸发生变化
3 架构设计
优酷统一架构和响应式SDK，提供响应式架构能力。
响应式页面布局、响应式容器布局，提供响应式参考实现。
4 数据二次加工
数据过滤
数据映射
数据合并
数据补全
分屏模式：
折叠屏：
获取响应式状态
6 容器响应式
容器适配列数、尺寸的效果
列数适配
响应式适配后的列数 = 当前屏幕宽度÷(标准屏幕宽度÷标准屏幕宽度下的组件列数 )
适配效果：
控件尺寸适配
X-Meetup | 与大咖共同探索云原生技术领导力最新实践！
belonemily 发表了文章 • 0 个评论 • 22 次浏览 • 6 天前
活动详情
前端音视频之WebRTC初探
大兴 发表了文章 • 0 个评论 • 18 次浏览 • 6 天前
今天，我们来一起学习一下 WebRTC，相信你已经对这个前端音视频网红儿有所耳闻了。
WebRTC Web Real-Time Communication 网页即时通信
WebRTC 于 2011 年 6 月 1 日开源，并在 Google、Mozilla、Opera 等大佬们的支持下被纳入 W3C 推荐标准，它给浏览器和移动应用提供了即时通信的能力。
WebRTC 优势及应用场景
优势
跨平台(Web、Windows、MacOS、Linux、iOS、Android) 实时传输 音视频引擎 免费、免插件、免安装 主流浏览器支持 强大的打洞能力
应用场景
在线教育、在线医疗、音视频会议、即时通讯工具、直播、共享远程桌面、P2P网络加速、游戏(狼人杀、线上KTV)等。
（有喜欢玩狼人杀的同学吗？有时间可以一起来一局，给我一轮听发言的时间，给你裸点狼坑，一个坑容错。）
WebRTC 整体架构
拉回来，我们看一看 WebRTC 的整体架构，我用不同的颜色标识出了各层级所代表的含义。
Web 应用 Web API WebRTC C++ API Session Management 信令管理 Transport 传输层 Voice Engine 音频引擎 Video Engine 视频处理引擎
我们再来看下核心的模块：
Voice Engine 音频引擎
VoIP 软件开发商 Global IP Solutions 提供的 GIPS 引擎可以说是世界上最好的语音引擎，谷歌大佬一举将其收购并开源，也就是 WebRTC 中的 音频引擎。
iSAC：WebRTC 音频引擎的默认编解码器，针对 VoIP 和音频流的宽带和超宽带音频编解码器。 iLBC：VoIP 音频流的窄带语音编解码器。 NetEQ For Voice：针对音频软件实现的语音信号处理元件。NetEQ 算法是自适应抖动控制算法以及语音包丢失隐藏算法，能够有效的处理网络抖动和语音包丢失时对语音质量产生的影响。 Acoustic Echo Canceler：AEC，回声消除器。 Noise Reduction：NR，噪声抑制。
Video Engine 视频处理引擎
VPx 系列视频编解码器是 Google 大佬收购 ON2 公司后开源的。
VP8：视频图像编解码器，WebRTC 视频引擎默认的编解码器。 Video Jitter Buffer：视频抖动缓冲器模块。 Image Enhancements：图像质量增强模块。
WebRTC 通信原理
媒体协商
媒体协商也就是让双方可以找到共同支持的媒体能力，比如双方都支持的编解码器，这样才能实现彼此之间的音视频通信。
SDP Session Description Protocal
媒体协商所交换的数据就是 SDP，说是协议，其实 SDP 并不是一个真正的协议，它就是一种描述各端“能力”的数据格式。
上图所示就是 SDP 的一部分，详细内容请参考：SDP: Session Description Protocol
https://tools.ietf.org/html/rfc4566
或者参考卡神的这篇文章：WebRTC：会话描述协议SDP
https://zhuanlan.zhihu.com/p/75492311
网络协商
ICE Interactive Connectivity Establishment 互动式连接建立
想要建立连接，我们要需要拿到双方 IP 和端口的信息，在当下复杂的网络环境下，ICE 统一了各种 NAT 穿越技术(STUN、TURN)，可以让客户端成功地穿透远程用户与网络之间可能存在的各类防火墙。
STUN、TURN
STUN：简单 UDP 穿透 NAT，可以使位于 NAT(或多重 NAT) 后的客户端找出自己的公网 IP 地址，以及查出自己位于哪种类型的 NAT 及 NAT 所绑定的 Internet 端口。
我们知道，NAT 主要有以下四个种类：
完全锥型 NAT IP 限制锥型 端口限制锥型 对称型
前三种都可以使用 STUN 穿透，而面对第四种类型，也是大型公司网络中经常采用的对称型 NAT ，这时的路由器只会接受之前连线过的节点所建立的连线。
那么想要处理这种网络情况，我们就需要使用 TURN (中继穿透 NAT) 技术。
TURN 是 STUN 的一个扩展，其主要添加了中继功能。在 STUN 服务器的基础上，再添加几台 TURN 服务器，如果 STUN 分配公网 IP 失败，则可以通过 TURN 服务器请求公网 IP 地址作为中继地址，将媒体数据通过 TURN 服务器进行中转。
信令服务器 Signal Server
拿到了双方的媒体信息(SDP)和网络信息(Candidate)后，我们还需要一台信令服务器作为中间商来转发交换它们。
信令服务器还可以实现一些 IM 功能，比如房间管理，用户进入、退出等。
小结
本文我们了解了 WebRTC 优势及应用场景、WebRTC 的整体架构及主要模块构成以及 WebRTC 的通信原理。这些基础知识和概念是需要我们牢记的，大家要记牢～
参考
《从 0 打造音视频直播系统》 李超 《WebRTC 音视频开发 React+Flutter+Go 实战》 亢少军 https://webrtc.github.io/webrtc-org/architecture/ https://developer.mozilla.org/zh-CN/docs/Web/API/WebRTC_API https://www.w3.org/TR/webrtc/
本文转自公众号“前端食堂”，作者霍语佳
未来 10 年，软件开发涨工资的 8 个 技术发展趋势
王叫兽 发表了文章 • 1 个评论 • 25 次浏览 • 2020-10-20 16:13
1、人工智能将继续占主导地位
2、Python预计会随着AI和Ml的发展而崛起
3、5G可能是为开发人员打开大门的下一个重要物种
最近对天气预报技术的关注
或
对覆盖范围不佳的吐槽
。不管面临的挑战如何，该技术都是有前途的，值得学习投资。
4、边缘和云计算的使用预计会上升
边缘计算
的潜力：一种分散式计算基础架构。边缘计算的高度分布式模型可能有助于克服云计算的缺点。这些发展可能是计算和工业的未来。
全球公共云服务收入
预计将从2278亿美元增长到2664亿美元。边缘计算预计将随着云计算功能的升级而增长。实际上，预计
全球Edge计算市场
将从2018年的14.7亿美元增长到2025年的268.4亿美元。
5、预计会有新突破的语言：Rust，TypeScript，Kotlin和Swift
增强能力
，
增强行业实力
，并将我们的重点转向解决人类问题。
StackOverflow研究
表明，到2020年，排名前四的现代编程语言将为Rust，TypeScript，Kotilin和Swift，其中Rust在过去四年中连续第四位。
6、 Kubernetes成为Mesos和Docker Swarm的胜利者
开发人员预测
，到2020年，我们将看到此流行应用程序的最佳实践和标准化的兴起。
7、Web框架：React继续发光
React
由于其灵活性和健壮性而受到许多人的
青睐
。
8、降低软件开发入门的门槛：会有越来越多的自学成才的程序员
又来？新增一门新的编程语言，真的学不动了
王叫兽 发表了文章 • 0 个评论 • 23 次浏览 • 2020-10-20 16:13
来自| 开源中国 编辑 | 可可
