server is too busy是什么意思，手机显示线路忙的原因？
可能是线路设置的问题，可以设置－通话设置－线路切换，一般选择线路1。
拨打电话注意事项：
1. 简单明了、语意清楚 。通话过程中要注意做到简单明了，尽量将语意表达清楚。说话时含含糊糊、口齿不清楚，很容易让通话对象感到不耐烦。尤其需要注意的是，不要在通话的同时，嘴里含着食物或其他东西。
2. 勿因人而改变通话语气 。不要因为对方身份的改变而改变通话语气，应该自始至终使用亲切平和的声音平等地对待客人。如果客人听到声音发生明显转变，心里很容易产生反感，从而认为打电话的人非常势利、没有教养。
3. 说话速度恰当、抑扬顿挫、流畅 。通话过程中要始终注意言谈举止，三思而后言。说话时速度要适当，不可太快，这样不但可以让对方听清楚所说的每一句话，还可以帮助说话人自我警醒，避免出现说错话而没及时发现的情况。另外，说话的语调尽量做到抑扬顿挫和流畅，给人舒服的感觉。
4. 最多让来电者稍候7秒钟 。根据欧美行为学家的统计，人的耐性是 7秒钟，7秒钟之后就很容易产生浮躁。因此，最多只能让来电者稍候7秒钟，否则对方很容易产生收线、以后再打的想法。如果让来电者等待，则需要说：“对不起，让您久等了。”
5. 私下与人交谈需按保留键 。在通话过程中，如果需要私下和其他人交谈时，注意按保留健，不要直接对着话筒跟其他人说话。否则，有些私下的交谈甚至对人的批评语言在不经意间就让客户听到了，对方很可能因此而不高兴。
6. 不要大声回答问题。通话过程中不要大声回答问题，不然将造成双方的疲劳。如果当时所处的空间声音嘈杂，则应该向客户致歉，并征求客户的意见，重新更换通话地点，或者留下电话号码稍后再拨。
7. 指明对象会议中，勿将电话转接至会场 。如果指定的通话对象正在参加会议，那就不应该将电话转接到会场中去。一般说来，参加会议的人比较容易出现弹性疲劳，不适合接听电话。在这种情况下，可以将所有的电话全部据实记录下来，等会议完毕之后再转交。
用4G信号或wifi进行抖音直播都会卡顿？
优化视频卡顿
造成播放端卡顿的原因主要有三种：
原因1：推流帧率太低
如果主播端手机性能较差，或者有很占 CPU 的后台程序在运行，可能导致视频的帧率太低。正常情况下 FPS 达到每秒15帧以上的视频流才能保证观看的流畅度，如果 FPS 低于10帧，可以判定为帧率太低，这会导致全部观众的观看体验都很卡顿。当然如果主播端画面本身变化就很少，如静态画面或 PPT 播放等场景，则不受该原因影响。
原因2：上传阻塞
主播的手机在推流时会源源不断地产生音视频数据，但如果手机的上传网速太小，那么产生的音视频数据都会被堆积在主播的手机里传不出去，上传阻塞会导致全部观众的观看体验都很卡顿。
国内运营商提供的宽带上网套餐中，下载网速虽然已经达到了10Mbps、20Mbps甚至是100Mbps、200Mbps，但上传网速却还一直限制的比较小，很多小城市的上行网速最快是512Kbps（也就是每秒最多上传64KB的数据）。
Wi-Fi 上网遵循 IEEE 802.11 规定的载波多路侦听和冲突避免标准，简言之就是一个 Wi-Fi 热点同时只能跟一个手机通讯，其它手机在跟热点通讯前都要先探测或询问自己是否能够通讯，所以一个 Wi-Fi 热点使用的人越多就越慢。同时 Wi-Fi 信号受建筑墙体的屏蔽干扰很严重，而一般的中国普通家庭很少在装修时考虑好 Wi-Fi 路由器和各个房间的信号衰减问题，可能主播本人也不清楚自己做直播的房间离家里的路由器究竟穿了几堵墙。
原因3：下行不佳
就是观众的下载带宽跟不上或者网络很波动，例如直播流的码率是2Mbps的，也就是每秒钟有2M比特的数据流要下载下来，但如果观众端的带宽不够，就会导致观众端体验非常卡顿。 下行不佳只会影响当前网络环境下的观众。
查看SDK状态提示信息
如果您使用的是腾讯云移动直播 SDK 来推流，该 SDK 提供了一种状态反馈机制，每隔1秒 - 2秒就会将内部各种状态参数反馈出来，您可以通过注册 TXLivePushListener 监听器来获取这些状态。相关状态的说明如下：
推流状态 含义说明
NET_STATUS_CPU_USAGE 当前进程的 CPU 使用率和本机总体的 CPU 使用率。
NET_STATUS_VIDEO_FPS 当前视频帧率，也就是视频编码器每条生产了多少帧画面。
NET_STATUS_NET_SPEED 当前的发送速度，单位：kbps。
NET_STATUS_VIDEO_BITRATE 当前视频编码器输出的比特率，也就是编码器每秒生产了多少视频数据，单位： kbps。
NET_STATUS_AUDIO_BITRATE 当前音频编码器输出的比特率，也就是编码器每秒生产了多少音频数据，单位：kbps。
NET_STATUS_CACHE_SIZE 音视频数据堆积情况，这个数字超过个位数，即说明当前上行带宽不足以消费掉已经生产的音视频数据。
NET_STATUS_CODEC_DROP_CNT 全局丢包次数，为了避免延迟持续恶性堆积，SDK 在数据积压超过警戒线以后会主动丢包，丢包次数越多，说明网络问题越严重。
NET_STATUS_SERVER_IP 连接的推流服务器的 IP，一般应该是离客户端跳数比较少的就近服务器。
解决帧率太低问题
1. 帧率太低的评判
通过 移动直播 SDK 的 TXLivePushListener 的 VIDEO_FPS 的状态数据，我们可以获得当前推流的视频帧率。正常来说每秒15帧以上的视频流才能保证观看的流畅度，常规推流如果 FPS 在10帧以下，观众就会明显的感到画面卡顿。
2. 针对性优化方案
2.1 观察 CPU_USAGE 的大小
通过移动直播 SDK 的 TXLivePushListener 的 CPU_USAGE 的状态数据，我们可以获得当前推流 SDK 的 CPU 占用情况和当前系统的 CPU 占用情况。如果当前系统的整体 CPU 使用率超过80%，那么视频的采集和编码都会受到影响，无法正常发挥作用；如果 CPU 使用率达到100%，那么主播端本身就已经很卡，观众端要有流畅的观看体验显然是不可能的。
2.2 确认谁在消耗 CPU
一款直播 App 中使用 CPU 的不可能只有 推流 SDK，弹幕、飘星、文本消息互动等都有可能会消耗一定的 CPU，这些都是不可避免的。如果单纯要测试推流 SDK 的 CPU 占用情况，可以使用我们的 精简版 DEMO 来观察和评估。
2.3 不盲目追高分辨率
过高的视频分辨率并不一定能带来清晰的画质：首先，较高的分辨率要配合较高的码率才能发挥效果，低码率高分辨的清晰度很多时候比不上高码率低分辨率。其次，像1280 x 720这样的分辨率在平均5寸左右的手机屏幕上并不能看出优势，要想跟960 x 540的分辨率拉开差距，只有在 PC 上全屏观看才能有明显的感官差异。但较高的分辨率会显著提升 SDK 的 CPU 使用率，因此常规情况下推荐使用 移动直播 SDK 中 TXLivePusher 的 setVideoQuality 设置高清档即可，盲目追高分辨率有可能达不到预期的目标。
2.4 适当使用硬件加速
现在的智能手机都支持硬件编码来降低视频编码对 CPU 的依赖，如果您发现您的 App 的 CPU 使用率过高，可以开启硬件编码来降低 CPU 使用率。TXLivePusher 的 setVideoQuality 的高清档默认使用的是软件编码（硬件编码在部分 Android 手机上的编码效果不佳，马赛克感很强），如果要使用硬件编码，可以使用 TXLivePushConfig 的 enableHWAcceleration 选项开启。
解决上传阻塞问题
据统计，视频云客户群80%以上的直播间卡顿问题，均是由于主播端上传阻塞所致。
1. 上传阻塞的评判
1.1：BITRATE 与 NET_SPEED 的关系
BITRATE( = VIDEO_BITRATE + AUDIO_BITRATE ) 指的是编码器每秒产生了多少音视频数据要推出去，NET_SPEED 指的是每秒钟实际推出了多少数据，所以如果 BITRATE == NET_SPEED 的情况是常态，则推流质量会非常良好；而如果 BITRATE >= NET_SPEED 这种情况的持续时间比较长，推流质量就很难有什么保障。
1.2：CACHE_SIZE 和 DROP_CNT 的数值
BITRATE >= NET_SPEED 的情况一旦出现，编码器产生的音视频数据就会在主播的手机上积压起来，积压的严重程度以 CACHE_SIZE 这个状态值展示出来，如果 CACHE_SIZE 超过警戒线，SDK 会主动丢弃一些音视频数据，从而触发 DROP_CNT 的增长。下图所示就是一个典型的上行阻塞，途中 CACHE_SIZE 始终在红色警戒线以上，说明上行网络不足以满足数据的传输需求，也就是上行阻塞严重：
说明：
您可以在【直播控制台】>【统计分析】里看到类似上图的图表。
2. 针对性优化方案
2.1 主动提示主播
对于注重清晰度的场景下，通过合适的 UI 交互提示主播“当前网络质量很糟糕，建议您拉近离路由器的距离，避免 Wi-Fi 穿墙”是最好的选择。
移动直播 SDK 的推流功能文档中有涉及事件处理的介绍，您可以利用它来做到这一点，推荐的做法是：如果 App 在短时间内连续收到移动直播 SDK 的多个 PUSH_WARNING_NET_BUSY 事件，则提示主播网络关注一下当前网络质量，因为对于上行阻塞这种情况而言，主播本人是没办法通过视频的表现感知到的，只能通过观众的提醒或者 App 的提醒来了解。
2.2 合理的编码设置
如下是我们推荐的编码设置（适合美女秀场，更多信息请参见 如何实现更好的画质），可以通过 TXLivePusher 里的 setVideoQuality 接口进行相应档位的设置：
档位 分辨率 FPS 码率 使用场景
标清 360 * 640 15 400kbps - 800kbps 如果您比较关注带宽成本，推荐选择该档位，画质会偏模糊，但带宽费用较高清档要低 60%。
高清（推荐） 540 * 960 15 1200kbps 如果您比较关注画质，推荐选择该档位，能确保绝大多数主流手机都能推出很清晰的画面。
超清 720 * 1280 15 1800kbps 慎用：如果您的场景多是小屏观看不推荐使用，如果是大屏幕观看且主播网络质量很好可以考虑。
优化播放端
1. 卡顿与延迟
如上图，下行网络的波动或者下行带宽不够，都会导致在播放过程中出现一段段的饥饿期（App 这段时间内拿不到可以播放的音视频数据）。如果想要让观看端的视频卡顿尽量少，就要尽可能地让 App 缓存足够多的视频数据，以保证它能平安度过这些“饥饿期”，但是 App 缓存太多的音视频数据会引入一个新的问题，即高延迟，这对互动性要求高的场景是很坏的消息，同时如果不做延迟修正和控制，卡顿引起的延迟会有累积效应，就是播放时间越久，延迟越高，延迟修正做得好不好是衡量一款播放器是否足够优秀的关键指标。所以延迟和流畅是一架天平的两端，如果过分强调低延迟，就会导致轻微的网络波动即产生明显的播放端卡顿。反之，如果过分强调流畅，就意味着引入大量的延迟（典型的案例就是 HLS（m3u8） 通过引入20秒 - 30秒的延迟来实现流畅的播放体验）。
2. 针对性优化方案
为了能够让您无需了解过多流控处理知识就能优化出较好的播放体验，腾讯云 移动直播 SDK 经过多个版本的改进，优化出一套自动调节技术，并在其基础上推出了三种比较优秀的 延迟控制方案：
自动模式：如果您不太确定您的主要场景是什么，可以直接选择这个模式。
说明：
把 TXLivePlayConfig 中的 setAutoAdjustCache 开关打开，即为自动模式。在该模式下播放器会根据当前网络情况，对延迟进行自动调节（默认情况下播放器会在1秒 - 5秒这个区间内自动调节延迟大小，您可以通过 setMinCacheTime 和 setMaxCacheTime 对默认值进行修改），以保证在足够流畅的情况下尽量降低观众跟主播端的延迟，确保良好的互动体验。
极速模式：主要适用于秀场直播等互动性高，并且对延迟要求比较苛刻的场景。
说明：
极速模式设置方法是 setMinCacheTime = setMaxCacheTime = 1s ，自动模式跟极速模式的差异只是 MaxCacheTime 有所不同 （极速模式的 MaxCacheTime 一般比较低，而自动模式的 MaxCacheTime 则相对较高 ），这种灵活性主要得益于 SDK 内部的自动调控技术，可以在不引入卡顿的情况下自动修正延时大小，而 MaxCacheTime 反应的就是调节速度：MaxCacheTime 的值越大，调控速度会越发保守，卡顿概率就会越低。
流畅模式：主要适用于游戏直播等大码率高清直播场景。
说明：
当把播放器中的 setAutoAdjustCache 开关关闭，即为流畅模式，在该模式下播放器采取的处理策略跟 Adobe Flash 内核的缓存出策略如出一辙：当视频出现卡顿后，会进入 loading 状态直到缓冲区蓄满，之后进入 playing 状态，直到下一次遭遇无法抵御的网络波动。默认情况下缓冲大小为5秒，您可以通过 setCacheTime 进行更改。
在延迟要求不高的场景下，这种看似简单的模式会更加可靠，因为该模式本质上就是通过牺牲一点延迟来降低卡顿率。
如何学习嵌入式？
我来发表一下我的观点。说下我的方法，适合在校大学生，大家有什么见解欢迎纠正讨论。
为什么说适合在校大学生呢，因为在校大学生时间充裕。而参加工作的人，时间就是金钱，与其花费太长时间自学，还不如报个培训班速成，但是培训班的缺点可能就是基础不牢（这个是个人见解，如有不同意见也可以看看我写的自学经历，根据自己的基础跳过相应的步骤即可）。
我认为学习任何东西都是需要分模块的。各个模块熟悉了最后串起来（个人经验）
提醒！！
提醒！！
提醒！！
玩嵌入式是有点费钱的。但是有舍有得，这个看你们自己把握了。
下面我说下我的方法
一、嵌入式分为几个模块（给自己学的勇气）
二、起步学什么（打基础）
三、进阶学什么（给自己坚持下去的动力）
一、嵌入式分几个模块
嵌入式分为软件、硬件（简单吧）。软件，其实可以分的更详细，但是我们不需要分这么详细，后面学习的过程中你就明白了。
二 、起步学什么
首先，你最好是计算机、电子、电气、微电子、电子信息、通信、自动化、信息工程等相关专业。
可能有人会问为什么必须这些专业。因为这些专业要么编程能力强，要么硬件基础很熟悉，学习嵌入式是天然的优势。比如自动化专业，他们学习过电路，模电，数电，电力电子这些课能让你们有牢固的硬件基础；还有C++，51单片机，微机让你们有一定的软件基础。特别是51单片机，一旦学会了，后面学习嵌入式会更容易。
接下来仔细说说如何起步（基础不劳，地动山摇）
第一步，你要懂得硬件的基本知识，这些硬件知识能帮你更好的理解51单片机的内部原理，硬件的管脚配置，引脚功能，更重要的是帮你理解放大电路，滤波电路等。（第三步推荐一本我认为比价好的关于51的书，里面有51的内部原理）这些懂了，在用51C语言写程序的时候就会发现so easy。至于为什么先学51呢，因为大学大部分还是开设51的课，再者51容易理解，教学视频丰富。
第二步，你要懂C/C++，c语言是学习嵌入式的灵魂。因为大学都开设有C课程，所以大家从C开始学会相对方便和节约时间。
第三步，有了相关基础后开始看51单片机系列的书（见下图），网上各种各样的视频多的很，对着网络上的视频学习，效果会更好。但是不能只学不练，买个开发板（当初我们是自己焊的），自己对着视频练习。理论和实际结合效果最好。
当然需要用到相应的烧录软件，和编程软件。我在这里统一说一下。
烧录软件就用STC-ISP（好用），编程的用KEIL c51（keil3也能用），后面玩32了再用KEIL5。
三、进阶学什么
第一步、51单片机玩差不多半个学期就行啦，半个学期够你掌握了，太长浪费时间。我们已经玩过51了，已经是大孩子了，哈哈哈。但是我们没有玩过32位的，直接上arm是不行的。
所以我们要开始学习32，其实32比51 简单的多，因为他们有丰富的库，各种库。市面上的教学资源非常非常的丰富，产品也比较成熟，某宝上面各种开发板（价格300以内），自己选一个买就行了。
其实你也可以跳过51学32，毕竟51太老了，太陈旧了，但是我觉得你学习51会帮你牢固知识，帮你形成写程序的习惯等。
学习32 的周期，根据自己情况安排，一般一个到一个半学期。
第二步、现在咱们对32比较了解了，轮到学习嵌入式系统了，对，没错就是系统，是不是很兴奋。。
想学习嵌入式系统Linux/WIN等 ，首先你需要买个arm学习版，在淘宝上面买的话，不太贵S3C2440，500+元。资料非常多，建议买arm9，因为ram11的资料太少，不适于自学。或者你们预算非常充足，可以考虑Cortex-A8/A9的开发板。
我相信你们学到这里已经有了自己的想法和见解了。到这个过程的时候，知乎上的大佬回答的很详细和网上的资源也非常丰富，多看看大家写的共同学习。
最后，做下总结
看懂电路图、看懂芯片手册（更牛皮的要求是会自己绘制PCB板，会器件选型，会自己调试自己设计板子，直至可以量产）
有编写，移植驱动的能力
懂内核的实现机制
懂C语言，C++等
下面列有详细的要求，你们自己把握下。
等到找工作的时候，有嵌入式硬件，嵌入式软件，嵌入式等，甚至可以触类旁通，要看你们的学习水平了， 哈哈哈。
嵌入式硬件要求：
1、熟练使用Allegro Cadence等EDA工具进行硬件原理图及PCB的设计，精通PCB布线流程、具备多层板布线经验规范及信号完整性分析，熟悉至少一种高速通信接口，如PCIE、SRIO、10GBE等。
2、精通嵌入式处理器设计，具有大型CPU或者DSP的板级硬件设计调试经验，例如P系列或者T系列PowerPC，C6678、C6655等DSP,以及FPGA设计经验者等。
3、负责硬件产品的需求调研、方案设计，熟练使用各类电子仪器仪表进行测试。
。。。。。。
嵌入式软件要求：
1、熟悉Linux操作系统内核，有Linux内核和驱动开发经验。
2、精通C/C++开发语言，shell脚本。
3、精通C语言，能独立编写、调试硬件驱动程序和功能程序。
4、熟悉多线程的开发，精通ucosII嵌入式系统移植、驱动和应用开发。
。。。。。。
嵌入式硬件的工作：
嵌入式软件的工作：
嵌入式的工作：
那你可以以“低端单片机-高端单片机-低端ARM-高端ARM”来学。我现在就是工作中用STM32，晚上回去自学ARM9。
启动Docker服务怎么指定使用的网桥？
你好，使用方法如下：
首先我们让ovsdb-server监听一个TCP端口：
ovs-appctl-tovsdb-serverovsdb-server/add-remoteptcp:6640
接下来，启动ovn-northd后台进程。这个进程负责将来自Docker的网络信息(存储在OVN_Northbound数据库中)转换成逻辑流存储于OVN_Southbound数据库。
/usr/share/openvswitch/scripts/ovn-ctlstart_northd
2、一次性配置
在每一个你打算创建容器的主机上，你需要运行以下的命令(如果你的OVS数据库被清空，你需要再次运行这个命令。除此之外，重复运行这个命令都是没有任何影响的)。
其他的主机可以通过$LOCAL_IP地址来访问到这个主机，它就相当于本地通道的端点。
$ENCAP_TYPE是指用户想使用的通道的类型。它可以是”geneve“或者”stt“。(注意，你的内核需要支持以上两个类型，用户可以通过运行以下命令来检测内核是否支持以上类型："llsmod|grep$ENCAP_TYPE")。
ovs-vsctlsetOpen_vSwitch.external_ids:ovn-remote="tcp:$CENTRAL_IP:6640"external_ids:ovn-encap-ip=$LOCAL_IPexternal_ids:ovn-encap-type="$ENCAP_TYPE"
最后，启动ovn-controller(你需要在每一次启动时运行以下命令)：
/usr/share/openvswitch/scripts/ovn-ctlstart_controller
3、启动OpenvSwitch网络驱动
在默认情况下，Docker使用Linux网桥，但它支持外扩展。为了替换Linux网桥，我们需要先启动OpenvSwitch驱动。
OpenvSwitch驱动使用了PythonFlask模块来监听Docker的网络API请求。因此，用户需要先安装Python的Flask模块。
easy_install-UpippipinstallFlask
在每一个你想要创建容器的主机上启动OpenvSwitch驱动：
ovn-docker-overlay-driver--detach
Docker内部包含了一些模块，这些模块拥有类似于OVN的逻辑交换机和逻辑端口的概念。请读者仔细阅读Docker的文档来查找相关的命令。这里我们给出了一些案例：
1)创建用户自己的逻辑交换机
下面的命令创建了一个名为”foo“的逻辑交换机，它的网段为”192.168.1.0/24”：
NID=`dockernetworkcreate-dopenvswitch--subnet=192.168.1.0/24foo`
2)显示已有逻辑交换机
dockernetworkls
你也可以通过以下命令从OVN的northbound数据库中查找到这个逻辑交换机：
ovn-nbctl--db=tcp:$CENTRAL_IP:6640lswitch-list
3)Docker创建逻辑端口，并且将这个端口附加到逻辑网络上
比如说，将一个逻辑端口添加到容器busybox的“foo”网络上：
dockerrun-itd--net=foo--name=busyboxbusybox
4)显示所有的逻辑端口
Docker现在并没有一个CLI命令来罗列所有的逻辑端口，但是你可以从OVN的数据库中找到它们：
ovn-nbctl--db=tcp:$CENTRAL_IP:6640lport-list$NID
5)用户也可以创建一个逻辑端口，并将它添加到一个运行中的容器上：
dockernetworkcreate-dopenvswitch--subnet=192.168.2.0/24bardockernetworkconnectbarbusybox
用户可以删除逻辑端口，或者将它们从运行容器上分离出来：
dockernetworkdisconnectbarbusybox
6)用户也可以删除逻辑交换机：
dockernetworkrmbar
如何在手机上安装linux？
首先，你的手机得是安卓手机(需要root)，然后去安装一款软件名字叫“linux Deploy”
这款软件安装好之后，我们再去安装一款“busyBox pro”这款软件。
这款软件主要集成了linux很多命令，软件下载安装好以后，点击进去点击安装，然后退出就可以。
安卓手机是用linux内核开发的，不多缺少了很多命令，所以我们需下载这款软件
接下来，打开linux Deploy，点击红色的标注，把界面需要更改成中文！
然后退出软件，重新点击进入软件，这样软件界面就变成中文了
接下来我们去配置软件
这样就可以了
