主頁 > 軟體設計 > 音視頻同步！RTCP 協議決議及代碼實作

音視頻同步！RTCP 協議決議及代碼實作

2021-09-29 07:42:37 軟體設計

音視頻同步！RTCP協議決議及代碼實作

RTCP 是實時控制協議（Real-Time Control Protocol）的縮寫，RTCP 由 RFC 3550 定義（取代作廢的 RFC 1889），

實時傳輸協議（RTP）和實時控制協議（RTCP）結合使用，可以監視大型多播網路的資料傳遞，RTP 承載媒體流，而 RTCP 用于監視傳輸統計資訊和服務質量，監視使接收器能夠檢測是否有任何丟包并補償任何延遲抖動，

兩種協議都獨立于基礎傳輸層協議和網路層協議作業，RTP 標頭中的資訊告訴接收器如何重建資料，并描述編解碼器位元流的打包方式，

下面我們重點講解 RTCP 功能、RTCP 資訊包等，最后 RTCP 協議決議實作，

RTCP 有哪些功能

1、RTCP 主要功能是提供有關質量的反饋資料分發，這是 RTP 角色不可或缺的一部分，傳輸協議，與流量和擁塞有關其他傳輸協議的控制功能，

2、RTCP 帶有 RTP 的持久性傳輸級別識別符號源稱為規范名稱或 CNAME，自從如果發現沖突或程式重新啟動，接收方要求 CNAME 跟蹤每個參與者，

接收者也可能要求 CNAME 將來自給定參與者的多個資料流關聯到集合中相關 RTP 會話的數量，例如同步音頻和視頻，媒體間同步還需要 NTP 和 RTP 資料發送方在 RTCP 資料包中包含的時間戳，

3、前兩個功能要求所有參與者發送 RTCP 資料包，因此必須控制速率以使 RTP 能夠擴大到大量參與者，通過讓每個參與者將其控制包發送給所有其他人，每個人都可以獨立觀察參與者的數量，

4、這項功能對于參加者可以任意進入和離開的松散會話行程十分有用，參加者可以自由進入或離開，沒有成員控制或引數協調，

功能 1-3 應該在所有環境中使用，尤其是在 IP 多播環境，RTP 應用程式設計師應避免只能在單播模式下作業且無法擴展到的機制更大的數字，RTCP 的傳輸可以單獨控制對于發送者和接收者，適用于例如單向鏈接，而接收者沒有反饋可能的，

RTCP 協議的埠

RTSP 通常使用 RTP 協議來傳送實時流，RTP 一般使用偶數埠，而 RTCP 使用相鄰的奇數埠，即 RTP 埠號+1，

RTP 埠

img

RTCP 埠

img

RTCP 資訊包有哪些

在 RTCP 通信控制中，RTCP 協議的功能是通過不同型別的 RTCP 包來實作的，RTCP 也是基于 UDP 包來傳送的，主要有五種型別的封包：

  1. SR：發送端報告，由發送 RTP 資料報的應用程式或中端發出的，
  2. RR：接收端報告，由接受但不發送 RTP 資料報的應用程式或中端發出，
  3. SDES：源描述，傳遞與會話成員有關的標識資訊的載體，如用戶名、郵件、電話等，
  4. BYE：通知離開，通知回話中的其他成員將退出會話，
  5. APP：由應用程式自己定義，作為 RTCP 協議的擴展，
#define RTCP_SR      200
#define RTCP_RR      201
#define RTCP_SDES    202
#define RTCP_BYE     203
#define RTCP_APP     204

我們可以根據這五種型別包判斷 RTCP 頭部

static bool dissect_rtcp_heur(u_char *rtcp_info,int PayloadLen)
{
    unsigned int offset = 0;
    unsigned int first_byte = 0;
    unsigned int packet_type = 0;


    /* 查看第一個位元組 */
    first_byte = rtcp_info[offset];

    /* 版本位是否設定為2*/
	//printf("version: %d\n",((first_byte & 0xC0) >> 6));
    if (((first_byte & 0xC0) >> 6) != 2)
    {
        return false;
    }

    /* 看包型別 */
	offset += 1;
    packet_type = rtcp_info[offset];
	//printf("packet_type: %d\n",packet_type);
    /* 復合資料包中的第一個資料包應該是發送方或接收者報告 */
    if (!((packet_type == RTCP_SR)  || (packet_type == RTCP_RR) ||
          (packet_type == RTCP_BYE) || (packet_type == RTCP_APP) ||
          (packet_type == RTCP_PSFB)))
    {
        return false;
    }

    /*總長度必須是4個位元組的倍數*/
	//printf("PayloadLen: %d\n",PayloadLen);
    if (PayloadLen % 4)
    {
        return false;
    }

    /* OK, dissect as RTCP */
    dissect_rtcp(rtcp_info,packet_type,offset,PayloadLen);
    return true;
}

RTCP 協議報文格式

SR：發送端報告

img

版本（V）：同 RTP 包頭部

填充 ( P ) ：同 RTP 包頭部，

接收報告計數器（RC）:5b 該 SR 包中接收的報告塊的數目，

包型別（PT）： 8bit SR 包型別為 200

長度（length）：SR 包以 32bit 為 1 單位的長度減 1

同步源（SSRC）：SR 包發送的同步源識別符號，與對應 RTP 包中的 SSRC 一樣，

NTP 時間戳（Network Time Protocol）：SR 包發送時的絕對時間，用于同步不同的流，

RTP 時間戳：與 NTP 時間戳對應，與 RTP 包中的時間戳具有相同的初始值，

Send’s Packet count：從開始發包到產生這個 SR 包的這段時間內發送者發送的有效資料的總位元組數，不包括頭部和填充，發送者改變 SSRC 時，該域要清零，

同步源 n 的 SSRC 識別符號：該報告中包含的是從該源接收到的包的統計資訊，

丟失率：表明從上一個 SR 或 RR 包發出依來從同步源 n 發送的 RTP 包的丟失率，

累計丟失資料：從開始接受 SSRC_n 的包到發送 SR 這個時間段內 SSRC_n 發送的 RTP 丟失的總數目，

收到的擴展最大序列號：從 SSRC_n 收到的從 RTP 資料包中的最大序列號，

接收抖動（Interarrival jitter）：RTP 資料包接收時間的統計方差估計，

上次 SR 時間戳（Last SR）：取最近從 SSRC_n 收到的 SR 包中的 NTP 時間戳中的中間 32bit，如果還未收到 SR 包，則為 0，

上次依賴 SR 延遲（Delay since Last SR）：從上次 SSRC_n 收到 SR 包到發送本包的延遲

Wireshark 抓包：

img

活動會話的參與者在發送和接收 RTP 分組時使用 SR，SR 有三個不同的部分：報頭資訊、發送方資訊和許多接收方報告塊，SR 也可以有一個與大綱相關的擴展域，

img

Wireshark 抓包：

img

SDES：源描述

SDES 提供了傳遞與會話成員有關的標識資訊的載體，如用戶名、郵件、電話等，每個 RTCP 混合分組中必須有 SDES 分組，

img

報頭包含一個長度域、一個凈荷型別域（PT=202）和一個源計數（RC）域，RC 域 5 個 bit，表示分組中資訊塊的數量，

每個資訊塊包含一個 SSRC 或 CSRC 值，其后跟著一個或多個的識別符號和一些可用于 SSRC 或 CSRC 的資訊，

CNAME 項的 SDES 包必須包含在每個組合 RTCP 包中，SDES 包可能包括其他源描述項，這要根據特別的應用需要，并同時考慮帶寬限制，

Wireshark 抓包：

img

SDES 源描述包提供了直觀的文本資訊來描述會話的參加者，包括 CNAME、NAME、EMAIL、PHONE、LOC 等源描述項，

這些為接收方獲取發送方的有關資訊提供了方便，SDES 包由包頭與資料塊組成，資料塊可以沒有，也可有多個，包頭由版本（V）、填充（P）、長度指示、包型別（PT）和源計數（SC）組成，

PT 占 8 位，用于識別 RTCP 的 SDES 包，SC 占 5 位，指示包含在 SDES 包中的 SSRC/CSRC 塊數量，零值有效，但沒有意義，

BYE: 通知離開

BYE 分組用于表示一個或多個媒體源不再是處于激活狀態，

img

Wireshark 抓包：

img

作為可選項，BYE 包可包括一個 8 位八進制計數，后跟文本資訊，表示離開原因，

最后，組合包中每個 RTCP 包可獨立處理，而不需要按照包組合的先后順序處理，

在組合包中有以下幾條強制約束，

  1. 只要帶寬允許，在 SR 包或 RR 包中的接收統計應該經常發送，因此每個周期發送的組合 RTCP 包中應包含報告包，
  2. 每個組合包中都應該包含 SDES CNAME，因為新接收者需要通過接收 CNAME 來識別源，并與媒體聯系進行同步，
  3. 組合包前面是包型別數量，其增長應該受到限制，

RTCP 協議如何實作媒體流的同步

通過抓包分析 RTCP 發送端報告，RTP 的同步其實就靠這三個域：

  1. sender SSRC ：SR 包發送的同步源識別符號，與對應 RTP 包中的 SSRC 一樣，
  2. NTP timestamp：SR 包發送時的絕對時間，用于同步不同的流，
  3. RTP timestamp：與 NTP 時間戳對應，與 RTP 包中的時間戳具有相同的初始值，

img

那怎么計算 NTP 時間呢？在 RTCP 中 NTP 時間存放在 8 個位元組中，分為：MSW 和 LSW，分別占用 4 個位元組，

const char *tvb_ntp_fmt_ts_sec(u_char *rtcp_info, int offset)
{
	uint32_t tempstmp = 0;
	time_t temptime = 0;
	struct tm *bd;
	char *buff = NULL;
	
	tempstmp = ntohl(*(uint32_t*)(rtcp_info + offset));
	if (tempstmp == 0){
		return "NULL";
	}

	/* We need a temporary variable here so the unsigned math
	* works correctly (for years > 2036 according to RFC 2030
	* chapter 3).
	*/
	temptime = (time_t)(tempstmp - NTP_BASETIME);
	bd = gmtime(&temptime);
	if (!bd){
		return "Not representable";
	}

	buff = (char *)malloc(NTP_TS_SIZE);
	snprintf(buff, NTP_TS_SIZE,
		"%s %2d, %d %02d:%02d:%02d UTC",
		mon_names[bd->tm_mon],
		bd->tm_mday,
		bd->tm_year + 1900,
		bd->tm_hour,
		bd->tm_min,
		bd->tm_sec);
	return buff;
}

NTP timestamp

  
    /* NTP timestamp */
    ts_msw = ntohl(*(uint32_t*)(rtcp_info + offset));
	printf("ts_msw: 0x%x\n",ts_msw);
    ts_lsw = ntohl(*(uint32_t*)(rtcp_info + offset + 4));
	printf("ts_lsw: 0x%x\n",ts_lsw);
	printf("MSW: %s\n",tvb_ntp_fmt_ts_sec(rtcp_info,offset));
    offset += 8;

RTCP 協議實作

下面我給出對 RTCP 協議決議實作的代碼，根據回放報文，決議欄位資訊，

/* 接收者/發送者計數是最后5位   */
#define RTCP_COUNT(octet)   ((octet) & 0x1F)


#define RTCP_PT_MIN  192
/* Supplemental H.261 specific RTCP packet types according to Section C.3.5 */
#define RTCP_FIR     192
#define RTCP_NACK    193
#define RTCP_SMPTETC 194
#define RTCP_IJ      195
/* RTCP packet types according to Section A.11.1 */
/* And https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml */
#define RTCP_SR      200
#define RTCP_RR      201
#define RTCP_SDES    202
#define RTCP_BYE     203
#define RTCP_APP     204
#define RTCP_RTPFB   205
#define RTCP_PSFB    206
#define RTCP_XR      207
#define RTCP_AVB     208
#define RTCP_RSI     209
#define RTCP_TOKEN   210

#define RTCP_PT_MAX  210


static const char mon_names[12][4] = {
	"Jan",
	"Feb",
	"Mar",
	"Apr",
	"May",
	"Jun",
	"Jul",
	"Aug",
	"Sep",
	"Oct",
	"Nov",
	"Dec"
};

/** data structure to hold time values with nanosecond resolution*/
typedef struct {
	time_t	secs;
	int	nsecs;
} nstime_t;


/*
 * 1900-01-01 00:00:00 (proleptic?) UTC.
 * Used by a number of time formats.
 */
#define EPOCH_DELTA_1900_01_01_00_00_00_UTC 2208988800U

/*
 * NTP_BASETIME is in fact epoch - ntp_start_time; ntp_start_time
 * is January 1, 2036, 00:00:00 UTC.
 */
#define NTP_BASETIME EPOCH_DELTA_1900_01_01_00_00_00_UTC
#define NTP_FLOAT_DENOM 4294967296.0
#define NTP_TS_SIZE 100


/* 解剖長度欄位，附加到此欄位的文字表示轉換為的實際位元組數 (即 (原始值 + 1) * 4) */
static int dissect_rtcp_length_field(u_char *rtcp_info, int offset)
{

    uint16_t  raw_length = ntohs(*(uint16_t*)(rtcp_info + offset));
    printf("(%u bytes)\n", (raw_length+1)*4);
    offset += 2;
    return offset;
}
static int dissect_rtcp_rr(u_char *rtcp_info, int offset,int count, int packet_length )
{
    int counter = 0;
    uint8_t  rr_flt = 0;
    int    rr_offset = offset;
	
    counter = 1;
    while ( counter <= count ) {
        uint32_t lsr = 0, dlsr = 0;

        /* Create a new subtree for a length of 24 bytes */

        /* SSRC_n source identifier, 32 bits */

        offset += 4;

        /* Fraction lost, 8bits */
        rr_flt = rtcp_info[offset];

        offset++;

        /* Cumulative number of packets lost, 24 bits */
        offset += 3;


        /* Sequence number cycles */

        offset += 2;
        /* highest sequence number received */

        offset += 2;

        /* Interarrival jitter */

        offset += 4;

        /* Last SR timestamp */
        lsr = ntohl(*(uint32_t*)(rtcp_info + offset));
		printf("Last SR timestamp: 0x%x\n",lsr);
        offset += 4;

        /* Delay since last SR timestamp */
        dlsr = ntohl(*(uint32_t*)(rtcp_info + offset));

        printf("(%d milliseconds)\n",(int)(((double)dlsr/(double)65536) * 1000.0));
        offset += 4;

        counter++;
    }

    return offset;
}

const char *tvb_ntp_fmt_ts_sec(u_char *rtcp_info, int offset)
{
	uint32_t tempstmp = 0;
	time_t temptime = 0;
	struct tm *bd;
	char *buff = NULL;
	
	tempstmp = ntohl(*(uint32_t*)(rtcp_info + offset));
	if (tempstmp == 0){
		return "NULL";
	}

	/* We need a temporary variable here so the unsigned math
	* works correctly (for years > 2036 according to RFC 2030
	* chapter 3).
	*/
	temptime = (time_t)(tempstmp - NTP_BASETIME);
	bd = gmtime(&temptime);
	if (!bd){
		return "Not representable";
	}

	buff = (char *)malloc(NTP_TS_SIZE);
	snprintf(buff, NTP_TS_SIZE,
		"%s %2d, %d %02d:%02d:%02d UTC",
		mon_names[bd->tm_mon],
		bd->tm_mday,
		bd->tm_year + 1900,
		bd->tm_hour,
		bd->tm_min,
		bd->tm_sec);
	return buff;
}

static int dissect_rtcp_sr(u_char *rtcp_info, int offset,int count, int packet_length)
{

    uint32_t     ts_msw = 0, ts_lsw = 0;
    int         sr_offset = offset;

    /* NTP timestamp */
    ts_msw = ntohl(*(uint32_t*)(rtcp_info + offset));
	printf("ts_msw: 0x%x\n",ts_msw);
    ts_lsw = ntohl(*(uint32_t*)(rtcp_info + offset + 4));
	printf("ts_lsw: 0x%x\n",ts_lsw);

	//printf("offset: 0x%x 0x%x 0x%x 0x%x\n",rtcp_info[offset],rtcp_info[offset + 1],rtcp_info[offset + 2],rtcp_info[offset + 3]);
	printf("MSW: %s\n",tvb_ntp_fmt_ts_sec(rtcp_info,offset));
    offset += 8;

    /* RTP timestamp, 32 bits */
	
    offset += 4;
    /* Sender's packet count, 32 bits */

    offset += 4;
    /* Sender's octet count, 32 bits */

    offset += 4;


    /* The rest of the packet is equal to the RR packet */
    if ( count != 0 )
        offset = dissect_rtcp_rr(rtcp_info, offset, count, packet_length-(offset-sr_offset));
    else
    {
        /* If length remaining, assume profile-specific extension bytes */
        if ((offset-sr_offset) < packet_length)
        {

            offset = sr_offset + packet_length;
        }
    }

    return offset;
}

static int dissect_rtcp_sdes(u_char *rtcp_info, int offset, int count)
{
    int           chunk = 0;

    int           start_offset = 0;
    int           items_start_offset = 0;
    uint32_t       ssrc = 0;
    unsigned int  item_len = 0;
    unsigned int  sdes_type = 0;
    unsigned int  prefix_len = 0;

    chunk = 1;
    while ( chunk <= count ) 
	{
		/* Create a subtree for this chunk; we don't yet know
		   the length. */
		start_offset = offset;

		ssrc = ntohl(*(uint32_t*)(rtcp_info + offset));
		printf("Chunk %u, SSRC/CSRC 0x%X\n", chunk, ssrc);

		/* SSRC_n source identifier, 32 bits */
		offset += 4;

		/* Create a subtree for the SDES items; we don't yet know
		   the length */


		/*
		 * Not every message is ended with "null" bytes, so check for
		 * end of frame as well.
		 */
		 
		  /* ID, 8 bits */
		sdes_type = rtcp_info[offset];
		printf("Type: %d\n",sdes_type);
		if (sdes_type == 0)
			break;
		offset++;
		/* Item length, 8 bits */
		item_len = rtcp_info[offset];
		printf("Length: %d\n",item_len);
		offset++;
		
		char *pszText = (char*)malloc(item_len);
		if (pszText != 0)
		{
			memcpy(pszText, rtcp_info + offset,item_len);
			pszText[item_len] = '\0';
			printf("Text = %s\n",pszText);
		}	

		chunk++;
    }

    return offset;
}

static void dissect_rtcp(u_char *rtcp_info,int packet_type, int offset,int PayloadLen)
{
	unsigned int  temp_byte = 0;
	int  elem_count = 0;
	int  packet_length = 0;
	int  total_packet_length = 0;
	int loop = 2;
	bool flag_rtcp = false;

		/*檢查是否為有效型別*/
		if ( ( packet_type < RTCP_PT_MIN ) || ( packet_type >  RTCP_PT_MAX ) )
			exit(-1);

		/*
		 * 獲取完整的RTCP資料包的長度
		 */
		 
		packet_length = (ntohs(*(uint16_t*)(rtcp_info + offset + 1)) + 1) * 4 ;
		//printf("packet_length: %d\n",packet_length);

		
		temp_byte = rtcp_info[offset-1];
		elem_count = RTCP_COUNT( temp_byte );/* Source count, 5 bits */
		printf("Reception report count: %d\n",elem_count);  

		switch ( packet_type ) 
		{
			
			case RTCP_SR:
			case RTCP_RR:
				/*
					Real-time Transport Control Protocol (Receiver Report)
					10.. .... = Version: RFC 1889 Version (2)
					..0. .... = Padding: False
					...0 0001 = Reception report count: 1
					Packet type: Receiver Report (201)
					Length: 7 (32 bytes)
					Sender SSRC: 0xb584b03e (3045371966)
					Source 1
				*/

				/* Packet type, 8 bits */
				offset++;
				/* Packet length in 32 bit words MINUS one, 16 bits */
				offset = dissect_rtcp_length_field(rtcp_info, offset);
				/* Sender Synchronization source, 32 bits */
				offset += 4;

				if ( packet_type == RTCP_SR )
				{
					offset = dissect_rtcp_sr(rtcp_info, offset, elem_count, packet_length-8 );
					printf("dissect_rtcp_sr\n");
				}
				else
				{	
					offset = dissect_rtcp_rr(rtcp_info, offset, elem_count, packet_length-8 );							
				}
				
				//uint16_t second_packet_type = ntohs(*(uint16_t*)(rtcp_info + offset));

				//printf("111offset: 0x%x 0x%x 0x%x 0x%x\n",rtcp_info[offset],rtcp_info[offset + 1],rtcp_info[offset + 2],rtcp_info[offset + 3]);
				
				if (rtcp_info[offset + 1] == RTCP_SDES)
				{
					
					/* Source count, 5 bits */
					offset++;
					/* Packet type, 8 bits */
					offset++;
					/* Packet length in 32 bit words MINUS one, 16 bits */
					offset = dissect_rtcp_length_field(rtcp_info, offset);
					offset = dissect_rtcp_sdes(rtcp_info,offset,elem_count);

				}

			break;

			default:
				/*
				 * To prevent endless loops in case of an unknown message type
				 * increase offset. Some time the while will end :-)
				 */
				offset++;
				break;

		}
		
}


static bool dissect_rtcp_heur(u_char *rtcp_info,int PayloadLen)
{
    unsigned int offset = 0;
    unsigned int first_byte = 0;
    unsigned int packet_type = 0;


    /* 查看第一個位元組 */
    first_byte = rtcp_info[offset];

    /* 版本位是否設定為2*/
	//printf("version: %d\n",((first_byte & 0xC0) >> 6));
    if (((first_byte & 0xC0) >> 6) != 2)
    {
        return false;
    }

    /* 看包型別 */
	offset += 1;
    packet_type = rtcp_info[offset];
	//printf("packet_type: %d\n",packet_type);
    /* 復合資料包中的第一個資料包應該是發送方或接收者報告 */
    if (!((packet_type == RTCP_SR)  || (packet_type == RTCP_RR) ||
          (packet_type == RTCP_BYE) || (packet_type == RTCP_APP) ||
          (packet_type == RTCP_PSFB)))
    {
        return false;
    }

    /*總長度必須是4個位元組的倍數*/
	//printf("PayloadLen: %d\n",PayloadLen);
    if (PayloadLen % 4)
    {
        return false;
    }

    /* OK, dissect as RTCP */
    dissect_rtcp(rtcp_info,packet_type,offset,PayloadLen);
    return true;
}


static void confirm_rtcp_packet(struct ip *pIp)
{
	int iIpTotalLen = ntohs(pIp->ip_len);
	int offset = 0;
	int nFragSeq = 0;
	struct udphdr* pUdpHdr = (struct udphdr*)((char*)pIp + (pIp->ip_hl<<2));
	if (pIp->ip_p == IPPROTO_UDP) 
	{
		printf("\n");
		
		int iPayloadLen = iIpTotalLen - (pIp->ip_hl<<2) - 8;
		printf("UDP Payload Len %d\n", iPayloadLen);
		
		u_char *pDnsHdr = (u_char*)(pUdpHdr+1);
		dissect_rtcp_heur(pDnsHdr,iPayloadLen);
		
	}	
}

編譯運行：

img

總結

RTCP 協議是流媒體通信的基石，RTCP 協議則負責可靠傳輸、流量控制和擁塞控制等服務質量保證，上面講解了 RTCP 功能、RTCP 資料包格式及代碼實作，最后，學習一個新的協議，最好還是研究學習官方檔案，因為這是最權威的資料，

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/303843.html

標籤：其他

上一篇：代碼簽名證書，讓軟體真正擁有姓名！

下一篇：黑色HTML5網站整站原始碼

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C＃(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 面試突擊第一季，第二季，第三季

    第一季必考 https://www.bilibili.com/video/BV1FE411y79Y?from=search&seid=15921726601957489746 第二季分布式 https://www.bilibili.com/video/BV13f4y127ee/?spm_id_fro ......

    uj5u.com 2020-09-10 05:35:24 more
  • 第三單元作業總結

    1.前言 這應該是本學期最后一次寫作業總結了吧。總體來說，對作業的節奏也差不多掌握了，作業做起來的效率也更高了。雖然和之前的作業一樣，作業中都要用到新的知識，但是相比之前，更加懂得了如何利用工具以及資料。雖然之間卡過殼，但總體而言，這幾次作業還算完成的比較好。 2.作業程序總結 相比前兩個單元，此單 ......

    uj5u.com 2020-09-10 05:35:41 more
  • 北航OO（2020）第四單元博客作業暨課程總結博客

    北航OO（2020）第四單元博客作業暨課程總結博客 本單元作業的架構設計 在本單元中，由于UML圖具有比較清晰的樹形結構，因此我對其中需要進行查詢操作的元素進行了包裝，在樹的父節點中存盤所有孩子的參考。考慮到性能問題，我采用了快取機制，一次查詢后盡可能快取已經遍歷過的資訊，以減少遍歷次數。 本單元我 ......

    uj5u.com 2020-09-10 05:35:48 more
  • BUAA_OO_第四單元

    一、UML決議器設計 ? 先看下題目：第四單元實作一個基于JDK 8帶有效性檢查的UML(Unified Modeling Language)類圖，順序圖，狀態圖分析器 MyUmlInteraction，實際上我們要建立一個有向圖模型，UML中的物件（元素）可能與同級元素連接，也可與低級元素相連形成 ......

    uj5u.com 2020-09-10 05:35:54 more
  • 6.1邏輯運算子

    邏輯運算子 1. && 短路與 運算式1 && 運算式2 01.運算式1為true并且運算式2也為true 整體回傳為true 02.運算式1為false，將不會執行運算式2 整體回傳為false 03.只要有一個運算式為false 整體回傳為false 2. || 短路或 運算式1 || 運算式2 ......

    uj5u.com 2020-09-10 05:35:56 more
  • BUAAOO 第四單元 & 課程總結

    1. 第四單元：StarUml檔案決議 本單元采用了圖模型決議UML。 UML檔案可以抽象為圖、子圖、邊的邏輯結構。 在實作中，圖的節點包括類、介面、屬性，子圖包括狀態圖、順序圖等。 采用了三次遍歷UML元素的方法建圖，第一遍遍歷建點，第二、三次遍歷設定屬性、連邊，實作圖物件的初始化。這里借鑒了一些 ......

    uj5u.com 2020-09-10 05:36:06 more
  • 談談我對C# 多型的理解

    面向物件三要素：封裝、繼承、多型。 封裝和繼承，這兩個比較好理解，但要理解多型的話，可就稍微有點難度了。今天，我們就來講講多型的理解。 我們應該經常會看到面試題目：請談談對多型的理解。 其實呢，多型非常簡單，就一句話：呼叫同一種方法產生了不同的結果。 具體實作方式有三種。 一、多載 多載很簡單。 p ......

    uj5u.com 2020-09-10 05:36:09 more
  • Python 資料驅動工具：DDT

    背景 python 的unittest 沒有自帶資料驅動功能。 所以如果使用unittest，同時又想使用資料驅動，那么就可以使用DDT來完成。 DDT是 “Data-Driven Tests”的縮寫。 資料：http://ddt.readthedocs.io/en/latest/ 使用方法 dd. ......

    uj5u.com 2020-09-10 05:36:13 more
  • Python里面的xlrd模塊詳解

    那我就一下面積個問題對xlrd模塊進行學習一下： 1.什么是xlrd模塊？ 2.為什么使用xlrd模塊？ 3.怎樣使用xlrd模塊？ 1.什么是xlrd模塊？ ?python操作excel主要用到xlrd和xlwt這兩個庫，即xlrd是讀excel，xlwt是寫excel的庫。 今天就先來說一下xl ......

    uj5u.com 2020-09-10 05:36:28 more
  • 當我們創建HashMap時，底層到底做了什么？

    jdk1.7中的底層實作程序（底層基于陣列+鏈表） 在我們new HashMap()時，底層創建了默認長度為16的一維陣列Entry[ ] table。當我們呼叫map.put(key1,value1)方法向HashMap里添加資料的時候： 首先，呼叫key1所在類的hashCode()計算key1 ......

    uj5u.com 2020-09-10 05:36:38 more
最新发布
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式，它可以用來減少類之間的直接依賴關系，
    * 將物件之間的通信封裝到一個中介者物件中，從而使得各個物件之間的關系更加松散。
    * 在中介者模式中，物件之間不再直接相互互動，而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:20:47 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點，專案投資大概1億，包括了礦山的各方面的內容，顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃，有很多煤礦行業專家的加持，他們的描述是非常完美，但是去年底應該上線的平臺，現在還沒有看到影子。他們確實有很多場景需求，但是被... ......

    uj5u.com 2023-04-20 08:20:25 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序，開始編碼、測驗、除錯之前進行需求分析和架構設計，才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:20:17 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師，不僅僅要緊跟行業技術趨勢，還要結合研發團隊現狀及痛點，探索新的交付方案。在日常中，你是否遇到如下問題 “ 業務需求排期長研發是瓶頸；非研發角色感受不到研發技改提效的變化；引入ISV 團隊又擔心質量和安全，培訓周期長“等等，基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:20:10 more
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式，它可以用來減少類之間的直接依賴關系，
    * 將物件之間的通信封裝到一個中介者物件中，從而使得各個物件之間的關系更加松散。
    * 在中介者模式中，物件之間不再直接相互互動，而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:19:44 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點，專案投資大概1億，包括了礦山的各方面的內容，顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃，有很多煤礦行業專家的加持，他們的描述是非常完美，但是去年底應該上線的平臺，現在還沒有看到影子。他們確實有很多場景需求，但是被... ......

    uj5u.com 2023-04-20 08:19:07 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序，開始編碼、測驗、除錯之前進行需求分析和架構設計，才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:18:57 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師，不僅僅要緊跟行業技術趨勢，還要結合研發團隊現狀及痛點，探索新的交付方案。在日常中，你是否遇到如下問題 “ 業務需求排期長研發是瓶頸；非研發角色感受不到研發技改提效的變化；引入ISV 團隊又擔心質量和安全，培訓周期長“等等，基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:18:49 more
  • 05單件模式

    #經典的單件模式 public class Singleton { private static Singleton uniqueInstance; //一個靜態變數持有Singleton類的唯一實體。 // 其他有用的實體變數寫在這里 //構造器宣告為私有，只有Singleton可以實體化這個類! ......

    uj5u.com 2023-04-19 08:42:51 more
  • 【架構與設計】常見微服務分層架構的區別和落地實踐

    軟體工程的方方面面都遵循一個最基本的道理：沒有銀彈，架構分層模型更是如此，每一種都有各自優缺點，所以請根據不同的業務場景，并遵循簡單、可演進這兩個重要的架構原則選擇合適的架構分層模型即可。 ......

    uj5u.com 2023-04-19 08:42:41 more

Copyright © 2010-2020 有解無憂