⑴ SRS RTMP 发布和播放代码解析
主程序启动后，会根据config判断是控制台模式还是后台运行模式，之后进入run_hybrid_server启动各种服务,rtmp,http,https,rtc等等服务；
SrsServerAdapter 各种服务器的适配，rtmp，http，https等，RtcServerAdapter 是webrtc的服务，此篇我们就分析rtmp服务，所以进入SrsServerAdapter后，就会进行各种服务器的监听，调用到，后调用
SrsServer::listen() -> SrsBufferListener::listen -> new SrsTcpListener(this, ip, port)
rtmp使用的是tcp，所以就开始监听tcp了
srs_tcp_listen创建socket并监听
之后new SrsSTCoroutine("tcp", this)创建协程，调用start会调用SrsTcpListener::cycle()；
具体流程是
协程里面处理accept等待客户端的连接，客户端连接请求后，开始回调on_tcp_client，即调用 SrsBufferListener::on_tcp_client()
调用 SrsServer::accept_client
调用fd_to_resource，根据type创建不同的ISrsStartableConneciton，这里rtmp是SrsListenerRtmpStream，所以返回new SrsRtmpConn 而后调用 SrsRtmpConn::start
class SrsRtmpConn : virtual public ISrsCoroutineHandler
所以调用到SrsRtmpConn::cycle(),里面调用SrsRtmpConn::do_cycle()
开始握手，建立rtmp连接，进入SrsRtmpConn::service_cycle()
建立连接后，设置rtmp
set_window_ack_size
set_peer_bandwidth
set_chunk_size
调用 SrsRtmpConn::stream_service_cycle()
首先进行rtmp->identify_client 客户端的身份识别
然后再根据不同的客户端类型type进入不同的分支
SrsRtmpConnPlay 客户端播流。
SrsRtmpConnFMLEPublish Rtmp推流到服务器。
SrsRtmpConnHaivisionPublish 应该是海康威视推流到服务器
SrsRtmpConnFlashPublish Flash推流到服务器。
我们先看推流 SrsRtmpConnFMLEPublish
首先 start_fmle_publish 创建流
然后进入 publishing
SrsPublishRecvThread rtrd(rtmp, req, srs_netfd_fileno(stfd), 0, this, source, _srs_context->get_id());
err = do_publishing(source, &rtrd);
SrsPublishRecvThread 有
SrsRecvThread trd;
SrsRtmpServer* rtmp;
class SrsRecvThread : public ISrsCoroutineHandler
所以rtrd->start后，会调用SrsRecvThread::cycle()再调用do_cycle()
rtmp->recv_message读取数据->SrsProtocol::recv_message ->
pumper->consume 调回 SrsRtmpConn::handle_publish_message(SrsSource* source, SrsCommonMessage* msg)
然后调用 process_publish_message
如果是edge边缘服务器，直接推流回源到源服务器
处理audio数据
处理video数据
我们先看处理video数据
SrsCommonMessage* shared_video 转换为 SrsSharedPtrMessage msg;
mix_correct是混合单增算法，解决音频和视频混合单增的问题
这里没有设置，就直接走on_video_imp
首先判断是不是sequence header, 如果是，判断跟之前的有没有一样，一样，那就只缓存一次，根据源码可知，音视频的metadata只发一次，如果有新的拉流端需求，怎样更新呢？
缓存h264 sequence header, hls分发，dvs分发，forwarders推流等，之后就客户端消费者分发，如果有客户端请求播放，那就会有consumer了，就可以进入consumer->enqueue
每个SrsConsumer消费者拥有独立的SrsMessageQueue* queue队列。内部队列实现实际上是SrsFastVector msgs
SrsMessageQueue有数量大小限制，当队列满的时候删除丢弃旧的messages：
队列大小限制queue_size设置为配置文件中的"queue_length"。如果没设置则默认#define SRS_PERF_PLAY_QUEUE 30。
max_queue_size = (int)(queue_size * 1000);
推流到此就结束了，而后播放端请求拉流，前面的基本一致，从
srs_error_t SrsRtmpConn::stream_service_cycle()
{
srs_error_t err = srs_success;
}
会走 SrsRtmpConnPlay分支
SrsRtmpConn::do_playing
SrsConsumer::mp_packets
SrsMessageQueue::mp_packets
即前面的SrsMessageQueue* queue里面取数据了
SrsRtmpServer::send_and_free_messages
⑵ Android：深入剖析图片加载库Glide缓存功能(源码分析）
Glide 需要缓存的 图片资源 分为两类：
Glide 的缓存机制使得 Glide 具备非常好的图片缓存效果，从而使得具备较高的图片加载效率。
下面，我将根据 Glide 缓存流程中的每个步骤 进行源码分析。
至此， Glide 的图片缓存 Key 生成完毕。
至此，创建好了缓存对象 LruResourceCache
即：
源码分析如下：
若上述两个方法都没获取到缓存图片时（即内存缓存里没有该图片的缓存），就开启新线程加载图片。
若无法从 内存缓存 里 获得缓存的图片， Glide 就会采用第2级缓存：磁盘缓存 去获取缓存图片
写入 内存缓存分为：写入 弱引用缓存 & LruCache 算法的缓存
写入 LruCache 算法 内存缓存的原理：包含图片资源 resource 的 EngineResource 对象的一个引用机制：
所以：
至此，实现了：
至此， Glide 的图片缓存流程解析完毕。
Android图片加载的那些事：为什么你的Glide 缓存没有起作用？
不定期分享关于 安卓开发 的干货，追求 短、平、快 ，但 却不缺深度 。
⑶ 直播系统源码开发，究竟是怎样的一个过程
首先一个基本的直播间源码一般包含三个大模块：主播端、播放端以及直播间服务端。
一、首先是主播端，它是组成视频流的根源，由一系列步骤构成：
1、根据移动端的设备来采集数据。
2、将收集的这种视频开展一系列的前期处理，例如图片水印、美肤和动画特效ps滤镜等处理。
3、将处理后的视频数据转化成可收看可传送的视频流；
4、传输拉流，将要压缩后的视频流根据网络通道传送出来解压后播放。
二、其次是播放端，播放端的作用有两个层面
1、饥族掘第一个层面是至关重要的要求，它牵涉到一些十分重要的指标，例如秒开，在许多直播间源码开发的情景之中都要保留好的体验烂核度，随后是针对一些关键内容的版权法。为了更好地做到更强的实际效果，大家还必须相互配合服务器端做智能解析，这在一些情景下也是至关重要的要求。
2、另一层面是业务流程层面。也即业务流程层面的作用，针对一个社交媒体直播间商品而言，在播放端，观众们期待可以即时地见到主播端推过来的视频流，而且和穗银主播及其别的观众们产生一定的互动交流，包括一些像关注、闲聊和视频弹幕那样的功能，还有礼物打赏的变现。
三、最后是直播间服务端，展示的最关键功能是搜集主播端视频拉流，并将其推送给用户端。
1、除开这一关键作用，直播间源码的开发也有许多运营的要求，例如身份验证，视频连线和即时转换格式，全自动鉴黄，多屏显示合一，及其云空间视频录制储存等作用。
2、此外，针对一个主播端发布的视频，中间必须历经一些阶段才可以传送到播放端，因而对中间商的品质开展监管，及其依据这种监管来开展智能化生产调度，也是十分关键的诉求。
3、事实上不论是主播端还是播放端，她们的要求都不只是视频拍摄和播放视频那么简易。在这个关键要求被解决以后，也有许多重要要求必须被考虑。直播间源码的开发中除开这三大控制模块以外，还必须完成一个业务流程服务器端来开展拉流和播放操纵，这就是直播间搭建的几大模块。
⑷ Gson源码解析
Gson 是一个 Java 库，可用于将 Java 对象转换为其 JSON 表示形式。它还可用于将 JSON 字符串转换为等效的 Java 对象。
地址 https://github.com/google/gson
TypeAdapter是Gson的核心，它的设计是一个 适配器模式
因为 Json 数据接口和 Type 的接口两者是无法兼容，因此 TypeAdapter 就是来实现兼容，把 json 数据读到 Type 中，把 Type 中的数据写入到 Json 里。
Gson会为每一种类型创建一个TypeAdapter，同样的，每一个Type都对应唯一一个TypeAdapter
而所有Type(类型)，在Gson中又可以分为基本类型和复合类型（非基本类型）
在 Gson 中封装了不同类型的读写的业务组装类是各个 TypeAdapter(适配器)
从缓棚姿喊存获取 TypeAdapter 对象，存在者直接返回
通过ThreadLocal缓存TypeAdapter对象，不同的线程使用缓存来解析的时候互不影响。
如果不存在缓存，那么从factories列表链野里查找，factories是在创建Gson对象时初始化，添加了很多用于创建TypeAdapter对象的TypeAdapterFactory。
在Gson中，Java对象与JSON字符串之间的转换是通过字符流来进行操作的。JsonReader继承于Reader用来读取字符，JsonWriter继承于Writer用来写入字符。
进行数据的写入 用于反序列化操作
该类是一个抽象册厅类，代表着json串的某一个元素。这个元素可以是一个Json(JsonObject)、可以是一个数组(JsonArray)、可以是一个Java的基本类(JsonPrimitive)、当然也可以为null(JsonNull);JsonObject,JsonArray,JsonPrimitive，JsonNull都是JsonElement这个抽象类的子类。JsonElement提供了一系列的方法来判断当前的JsonElement。
各个JsonElement的关系可以用如下图表示：
JsonObject对象可以看成 name/values的集合，而这写values就是一个个JsonElement,他们的结构可以
用如下图表示：
Expected BEGIN_ARRAY but was STRING at line 1 column 27
这种错误一般都是原来是一个字段需要是数组类型，但是事实上给的是””,导致的
解决办法
⑸ 直播源码，直播系统如何开发搭建与运营
直播的火爆让各行各业对直播这块新市场垂涎不已，而进军直播市场的第一步——直播系统源码却让企业头疼不已，那么直播系统源码如何进行开发呢？一、媒体模块：1、采集：通过SDK接口，直接从用户设备采集视频、音频等数据，视频采样数据一般采用RGB或YUV格式、音频采样数据一般采用PCM格式。2、预处理：对采集到的数据通过SDK层面接口进行润化处理，主要是图像方面的处理，如美颜、水印、滤镜等，GPU优化提速，平衡手机功耗及效果。3、编码：对采集到的数据进行压缩编码，比较常用的视频编码为H.264，音频为AAC，在分辨率、帧数、码率等参数设计上找到最佳平衡点，使之匹配推流所需协议，提高上传效率。4、推拉流：推流就是将压缩后的音视频变为流数据，上传至服务器。拉流即通过播放端获取码流，从服务端拉取支持以RTMP、HTTP-FLV及HLS等协议的音视频流。5、解码：对拉流获取封装的视频数据进行高性能解码，让直播更流畅。6、播放：解码后的音频数据即可在播放端进行播放，支持包括MP4、FLV、M3U8等多样视频播放格式。
二、服务模块
1、聊天系统：包括聊天室功能、弹幕、私聊
2、礼物系统：礼物的收发，礼物的图形
3、支付系统：充值、提现、收益兑换
4、运行系统：提供直播方案
5、安全系统：实名认证、截图、自动鉴黄、录制、回播、禁播6、统计系统：点击量、收益、流量统计
三、管理模块
1、前端：移动端、PC端页面效果展示设计，维护
2、后台：管理运营，数据库管理
我们都知道，搭建一个完整的直播平台过程包括：采集、处理、编码、推流、分发、解码和播放，搭建直播平台是需要借助三方账号的支持的，比如服务器、推拉流、短信服务等，搭建直播平台都也是如此，除了本身的系统功能外，想用直播系统源码搭建平台，还需要一些三方的协助：
1、 CDN，提供视频加速和视频分发服务，一般视频cdn可以使用腾讯的直播cdn加速服务，也可以使用ucloud的视频cnd加速服务，具体费用咨询对应厂商客服。只要是支持rtmp直播协议的就可以。
2、 美颜SDK，实现美颜功能
3、 支付账号，支付宝支付和微信支付的支付账号
4、 云存储，大量的录播视频、短视频、直播间实时互动消息，需要动态存储和静态存储的支持。
5、登录和分享的账号，微信和qq的登录和分享
6、 苹果公司开发者账号，分发和苹果上架使用。
众多的三方接口接入也是直播系统源码平台后期能够正常运营的先决条件，好在大部分直播系统源码服务商都可以提供协助接入服务免去了很多后顾之忧，因此搭建运营直播系统源码平台不仅仅要选对直播系统源码，还要选择正确的服务商。
⑹ 直播源代理源码如何使用
直播源代理源码使用方法如下：
一、首先是主播端，即推流端。
主要涉及到音视频的采集技术，这方面建议采用大厂商的直播SDK，比如腾讯直播SDK，阿里云直播SDK，七牛SDK等效果都非常不错。
二、中间环节是服务端，也即后台。
主要作用就是对直播间、主播、礼物、充值等进行管理。
三、最后就是推流端，即拉流端，用户观看端。
这个也可以采用现成的SDK来完成（如第一条的）。
技术难点主要集中于美颜技术，音视频混流技术，其他都比较简单，按照步骤文档一步一步来就行
⑺ 视频直播类app源码
一、手机直播系统源码开发实现视频直播主要有以下四步：
1）前端采集编码设备：提供直播信号源的采集和编码压缩功能，并将信号推送到直播流媒体服务器上。
2）直播流媒体服务器：负责直播流的发布和转播分发功能。
3）WEB服务器：实现直播节目在终端上的展现。
4）终端设备：包括PC和移动终端。编码和协议是实现直播的重要环节：1）网络协议：主要有3种a.RTSP（RealTimeStreamingProtocol）是用来控制声音或影像的多媒体串流协议,由RealNetworks和Netscape共同提出的；b.RTMP(RealTimeMessagingProtocol):实时消息传送协议是Adobe公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议；c.HLS(HTTPLiveStreaming):是苹果公司(AppleInc.)实现的基于HTTP的流媒体传输协议；2）视频编码:Mpeg4,H264等3）音频编码:Mp3,AAC等4）视频分辨率:标清通常指的是640×480（或768×480）；高清指的是1280×720；全高清指的是1920×1080；超高清3840×2160。
二、直播系统源码搭建服务器部署重点
直播系统源码有哪几块组成，视频直播的过程一般可以分为采集、前处理、编码、传输、解码、渲染这几个环节，经过这几个环节之后，我们就可以通过PC端或者移闭橘动端进行视频直播的观看。直播系统在搭建时会用到多个业务服务器，共同完成直播系统的业务逻辑流程。通常在服务器部署时会采用动静分离分布式部署方式，保障了直播平台的稳定运行。主要用到以下的业务服务器。
1）消息服务器：主要用于消息推送，给用户推送房间聊天消息、私信消息。
2）业务服务器：手机直播的业务部分、好友关系、直播管理、货币系统、礼物系统等。
3）视频服务器：视频直播、点播、转码、存储和点播等。
4）IM即时聊天：使用Node.js服务自主搭建部署聊天服务器。
5）视频流（流媒体服务器）：建议采用第三方CDN，开通账号即可使用。关于CDN方面的内容，我们会在以后的内容中做重点介绍。
6）业务服务器：伍态颤网站逻辑基于php-tlinkphp、thinkcmf、mysql、redis。MYSQL服务提供静态数据的存储，REDIS服务提供数据的缓存、存储动态数据。
以上便是对直播系统源码如何实现视频直播以及搭建服务器的简单介绍。搭建直播开发平台之前就是找到一款优质的直播系统源码，直播系统源码开发原理比其他软件更加复杂，而且相对于技术以及其他方面都会有一定的要求。直播系统源码的稳定性和安全性决定了后期搭建出的直播平台的流畅度、高并发承载及用户的产品体验，所以选择直播源码的时候一定不要为了贪图价格便宜，而腔败选择安全性低，系统功能不会正常更新，bug一堆的源码。直播系统源码的开发需要经过推流端(采集、前处理)、服务端处理(编码、转码、录制、截图、鉴黄)、播放器(拉流、解码、渲染和互动系统)。望采纳，谢谢
⑻ 一文解密Kafka，Kafka源码设计与实现原理剖析，真正的通俗易懂
Apache Kafka （简称Kafka ）最早是由Linkedln开源出来的分布式消息系统，现在是Apache旗下的一个子项目，并且已经成为开册、领域应用最广泛的消息系统之 Kafka社区也非常活跃，从 版本开始， Kafka 的标语已经从“一个高吞吐量、分布式的消息系统”改为“一个分布式的流平台”
关于Kafka，我打算从入门开始讲起，一直到它的底层实现逻辑个原理以及源码，建议大家花点耐心，从头开始看，相信会对你有所收获。
作为 个流式数据平台，最重要的是要具备下面 个特点
消息系统：
消息系统 也叫作消息队列）主要有两种消息模型：队列和发布订Kafka使用消费组（ consumer group ）统 上面两种消息模型 Kafka使用队列模型时，它可以将处理 作为平均分配给消费组中的消费者成员
下面我们会从 个角度分析Kafka 的几个基本概念，并尝试解决下面 个问题
消息由生产者发布到 fk 集群后，会被消费者消费 消息的消费模型有两种：推送模型（ pu和拉取模型（ pull 基于推送模型的消息系统，由消息代理记录消费者的消费状态 消息代理在将消息推送到消费者后 标记这条消息为已消费
但这种方式无法很好地保证消息的处理语义 比如，消息代理把消息发送出去后，当消费进程挂掉或者由于网络原因没有收到这条消息时，就有可能造成消息丢失（因为消息代理已经 这条消息标记为自己消费了，但实际上这条消息并没有被实际处理） 如果要保证消息的处理语义，消息代理发送完消息后，要设置状态为“已发送”，只有收到消费者的确认请求后才更新为“已消费”，这就需要在消息代理中记录所有消息的消费状态，这种做法也是不可取的
Kafka每个主题的多个分区日志分布式地存储在Kafka集群上，同时为了故障容错，每个分区都会以副本的方式复制到多个消息代理节点上 其中一个节点会作为主副本（ Leader ），其 节点作为备份副本（ Follower ，也叫作从副本）
主副本会负责所有的客户端读写操作，备份副本仅仅从主副本同步数据 当主副本 IH 现在故障时，备份副本中的 副本会被选择为新的主副本 因为每个分区的副本中只有主副本接受读写，所以每个服务端都会作为某些分区的主副本，以及另外一些分区的备份副本这样Kafka集群的所有服务端整体上对客户端是负载均衡的
消息系统通常由生产者“pro ucer 消费者（ co sumer ）和消息代理（ broke 大部分组成，生产者会将消息写入消息代理，消费者会从消息代理中读取消息 对于消息代理而言，生产者和消费者都属于客户端：生产者和消费者会发送客户端请求给服务端，服务端的处理分别是存储消息和获取消息，最后服务端返回响应结果给客户端
新的生产者应用程序使用 af aP oce 对象代表 个生产者客户端进程 生产者要发送消息，并不是直接发送给 务端 ，而是先在客户端 消息放入队列 然后 一个 息发送线程从队列中消息，以 盐的方式发送消息给服务端 Kafka的记 集器（ Reco dACCUl'lUlato ）负责缓存生产者客户端产生的消息，发送线程（ Sende ）负责读取 集器的批 过网络发送给服务端为了保证客户端 络请求 快速 应， Kafka 用选择器（ Selecto 络连接 读写 理，使网络连接（ Netwo kCl i.ent ）处理客户端 络请求
追加消息到记录收集器时按照分区进行分组，并放到batches集合中，每个分区的队列都保存了将发送到这个分区对应节点上的 记录，客户端的发送线程可 只使用 Sende 线程迭 batches的每个分区，获取分区对应的主剧本节点，取出分区对应的 列中的批记录就可以发送消息了
消息发送线程有两种消息发送方式 按照分区直接发送 按照分区的目标节点发迭 假设有两台服务器， 题有 个分区，那么每台服务器就有 个分区 ，消息发送线程迭代batches的每个分 接往分区的主副本节点发送消息，总共会有 个请求 所示，我 先按照分区的主副本节点进行分组， 属于同 个节点的所有分区放在一起，总共只有两个请求做法可以大大减少网络的开销
消息系统由生产者 存储系统和消费者组成 章分析了生产者发送消息给服务端的过程，本章分析消费者从服务端存储系统读取生产者写入消息的过程 首先我 来了解消费者的 些基础知识
作为分布式的消息系统， Kafka支持多个生产者和多个消费者，生产者可以将消息发布到集群中不同节点的不同分区上；“肖费者也可以消费集群中多个节点的多个分区上的消息 写消息时，多个生产者可以 到同 个分区 读消息时，如果多个消费者同时读取 个分区，为了保证将日志文件的不同数据分配给不同的消费者，需要采用加锁 同步等方式，在分区级别的日志文件上做些控制
相反，如果约定“同 个分区只可被 个消费者处理”，就不需要加锁同步了，从而可提升消费者的处理能力 而且这也并不违反消息的处理语义：原先需要多个消费者处理，现在交给一个消费者处理也是可以的 3- 给出了 种最简单的消息系统部署模式，生产者的数据源多种多样，它们都统写人Kafka集群 处理消息时有多个消费者分担任务 ，这些消费者的处理逻辑都相同， 每个消费者处理的分区都不会重复
因为分区要被重新分配，分区的所有者都会发生变 ，所以在还没有重新分配分区之前 所有消费者都要停止已有的拉取钱程 同时，分区分配给消费者都会在ZK中记录所有者信息，所以也要先删ZK上的节点数据 只有和分区相关的 所有者 拉取线程都释放了，才可以开始分配分区
如果说在重新分配分区前没有释放这些信息，再平衡后就可能造成同 个分区被多个消费者所有的情况 比如分区Pl 原先归消费者 所有，如果没有释放拉取钱程和ZK节点，再平衡后分区Pl 被分配给消费者 了，这样消费者 和消费者 就共享了分区Pl ，而这显然不符合 fka 中关于“一个分区只能被分配给 个消费者”的限制条件 执行再平衡操作的步骤如下
如果是协调者节点发生故障，服务端会有自己的故障容错机制，选出管理消费组所有消费者的新协调者节，点消费者客户端没有权利做这个工作，它能做的只是等待一段时间，查询服务端是否已经选出了新的协调节点如果消费者查到现在已经有管理协调者的协调节点，就会连接这个新协调节，哉由于这个协调节点是服务端新选出来的，所以每个消费者都应该重新连接协调节点
消费者重新加入消费组，在分配到分区的前后，都会对消费者的拉取工作产生影响 消费者发送“加入组请求”之前要停止拉取消息，在收到“加入组响应”中的分区之后要重新开始拉取消息时，为了能够让客户端应用程序感知消费者管理的分区发生变化，在加入组前后，客户端还可以设置自定义的“消费者再平衡监听器”，以便对分区的变化做出合适的处理