簡介一套基于Qt5與FFmpeg開發(fā)的視頻播放器完整源碼工程面向需要學習音視頻解碼與Qt界面編程的開發(fā)者也適合在已有項目中快速加入播放功能。壓縮包共43個文件大小約20.08MB既包含C源碼、界面文件、資源文件和工程配置也保留了構(gòu)建日志與調(diào)試文件并附帶flv測試視頻其中.pro方案可配合qmake使用.sln/.vcxproj便于在Visual Studio中打開.ui與.qrc則對應(yīng)界面布局和資源管理。目前已有2453人學習下載具備一定參考價值。源碼覆蓋播放器主界面、控制交互、FFmpeg初始化解碼以及視頻幀讀取與顯示等核心環(huán)節(jié)從工程搭建到播放邏輯都給出可直接運行的版本復制后配置好Qt與FFmpeg環(huán)境即可編譯使用也可在此基礎(chǔ)之上擴展音視頻同步、倍率播放等功能是桌面播放器開發(fā)的實用樣本。1. 為什么播放器源碼里最難的不是解碼先說結(jié)論用 Qt 和 FFmpeg 寫視頻播放器解碼器的調(diào)用只是查文檔的功夫真正讓開發(fā)者熬夜的是音視頻同步、線程模型、渲染路徑這三件事。網(wǎng)上能搜到的播放器源碼大部分能跑通但畫面卡頓、聲音超前、拖動進度條后對不上嘴型這些問題恰恰是源碼里最值得抄作業(yè)的部分。這篇文章面向兩類讀者一是想拿一套可復用的 Qt FFmpeg 播放器源碼做二次開發(fā)的開發(fā)者二是正在從零寫播放器、想知道每一步該怎么選型和避坑的初學者。我會把一條可落地的技術(shù)路線拆開講先講為什么這么設(shè)計再講每一步怎么實現(xiàn)最后給參數(shù)和踩坑清單。你不需要從零發(fā)明播放器但需要理解源碼里每一層在解決什么問題這樣改起來才有底氣。2. 播放器的整體架構(gòu)解碼、隊列、渲染的三角關(guān)系2.1 為什么必須用多線程單線程解碼會卡死界面播放器的核心鏈路是讀文件、解封裝、解碼、轉(zhuǎn)換格式、渲染。如果全部放在 UI 線程里解碼一幀 1080p 視頻大約需要 20 到 50 毫秒加上音頻處理和渲染開銷UI 線程會被占用大半。窗口拖動、按鈕點擊都會變得遲鈍甚至直接卡死。常見的做法是把這條鏈路拆成三個線程解封裝與解碼線程、音頻播放線程、視頻渲染線程。三個線程之間用隊列解耦解碼線程只管往隊列里塞數(shù)據(jù)渲染線程按自己的節(jié)奏取數(shù)據(jù)互不等待。[解封裝/解碼線程] - [視頻隊列] - [視頻渲染線程] - [音頻隊列] - [音頻輸出設(shè)備]如果你拿到的源碼只有一個線程那它多半只是教學 Demo支撐不了長時間播放或高分辨率視頻。動手改造的第一步就是確認線程模型是否已經(jīng)拆開。2.2 隊列緩沖為什么不能解碼一幀就渲染一幀解碼器的輸出速度不是均勻的。視頻的 I 幀可能瞬間解碼出大塊數(shù)據(jù)B 幀則快很多。如果解碼一幀立刻渲染一幀畫面節(jié)奏會跟著解碼速度走而不是跟著時間軸走表現(xiàn)出來的就是忽快忽慢。隊列在這個環(huán)節(jié)起到兩個作用一是吸收解碼速度的抖動讓渲染線程有穩(wěn)定的數(shù)據(jù)來源二是為音視頻同步提供緩沖空間。沒有隊列同步邏輯無從談起。我見過不少新手把隊列設(shè)計成無限增長結(jié)果播放一小時后內(nèi)存漲幾百兆。隊列一定要設(shè)上限視頻隊列一般放 30 到 60 幀音頻隊列按 0.5 秒到 1 秒的數(shù)據(jù)量來限制。當隊列滿了解碼線程要阻塞等待而不是繼續(xù)解碼。2.3 FFmpeg 的解碼上下文管理一個典型的初始化序列解碼初始化是播放器源碼里最固定的部分也是新手最容易寫錯的地方。完整流程是打開文件、查流信息、找視頻流、創(chuàng)建解碼器、打開解碼器。下面是這個過程的典型代碼AVFormatContext *fmtCtx nullptr; if (avformat_open_input(fmtCtx, filename, nullptr, nullptr) 0) { // 文件打不開或格式無法識別 return -1; } if (avformat_find_stream_info(fmtCtx, nullptr) 0) { return -1; } int videoStreamIndex av_find_best_stream(fmtCtx, AVMEDIA_TYPE_VIDEO, -1, -1, nullptr, 0); AVStream *videoStream fmtCtx-streams[videoStreamIndex]; const AVCodec *decoder avcodec_find_decoder(videoStream-codecpar-codec_id); AVCodecContext *codecCtx avcodec_alloc_context3(decoder); avcodec_parameters_to_context(codecCtx, videoStream-codecpar); if (avcodec_open2(codecCtx, decoder, nullptr) 0) { return -1; }這段代碼有幾點要注意。av_find_best_stream比手動遍歷流列表更可靠它會自動跳過字幕流和數(shù)據(jù)流返回最佳的流索引。codecpar是 AVStream 里的參數(shù)不能直接從codecCtx拿因為此時解碼器上下文還沒初始化必須先拷貝參數(shù)再打開解碼器。如果是硬解場景avcodec_find_decoder要改成avcodec_find_decoder_by_name(h264_cuvid)之類的硬解名稱但初始化流程不變。2.4 像素格式轉(zhuǎn)換YUV 到 RGB 的一步不能省FFmpeg 解碼出來的視頻幀默認是 YUV420P而 Qt 的 QWidget 渲染和 QImage 通常接收 RGB 格式。中間這層轉(zhuǎn)換由sws_scale完成幾乎每個播放器源碼都有這段邏輯。轉(zhuǎn)換上下文的創(chuàng)建可以復用不需要每幀重新創(chuàng)建SwsContext *swsCtx sws_getContext( codecCtx-width, codecCtx-height, codecCtx-pix_fmt, codecCtx-width, codecCtx-height, AV_PIX_FMT_RGB24, SWS_BILINEAR, nullptr, nullptr, nullptr);SWS_BILINEAR是性價比最高的縮放算法。追求畫質(zhì)可以換SWS_LANCZOS但 CPU 占用會明顯上升追求低分辨率預覽可以用SWS_FAST_BILINEAR畫質(zhì)會差一些但速度快。播放器這種場景我一般固定用SWS_BILINEAR不要做成可配置的否則后續(xù)排錯時多一個變量。3. 核心循環(huán)與時鐘設(shè)計同步問題的根基3.1 解碼循環(huán)不要用 sleep 控制節(jié)奏解碼線程的主循環(huán)最常見的錯誤寫法是死循環(huán)里加QThread::msleep(10)之類的延時試圖通過降低解碼速度來匹配播放速度。這會帶來兩個問題一是延時不精確做不到與幀率對齊二是音頻和視頻的解碼節(jié)奏會被強行綁在一起同步邏輯無法介入。正確的做法是讓解碼線程以最高速度工作能解多少解多少但隊列滿時阻塞。這樣解碼器始終處于工作狀態(tài)而節(jié)奏控制由渲染線程通過隊列消費速度來實現(xiàn)。下面是一個典型的解碼循環(huán)骨架while (!m_stopRequested) { if (m_videoQueue.size() MAX_VIDEO_QUEUE_SIZE) { QThread::msleep(5); continue; } AVPacket packet; if (av_read_frame(fmtCtx, packet) 0) { // 讀到文件尾或出錯標記結(jié)束 break; } if (packet.stream_index videoStreamIndex) { int ret avcodec_send_packet(codecCtx, packet); if (ret 0) { AVFrame *frame av_frame_alloc(); if (avcodec_receive_frame(codecCtx, frame) 0) { m_videoQueue.enqueue(frame); } else { av_frame_free(frame); } } } av_packet_unref(packet); }隊列滿時用msleep(5)退避是簡單且可靠的做法但要確保最終檢測到m_stopRequested能及時退出否則退出播放時線程可能被困在循環(huán)里。avcodec_send_packet和avcodec_receive_frame是 FFmpeg 3.x 之后推薦的解碼接口舊的avcodec_decode_video2已經(jīng)廢棄如果你拿到的源碼還在用舊接口建議遷移因為新接口能正確處理多幀返回和延遲幀。3.2 兩類時鐘系統(tǒng)時鐘與音頻時鐘同步的核心是有一個統(tǒng)一的時鐘基準。常見的做法有兩種以系統(tǒng)時間為基準的gettimeofday或QElapsedTimer以音頻設(shè)備已播放的采樣數(shù)為基準的音頻時鐘。兩者都能用但語義差別很大。系統(tǒng)時間時鐘實現(xiàn)最簡單每渲染一幀就讀取當前時間與幀的 PTS 做差差值大于閾值就丟幀或等待。但它有個致命弱點如果系統(tǒng)負載升高解碼線程或渲染線程被調(diào)度延遲這個時鐘的讀數(shù)會跟著推遲同步判斷就失真。音頻時鐘則不同它以音頻設(shè)備消費的采樣數(shù)來推算當前時間位置和系統(tǒng)的負載無關(guān)。我處理過的真實項目里本地播放用系統(tǒng)時間也能做但遇到高分辨率視頻或低配機器畫面會周期性抖動。后來改為主時鐘用音頻時鐘、視頻幀按 PTS 時間戳調(diào)度抖動的頻率立刻降下來了。音頻初始化時需要先拿到音頻流的采樣率、聲道數(shù)、樣本格式配置好 Qt 的QAudioFormat然后創(chuàng)建一個線程獨立運行。音頻時鐘的實現(xiàn)直接依賴音頻設(shè)備的回放進度和隊列尾部時間戳qreal getAudioClock() { qreal pts m_audioClockPts; // 隊列中音頻幀的 PTS qreal delta m_audioDevice-processedUSecs() / 1000000.0; return pts delta; }這里的m_audioClockPts要在每次寫入音頻數(shù)據(jù)時更新processedUSecs的起點是start()之后設(shè)備真正開始播放的時間兩者相加就是音頻當前在時間軸上的位置。細節(jié)上有偏差但不影響整體同步精度。4. 用 QWidget 渲染視頻從 AVFrame 到屏幕的完整路徑4.1 標準轉(zhuǎn)換AVFrame 到 QImage 到 QPixmap視頻解碼得到AVFrame后要交給 Qt。最常見的路徑是把AVFrame先轉(zhuǎn)成QImage再轉(zhuǎn)成QPixmap繪制到控件上。這段邏輯看起來簡單但有兩個高頻坑字節(jié)對齊和格式匹配。AVFrame *frame /* 來自解碼線程 */; // sws_scale 轉(zhuǎn)換后得到 RGB24 數(shù)據(jù) uint8_t *rgbData new uint8_t[frame-width * frame-height * 3]; int linesize frame-width * 3; sws_scale(swsCtx, frame-data, frame-linesize, 0, frame-height, rgbData, linesize); QImage image(rgbData, frame-width, frame-height, linesize, QImage::Format_RGB888); QPixmap pixmap QPixmap::fromImage(image); delete[] rgbData;這里最容易翻車的是linesize。FFmpeg 的frame-linesize[0]是 Y 平面的行字節(jié)數(shù)它不一定等于width * 3有時會多出幾個字節(jié)做對齊。如果直接拿這個值傳給QImage畫面會出現(xiàn)斜條紋或顏色偏移。上面代碼用frame-width * 3作為QImage的bytesPerLine參數(shù)并在sws_scale里同步指定才能保證格式一致。另一個坑是rgbData必須保證 QImage 使用期間不能被釋放。示例代碼里在QImage構(gòu)造后立即轉(zhuǎn)QPixmap所以可以馬上delete但如果QImage要跨函數(shù)使用就要用QImage::copy()深拷貝一份再返回否則指針釋放后圖像數(shù)據(jù)懸空輕則花屏重則崩潰。4.2 QWidget 繪制路徑對比三種方式的取舍QWidget 渲染視頻主要有三條路線源碼里常見的是第一種繪制方式實現(xiàn)成本性能適用場景paintEvent里drawPixmap最低中等低分辨率、局部刷新需求QGraphicsView QGraphicsPixmapItem較低中高需要縮放、旋轉(zhuǎn)等圖形變換QOpenGLWidget 紋理上傳較高高4K、高幀率、硬件加速需求大多數(shù)播放器源碼用第一種就夠了。如果項目對性能有要求建議在初始化階段讀一下系統(tǒng)信息再做選擇4K 片源直接走 OpenGL 路線SD 片源用 QWidget 即可。void VideoWidget::paintEvent(QPaintEvent *event) { QPainter painter(this); if (m_pixmap.isNull()) { painter.fillRect(rect(), Qt::black); return; } QSize scaledSize m_pixmap.size(); scaledSize.scale(rect().size(), Qt::KeepAspectRatio); QPoint topLeft (rect().size() - scaledSize) / 2; painter.drawPixmap(topLeft, m_pixmap.scaled(scaledSize, Qt::KeepAspectRatio, Qt::SmoothTransformation)); }這段邏輯里有一個常見失誤每幀都調(diào)用scaled()重新縮放。如果窗口大小不變這個縮放是多余的浪費大量 CPU。優(yōu)化做法是只在窗口大小變化時重新縮放保存一份m_scaledPixmappaintEvent里直接繪制緩存。源碼里如果每幀都在scaled建議改成這種惰性縮放幀率能提升不少。4.3 線程邊界QImage 在解碼線程創(chuàng)建、UI 線程使用的問題解碼線程把QImage送進隊列UI 線程取出來繪制。嚴格來說這沒有問題因為QImage是值類型內(nèi)部對數(shù)據(jù)塊做引用計數(shù)隱式共享機制保證先拷貝引用、后深拷貝數(shù)據(jù)。但有一個關(guān)鍵前提創(chuàng)建QImage的線程和消費它的線程不能同時對同一份數(shù)據(jù)做寫操作。所以在解碼線程里這樣寫是安全的QImage frameImage(rgbData, width, height, bytesPerLine, QImage::Format_RGB888); m_queue.enqueue(frameImage); // 拷貝引用數(shù)據(jù)共享但 UI 線程如果調(diào)image.scaled()、image.rgbSwapped()這類修改自身的方法就會觸發(fā)深拷貝數(shù)據(jù)沒問題只是多一次耗時。最大的風險不在 QImage而在釋放順序——解碼線程自己分配的內(nèi)存必須由解碼線程自己釋放否則可能 double free?？缇€程傳遞時盡量用QImage這類自帶引用計數(shù)的對象不要用裸指針 手動管理內(nèi)存的方式。5. 音視頻同步實現(xiàn)A/V 時間戳對齊的三個關(guān)鍵細節(jié)音視頻同步是播放器源碼的核心難點也是能不能真正落地用的分水嶺。拿到源碼后先看它采用的是哪種同步策略再決定改動方向。5.1 以音頻為主時鐘的同步模型最常見的同步模型是選音頻為基準時鐘。原因很簡單人耳對音頻斷續(xù)比眼睛對視頻卡頓更敏感音頻斷斷續(xù)續(xù)直接無法忍受而視頻丟幾幀大多數(shù)人感知不到。所以讓音頻保持連續(xù)播放視頻幀按需要提前或推后是體驗最好的方案。同步公式可以寫成這樣視頻應(yīng)顯示時間 視頻幀 PTS - 音頻時鐘 差值 0視頻慢于音頻需要加速顯示或丟幀 差值 0視頻快于音頻需要等待這個差值的處理閾值要根據(jù)片源特性來選擇沒有統(tǒng)一的絕對最優(yōu)值但經(jīng)驗值可以作為起點。5.2 閾值設(shè)置上一收藏到小于 100ms 的抖動不要立刻丟幀同步最怕抖動。音頻時鐘的讀數(shù)本身有噪聲視頻 PTS 在不同封裝格式下也有微小的不規(guī)則性。如果每幀都做丟幀判斷差值稍微波動就丟幀畫面會頻繁跳動體驗更差。常見做法是設(shè)置遲滯區(qū)qreal diff videoPts - audioClock(); if (diff 0.08) { // 視頻落后太多丟幀加速追 dropCurrentFrame(); } else if (diff -0.08) { // 視頻超前太多等待當前幀目標時間再顯示 waitUntil(videoPts); } else { // 在同步窗口內(nèi)正常顯示 renderFrame(); }這個 80ms 的閾值是本地播放經(jīng)驗的折中值。低于 50ms 時網(wǎng)絡(luò)流或高碼率視頻會頻繁觸發(fā)丟幀高于 150ms 時嘴型對不上的感知開始變得明顯。值得強調(diào)的一點是丟幀策略要優(yōu)先丟 P 幀或 B 幀絕不能丟 I 幀否則會引發(fā)連續(xù)花屏。5.3 seek 操作后的同步重置最容易被忽略的一次復位拖動進度條后同步狀態(tài)完全被打亂。解碼隊列里殘留著舊位置的幀音頻設(shè)備還播著舊數(shù)據(jù)。如果只清隊列不做時鐘復位畫面會先跳到新位置然后又被舊幀拉回舊位置播放幾秒后才恢復。完整的 seek 復位應(yīng)該包括av_seek_frame(fmtCtx, videoStreamIndex, targetPts, AVSEEK_FLAG_BACKWARD); avcodec_flush_buffers(codecCtx); // 清空兩個隊列 m_videoQueue.clear(); m_audioQueue.clear(); // 重置同步狀態(tài) m_audioClockPts 0; m_isSeeking true;AVSEEK_FLAG_BACKWARD讓 FFmpeg 定位到目標時間點之前最近的可用關(guān)鍵幀這樣可以保證立即取到可解碼的幀。avcodec_flush_buffers告訴解碼器丟棄內(nèi)部緩存的所有參考幀否則重啟解碼時會產(chǎn)生大量錯誤幀。需要提到的細節(jié)是seek 后第一次解碼出的幀的 PTS 可能遠小于目標時間點如果立即同步畫面會閃一下。所以完整的實現(xiàn)里seek 后要跳過 PTS 小于目標時間的幀直到第一幀 PTS 逼近目標值再恢復渲染。源碼里如果沒有這個跳過邏輯實際體驗會非常奇怪。還有幾個不太容易被注意但實際影響體驗的小點會在排查章節(jié)里展開這里的脈絡(luò)是同步模型先定基準再定閾值最后處理 seek 等中斷場景三步寫全才能算完整實現(xiàn)。6. 排查與避坑播放器的 5 個典型故障對照6.1 音頻正常但畫面卡頓現(xiàn)象聲音連續(xù)畫面每隔幾秒卡一下卡的時候 CPU 占用沒有異常變化。原因視頻隊列消費速度跟不上生產(chǎn)速度或者視頻渲染與 UI 線程的刷新節(jié)奏沖突比如QWidget::update()被高頻調(diào)用導致事件堆積。解決先確認視頻隊列的長度是否持續(xù)增長是則說明渲染端消耗太慢優(yōu)先查繪制路徑里是否有每幀scaled()。再確認是否在paintEvent里做了不必要的深拷貝典型做法是QPixmap::fromImage(image.copy())這個copy()會觸發(fā)整幀內(nèi)存復制1080p 下每次接近 6MB卡頓在所難免。6.2 畫面正常但聲音斷續(xù)或爆音現(xiàn)象畫面流暢聲音每過幾秒就“咔”一下或開播時正常、播放幾分鐘后開始撕裂。原因音頻隊列供給不穩(wěn)定解碼線程在音頻隊列滿和視頻隊列滿之間切換導致音頻數(shù)據(jù)到達不勻速另一個常見原因是 FFmpeg 輸出的是浮點樣本而QAudioOutput配置為有符號整型樣本格式不匹配直接產(chǎn)生爆音。解決檢查QAudioFormat的setSampleFormat是否與解碼器輸出一致。FFmpeg 的AV_SAMPLE_FMT_FLTP對應(yīng) Qt 的QAudioFormat::FloatAV_SAMPLE_FMT_S16P對應(yīng)QAudioFormat::Int16。如果格式不匹配需要用swr_convert做音頻重采樣這是源碼里最容易漏掉的一步。6.3 拖動進度條后畫面卡死或黑屏現(xiàn)象執(zhí)行 seek 后播放器停止輸出畫面但音頻正?；蛘弋嬅婊謴秃蠡ㄆ烈偻蟿右淮尾耪?。原因多數(shù)是 seek 后只清了視頻隊列沒清音頻隊列導致兩邊的時鐘基準錯位或者flush_buffers之后第一個解碼幀是參考幀直接送去渲染造成花屏。解決seek 時必須同時清空兩個隊列并重置主時鐘然后跳過第一個關(guān)鍵幀從第二幀開始正常渲染。代碼順序上av_seek_frame和avcodec_flush_buffers后循環(huán)讀取直到第一個AVFrame返回成功且 PTS 不小于目標值才恢復同步邏輯。6.4 播放到最后程序崩潰退出時卡住現(xiàn)象視頻播放到最后幾秒關(guān)閉窗口時程序進入掛起狀態(tài)要強制結(jié)束進程。原因解碼線程還在av_read_frame讀末尾數(shù)據(jù)UI 線程已經(jīng)銷毀了解碼相關(guān)對象兩個線程在同一個AVFormatContext上并發(fā)操作。解決退出流程要先請求解碼線程停止用互斥鎖保護m_stopRequested等線程退出后再銷毀資源。順序是置停止標志 → 喚醒阻塞中的線程 → 等待線程結(jié)束 → 釋放AVFormatContext和AVCodecContext。如果源碼里直接在析構(gòu)函數(shù)里avformat_close_input那就是隱患所在。6.5 硬解開啟后畫面正常但 CPU 不降反升現(xiàn)象源碼支持硬解配置了h264_cuvid或hevc_qsv后畫面正常但 CPU 占用率依然很高甚至比軟解還高。原因解碼器解碼后輸出的仍然是硬件格式幀如AV_PIX_FMT_NV12然后轉(zhuǎn)成 RGB 時sws_scale會把數(shù)據(jù)從 GPU 拉回 CPU再做格式轉(zhuǎn)換開銷反而更大。解決檢查解碼后的frame-format。如果是硬件格式就先做av_hwframe_transfer_data把硬件幀拷回系統(tǒng)內(nèi)存再用 GPU 上的scale方案或直接使用QOpenGLWidget把 NV12 數(shù)據(jù)直接綁定為紋理由顯卡完成 YUV 到 RGB 轉(zhuǎn)換。走 CPU 回讀必然是死路。7. 幾個能立刻提升播放體驗的進階小技巧前面把主流程和排查過了一遍最后寫幾個不影響架構(gòu)、改動量小但能明顯改善上手體驗的技巧也都是源碼交付后我一般會先做的事。第一個是視頻窗口的異步縮放。paintEvent里的scaled改成等窗口 resize 后再緩存縮放結(jié)果在事件循環(huán)里用定時器做防抖窗口尺寸穩(wěn)定的狀態(tài)下幀率會明顯變化。改動不超過 20 行收益非常直接。第二個是緩沖策略從“滿再播”改為“快滿再播”。初始化時先把音頻隊列填充 500ms 的數(shù)據(jù)再啟動輸出能顯著減少開播時的爆音和斷續(xù)。手感上接近直播應(yīng)用的開播延遲體驗但本地文件沒必要等那么久300 到 500ms 就夠了。第三個是倍速播放的音頻處理。FFmpeg 的解碼器不支持變速變速要在音頻輸出端做。Qt 的QMediaPlayer自帶倍速邏輯但在 Qt FFmpeg 的裸實現(xiàn)里通常依賴swr_ctx的audio_resample配合av_audio_convert或者最簡單的丟棄/重復樣本這些做法都會改變音調(diào)。實踐中更常見的方式是把音頻時鐘的步長按倍速比例縮放視頻幀的出幀節(jié)奏同步加倍音調(diào)失真可以接受但不是高保真方案。驗證一版改動是否生效用 4K 高碼率視頻連續(xù)播放 30 分鐘觀察音頻時鐘與視頻時鐘差值是否在 100ms 以內(nèi)浮動再反復做 seek 操作每次 seek 后畫面應(yīng)在 500ms 內(nèi)恢復同步狀態(tài)。這兩組測試通過播放器基本可以放心交付。項目里遇到過很多同學在拼裝源碼時追求多加功能結(jié)果同步一直調(diào)不對后來把倍速、硬解都先關(guān)掉專項調(diào)同步才把根子解決。說句實話Qt FFmpeg 播放器源碼網(wǎng)上能下到的版本不少但真正能作為產(chǎn)品底座的不多差別不在渲染也不在某一個解碼格式支持而在同步策略和線程退出的處理這兩塊是源碼里最有閱讀價值的段落。讀源碼的時候先讀這兩個模塊比先看界面代碼有用得多。這也是我自己復查源碼時的習慣希望幫到你。本文還有配套的精品資源點擊獲取