Qt編寫安防視頻監(jiān)控系統(tǒng)40-onvif線程處理

# 一、前言

整個onvif模塊大部分的功能都有了以后，除了在demo上點點按鈕可以執(zhí)行獲取結(jié)果顯示外，最終還是要應用到視頻監(jiān)控中，在按鈕上點點和系統(tǒng)中后臺自動運行是兩碼事，比如onvif校時和事件訂閱，不會說是傻到在監(jiān)控系統(tǒng)界面上提供按鈕給用戶點擊才去執(zhí)行，最多做的應該是系統(tǒng)設置中提供兩個開關比如自動校時、事件訂閱，可以方便的開啟這幾個功能。開啟以后等監(jiān)控系統(tǒng)啟動后自動去處理，比如挨個對攝像機進行校時處理以及訂閱事件，為了能夠做到添加攝像機后自動立即應用，特意改成了在打開攝像機視頻畫面的時候，主動去實例化DeviceOnvif類（每個攝像機都對應一個實例）

最開始的做法是采用定時器去處理要指定的指令隊列，后面發(fā)現(xiàn)速度不好控制，畢竟網(wǎng)絡請求受網(wǎng)速和網(wǎng)絡環(huán)境的影響，有時候100毫秒就執(zhí)行完成了，有時候又需要300毫秒不等，盡管網(wǎng)絡請求的時候已經(jīng)設置了超時時間（這個時間一般設置成2-3秒，保證請求有足夠的時候返回），這個時間有點大，如果按照這個網(wǎng)絡請求超時時間來設定定時器，設備數(shù)量很多的時候太慢了，監(jiān)控系統(tǒng)一般幾十個設備是有的，這蝸牛一樣的速度要處理到何年馬月，而且每個攝像機有多個指令需要處理比如自動校時、事件訂閱等。

那有沒有一種機制可以盡最快的速度排隊處理呢，答案是當然，這不就是線程擅長干的事情嗎，使勁的干，休息多久自由msleep控制即可，網(wǎng)絡環(huán)境好的情況下，20個設備的指令基本上在1s內(nèi)完成的，這就能夠滿足用戶的需求，畢竟用戶打開軟件后，大概率不想等待太長時間，就像能夠看到所有攝像機時間自動校準好了，搞個攝像機報警也能立即通過onvif協(xié)議上報，該處理的都盡快處理完了。

QNetworkAccessManager類如果一開始不是在線程中new出來的，會提示不能在其他線程執(zhí)行，這就需要在線程的run函數(shù)中調(diào)用QMetaObject::invokeMethod來執(zhí)行對應的處理，一個萬能的處理方法就是將需要執(zhí)行的全部放在work函數(shù)中，搞個iswork標志位，進入該開始的時候?qū)酥疚籭swork=true，處理結(jié)束后iswork=false，在run中先判斷標志位是否為假，為假表示當前不在工作，則去調(diào)用work函數(shù)處理。這就規(guī)避了在線程中執(zhí)行其他線程類對象函數(shù)的錯誤提示。

基本的處理思路

- 查詢出所有的攝像機信息。

- 過濾攝像機信息，找出所有具備onvif地址的，只有具備onvif地址的才是需要去處理的。

- 從deviceonvif鏈表中找到當前onvif地址的設備類對象，該方法同時肩帶new出實例在沒有找到對應實例的情況下。

- 將對應的處理轉(zhuǎn)成命令指令隊列，帶有onvif地址標識，交給onvifthread線程類專門處理。

- 所有的方法在該實例中都有對應方法進行處理，對該實例調(diào)用對應的方法比如校時、事件訂閱、抓圖等。

- 處理完成后將對應的結(jié)果信號發(fā)出去，對應三個參數(shù)分別表示onvif地址、指令、結(jié)果數(shù)據(jù)（QVariant類型）。

onvif主要的功能

1. 搜索設備，獲取設備的信息比如廠家、型號等。

2. 獲取設備的多個配置文件信息profile。

3. 獲取對應配置文件的視頻流地址rtsp，以及分辨率等參數(shù)。

4. 云臺控制，上下左右移動，焦距放大縮小，相對和絕對移動。

5. 獲取預置位信息，觸發(fā)預置位。

6. 訂閱事件，接收設備的各種消息尤其是報警事件比如IO口的報警。

7. 抓圖，獲取設備當前的圖片。

8. 獲取、創(chuàng)建、刪除用戶信息。

9. 獲取和設備網(wǎng)絡配置信息比如IP地址等。

10. 獲取和設置NTP時間同步。

11. 獲取和設置設備時間。

12. 重啟設備。

onvif的處理流程

1. 綁定組播IP（239.255.255.250）和端口（3702），發(fā)送固定的xml格式的數(shù)據(jù)搜索設備。

2. 接收到的xml格式的數(shù)據(jù)解析，得到設備的Onvif地址。

3. 對Onvif地址發(fā)送對應的數(shù)據(jù)，收到數(shù)據(jù)取出對應的節(jié)點數(shù)據(jù)。

4. 請求Onvif地址獲取Media地址和Ptz地址，Media地址用來獲取詳細的配置文件，Ptz地址用來云臺控制。

5. ptz控制是對Ptz地址發(fā)送對應的數(shù)據(jù)即可。

6. 設置了用戶認證的需要組織用戶token信息一塊發(fā)送，每次都需要作鑒權處理。

7. 接收到的數(shù)據(jù)不是標準的xml數(shù)據(jù)，沒法按照正常的節(jié)點解析來處理，只能用QXmlQuery來做。

8. 每個廠家設備返回的數(shù)據(jù)未必完全一致，基本上都不一致，需要進行模糊查找節(jié)點值。

9. 特意采用底層協(xié)議解析，因為soap太臃腫函數(shù)名稱太另類，特意做的輕量級的。

10. 兩個必備工具，Onvif Device Manager 和 Onvif Device Test Tool。

## 二、功能特點

### （一）軟件模塊

1. 視頻監(jiān)控模塊，各種停靠小窗體子模塊，包括設備列表、圖文警情、窗口信息、云臺控制、預置位、巡航設置、設備控制、懸浮地圖、網(wǎng)頁瀏覽等。

2. 視頻回放模塊，包括本地回放、遠程回放、設備播放、圖片回放、視頻上傳等。

3. 電子地圖模塊，包括圖片地圖、在線地圖、離線地圖、路徑規(guī)劃等。

4. 日志查詢模塊，包括本地日志、設備日志等。

5. 系統(tǒng)設置模塊，包括系統(tǒng)設置（基本設置、視頻參數(shù)、數(shù)據(jù)庫設置、地圖配置、串口配置等）、錄像機管理、攝像機管理、輪詢配置、用戶管理等。

### （二）基礎功能

1. 支持各種視頻流（rtsp、rtmp、http等）、視頻文件（mp4、rmvb、avi等）、本地USB攝像機播放。

2. 支持多畫面切換，包括1、4、6、8、9、13、16、25、36、64畫面切換。

3. 支持全屏切換，多種切換方式包括鼠標右鍵菜單、工具欄按鈕、快捷鍵（alt+enter全屏，esc退出全屏）。

4. 支持視頻輪詢，包括1、4、9、16畫面輪詢，可設置輪詢分組（輪詢預案）、輪詢間隔、碼流類型等。

5. 支持onvif協(xié)議，包括設備搜索、云臺控制、設備控制（圖片參數(shù)、校對時間、系統(tǒng)重啟，抓拍圖片等）。

6. 支持權限管理，不同的用戶可以對應不同的模塊權限，比如刪除日志、關閉系統(tǒng)等。

7. 數(shù)據(jù)庫支持多種，包括sqlite、mysql、sqlserver、postgresql、oracle、人大金倉等。

8. 本地USB攝像機支持設置分辨率、幀率等參數(shù)。

9. 所有停靠模塊都自動生成對應的菜單用來控制顯示和隱藏，在標題欄右鍵可以彈出。

10. 支持顯示所有模塊、隱藏所有模塊、復位普通布局、復位全屏布局。

11. 雙擊設備彈出實時預覽視頻，支持圖片地圖、在線地圖、離線地圖等。

12. 攝像機節(jié)點拖曳到對應窗體播放視頻，同時支持拖曳本地文件直接播放。

13. 刪除視頻支持鼠標右鍵刪除、懸浮條關閉刪除、拖曳到視頻監(jiān)控面板外刪除等多種方式。

14. 圖片地圖上設備按鈕可自由拖動，自動保存位置信息。百度地圖上可以鼠標單擊獲取經(jīng)緯度信息，用來更新設備位置。

15. 視頻監(jiān)控面板窗體中任意通道支持拖曳交換，瞬間響應。

16. 封裝了百度地圖，視圖切換，運動軌跡，設備點位，鼠標按下獲取經(jīng)緯度等。

17. 雙擊節(jié)點、拖曳節(jié)點、拖曳窗體交換位置等操作，均自動更新保存最后的播放地址，下次軟件打開自動應用。

18. 右下角音量條控件，失去焦點自動隱藏，音量條帶靜音圖標。

19. 支持視頻截圖，可指定單個或者對所有通道截圖，底部小工具欄也有截圖按鈕。

20. 支持超時自動隱藏鼠標指針、自動全屏機制。

21. 支持onvif云臺控制，可上下左右移動云臺攝像機，包括復位和焦距調(diào)整等。

22. 支持任意onvif攝像機，包括但不限于海康、大華、宇視、天地偉業(yè)、華為等。

23. 可保存視頻，可選定時存儲或者單文件存儲，可選存儲間隔時間。

24. 可設置視頻流通信方式tcp+udp，可設置視頻解碼是速度優(yōu)先、質(zhì)量優(yōu)先、均衡等。

25. 可設置軟件中文名稱、英文名稱、LOGO圖標等。

26. 存儲的視頻文件支持導出到指定目錄，支持批量上傳到服務器。

### （三）特色功能

1. 主界面采用停靠窗體模式，各種組件以小模塊的形式加入，可自定義任意模塊加入。

2. 停靠模塊可拖動任意位置嵌入和懸浮，支持最大化全屏，支持多屏幕。

3. 雙重布局文件存儲機制，正常模式、全屏模式都對應不同的布局方案，自動切換和保存，比如全屏模式可以突出幾個模塊透明顯示在指定位置，更具科幻感現(xiàn)代化。

4. 原創(chuàng)onvif協(xié)議機制，采用底層協(xié)議解析（udp廣播搜索+http請求執(zhí)行命令）更輕量易懂易學習拓展，不依賴任何第三方組件比如gsoap。

5. 原創(chuàng)數(shù)據(jù)導入導出機制，跨平臺不依賴任何組件，瞬間導出數(shù)據(jù)。

6. 內(nèi)置多個原創(chuàng)組件，宇宙超值超級牛逼，包括數(shù)據(jù)導入導出組件（導出到xls、pdf、打印）、數(shù)據(jù)庫組件（數(shù)據(jù)庫管理線程、自動清理數(shù)據(jù)線程、萬能分頁、數(shù)據(jù)請求等）、地圖組件、視頻監(jiān)控組件、文件多線程收發(fā)組件、onvif通信組件、通用瀏覽器內(nèi)核組件等。

7. 自定義信息框+錯誤框+詢問框+右下角提示框（包含多種格式）等。

8. 精美換膚，高達17套皮膚樣式隨意更換，所有樣式全部統(tǒng)一，包括菜單等。

9. 視頻控件懸浮條可以自行增加多個按鈕，監(jiān)控界面底部小工具欄也可自行增加按鈕。

10. 雙擊攝像機節(jié)點自動播放視頻，雙擊節(jié)點自動依次添加視頻，會自動跳到下一個，雙擊父節(jié)點自動添加該節(jié)點下的所有視頻。可選主碼流、子碼流。

11. 錄像機管理、攝像機管理，可添加刪除修改導入導出打印信息，立即應用新的設備信息生成樹狀列表，不需重啟。

12. 可選多種內(nèi)核自由切換，ffmpeg、vlc、mpv等，均可在pro中設置。推薦用ffmpeg，跨平臺最多，默認提供好了linux和mac平臺上編譯好的庫。

13. 支持硬解碼，可設置硬解碼類型（qsv、dxva2、d3d11va等）。

14. 默認采用opengl繪制視頻，超低的CPU資源占用，支持yuyv和nv12兩種格式繪制，很牛逼。

15. 高度可定制化，用戶可以很方便的在此基礎上衍生自己的功能，比如增加自定義模塊，增加運行模式、機器人監(jiān)控、無人機監(jiān)控、挖掘機監(jiān)控等。

16. 支持xp、win7、win10、linux、mac、各種國產(chǎn)系統(tǒng)（UOS、中標麒麟、銀河麒麟等）、嵌入式linux等系統(tǒng)。

17. 注釋完整，項目結(jié)構(gòu)清晰，超級詳細完整的使用開發(fā)手冊，精確到每個代碼文件的功能說明，不斷持續(xù)迭代版本。

## 三、體驗地址

1. 體驗地址：[https://pan.baidu.com/s/1d7TH_GEYl5nOecuNlWJJ7g](https://pan.baidu.com/s/1d7TH_GEYl5nOecuNlWJJ7g) 提取碼：01jf 文件名：bin_video_system.zip。

2. 國內(nèi)站點：[https://gitee.com/feiyangqingyun](https://gitee.com/feiyangqingyun)

3. 國際站點：[https://github.com/feiyangqingyun](https://github.com/feiyangqingyun)

4. 個人主頁：[https://blog.csdn.net/feiyangqingyun](https://blog.csdn.net/feiyangqingyun)

5. 知乎主頁：[https://www.zhihu.com/people/feiyangqingyun/](https://www.zhihu.com/people/feiyangqingyun/)

6. 在線文檔：[https://feiyangqingyun.gitee.io/qwidgetdemo/video_system.html](https://feiyangqingyun.gitee.io/qwidgetdemo/video_system.html)

## 四、效果圖

## 五、核心代碼

avascript 是一種同步編程語言。但它也是 Web 語言，需要異步獲取數(shù)據(jù)，我們也需要用戶交互性，即事件驅(qū)動并僅基于用戶行為執(zhí)行的功能。

回調(diào)和承諾

我們通過創(chuàng)建在程序初始化時不會立即執(zhí)行的代碼片段來實現(xiàn)這一點。這些代碼片段也稱為回調(diào)和承諾。最初，最基本的方法是使用純回調(diào)，但函數(shù)定義的本質(zhì)導致了所謂的嵌套回調(diào)的“回調(diào)地獄”。因此，一個更精致的工具出現(xiàn)了——承諾。如今，我們還使用 async/await 作為“.then()”解決 Promise 的流行替代方案。然而，本文的目的不是教授處理異步請求的基礎知識。它試圖深入研究 Javascript 的本質(zhì)，并解釋回調(diào)和 Promise 等異步工具為何成為其中的一部分。

那么單線程編程語言為何擁有可供使用的異步工具呢？

JavaScript 運行時

簡單的答案是——Javascript 運行時。如今，Javascript 不僅僅是一種具有切換靜態(tài)網(wǎng)頁上按鈕的簡單目的的腳本語言，它還是一種功能齊全的編程語言。因此，為了理解單線程語言如何實現(xiàn)并發(fā)

我們看到一個 JS 引擎和一些附加功能 - Web API、事件循環(huán)和隊列。當我們說單線程時，我們指的是JS引擎。簡單地說，這與您編寫的代碼及其執(zhí)行上下文有關，而附加功能會“創(chuàng)建”附加線程。因此，運行時由兩部分組成 - 您的代碼和一些其他外部代碼，兩者都生成整個應用程序。所以，現(xiàn)代Javascript總是需要一個運行時環(huán)境來執(zhí)行，而最流行的就是瀏覽器。另一種流行的方法是 Node.js。

但是現(xiàn)在，讓我們應用我們已經(jīng)學到的有關運行時環(huán)境的知識來看看回調(diào)函數(shù)的機制。

回調(diào)

function fetchData(callback) {
  setTimeout(function () {
    const data='Async data';
    callback(data); // Execute the callback function with the data
  }, 1000);
}

function processData(data) {
  console.log('Received data: ', data);
}

fetchData(processData); // Pass the processData function as a callback
console.log('Fetching data...');

執(zhí)行線：

console.log('Fetching data...'); //該行被執(zhí)行
console.log('Received data: Async data'); // 該行是第二個執(zhí)行的。

一步一步的解釋：

首先觸發(fā) fetchData(processData)

setTimeout 的調(diào)用延遲了 1000 毫秒。

在等待超時的同時，程序繼續(xù)執(zhí)行 console.log('Fetching data...');

1000 毫秒（1 秒）后，回調(diào)函數(shù) processData 將使用數(shù)據(jù)“Async data”執(zhí)行。

在 processData 內(nèi)部，語句 console.log('Received data:', data); 最終被執(zhí)行。

所以，打印語句的最終順序是：

“正在獲取數(shù)據(jù)……”

“接收到的數(shù)據(jù)：異步數(shù)據(jù)”

因此，“Fetching data...”console.log 在 fetchData 函數(shù)之前執(zhí)行。

這怎么可能？

單線程的 Javascript 如何“知道”繼續(xù)解釋代碼并執(zhí)行后續(xù)的 console.log("Fetching data...")，即使它還有另一個任務似乎處于待命狀態(tài)（fetchData 函數(shù)）。

正如我所說，當我們說單線程時，我們指的是JS引擎的執(zhí)行機制。 Javascript引擎負責執(zhí)行上下文，即管理內(nèi)存堆和調(diào)用堆棧。內(nèi)存堆存儲 JS 代碼中定義的所有變量，而調(diào)用堆棧執(zhí)行操作（函數(shù)執(zhí)行）。

那么，回到當前的問題，單線程意味著只有一個調(diào)用堆棧。反過來，一個調(diào)用堆棧意味著一次只能執(zhí)行一段代碼。

在我們的例子中，使用 console.log('Fetching data...') 和 fetchData 函數(shù)，考慮到 Javascript 的非阻塞性質(zhì)，Javascript 不會等待回調(diào)的響應，而是繼續(xù)解釋后續(xù)的代碼塊。

為什么不等呢？

答案 - 回調(diào) fetchData 函數(shù)是從當前主線程的調(diào)用堆棧中“提取”的，邏輯上執(zhí)行會繼續(xù) console.log('Fetching data...')。

但是這個回調(diào)被“提取”到哪里呢？

不僅針對回調(diào)的一般答案是，任何此類異步函數(shù)都利用 Web API，通過依賴事件循環(huán)來管理其隊列優(yōu)先級（何時重新進入主線程調(diào)用堆棧）。

對于回調(diào)，Timer Web API 執(zhí)行 setTimeout，事件循環(huán)將該函數(shù)的結(jié)果放入任務隊列中。這也是為什么 setTimeout 中設置的延遲被稱為最小延遲時間。目前尚不清楚調(diào)用堆棧何時會被釋放，以便可以執(zhí)行新的事件循環(huán)并將隊列中的任務添加到其中。

現(xiàn)在讓我們看看如何在 Javascript 運行時中解析 Promise。

const promise=new Promise(resolve=>{
  resolve("Promise")
}, reject=> {

})

promise.then(res=>console.log(res))

對于 Promise，Promise 被設置到微任務隊列中，事件循環(huán)的優(yōu)先級高于常規(guī)任務（例如 setTimeout 回調(diào)）。這意味著當/如果承諾被履行時，其結(jié)果將被添加到微任務隊列中，確保它將在事件循環(huán)中的下一個（常規(guī)）任務之前執(zhí)行。

控制反轉(zhuǎn)

因此，簡單來說，Javascript 運行時為單線程編程語言添加了線程和并發(fā)性。

這也稱為控制反轉(zhuǎn)，這是編程中非常流行的術語。代碼結(jié)果取決于外部因素，即每個 Javascript 運行時附帶的附加功能。如上所述，執(zhí)行控制被反轉(zhuǎn)并移交給外部實體。

段時間沒寫文章了，條友們，這次我們從一個題目開始吧。

首先我給大家出一道題目，大家可以先思考一下，再往下看。

題目是：請用JavaScript重寫confirm方法，實現(xiàn)和confirm同樣的功能。

乍一看可能感覺很簡單，定義一個confirm方法覆蓋window對象原生的 confirm方法，在方法里用div畫一個彈框，參數(shù)中傳入兩個回調(diào)方法，當用戶點擊“確定”或者“取消”的時候分別調(diào)用相應的回調(diào)方法，如下：

confirm("確定嗎？",callBack1,callBack2);

但是這樣和原來的confirm()方法是不一樣的，原來的confirm()方法只有一個參數(shù)，只傳入要顯示的消息，并且用戶點擊按鈕之前線程是暫停的，只有當用戶點擊確定或者取消后，接下來的代碼才會繼續(xù)執(zhí)行，并不需要回調(diào)方法，這樣業(yè)務邏輯更清晰有條理。

谷歌瀏覽器的confirm彈窗

ie瀏覽器的confirm彈窗

如上面兩圖，原生的confirm方法在各個瀏覽器樣式不同，但功能相同，即都能夠暫停程序執(zhí)行，直到用戶點擊了按鈕。

那么我們能否用純JavaScript做出一個樣式不同但功能相同的confirm方法來覆蓋原生的confirm方法呢，答案是可以的，思路就是暫停程序的執(zhí)行，是暫停而不是堵塞JavaScript線程，因為一旦JavaScript線程被阻塞，dom渲染的線程也會被掛起，從而導致用戶無法點擊彈框出現(xiàn)的按鈕，所以像while(true){...}這種寫法是不可取的，JavaScript不像c或c++那樣，JavaScript出現(xiàn)這種死循環(huán)很快會堆棧溢出，程序就擋掉了。那么如何實現(xiàn)代碼的暫停呢，es7中新出了await關鍵字，await簡單來講就是讓程序同步而不是以異步的方式執(zhí)行，字面意思就是等待，等著程序執(zhí)行完再進行下一步，await只能用在異步的方法里面，既帶有async標記的function。我今天跟大家分享的實現(xiàn)程序暫停的方法就是通過await實現(xiàn)的。

首先，我們可以構(gòu)造一個等待函數(shù)， waitUserClick()

waitUserClick()相當于一個sleep方法，執(zhí)行這個函數(shù)結(jié)束需要等待100毫秒，這個等待多長時間我們可以隨意調(diào)節(jié)，這個函數(shù)的作用就是讓你等待100毫秒，其他的什么都不干，那么有個這個等待函數(shù)了，我們可以接下來實現(xiàn)一個while循環(huán)來監(jiān)聽用戶有沒有點擊按鈕。

這個while每個循環(huán)調(diào)用了我們上面定義的等待函數(shù)，間隔100毫秒，這樣就不會造成瀏覽器假死，dom渲染不受影響，接下來用戶點擊確定或者取消按鈕的時候，我們就可以把WAIT_USER_CLICK這個狀態(tài)改為false從而跳出循環(huán)繼續(xù)執(zhí)行下面的代碼邏輯，也就是說這個while循環(huán)是讓代碼暫停的關鍵，而WAIT_USER_CLICK被用戶點擊按鈕后調(diào)整為false就會跳出循環(huán)，這就實現(xiàn)了代碼的繼續(xù)執(zhí)行，這就是實現(xiàn)程序暫停和啟動的關鍵，剩下的就是用dom畫個confirm彈窗了，這很簡單了，代碼如下。

上面就是整個confirm方法，我們可以看到這個SYS_USER_FEED_BACK;就是對用戶進行了什么操作的反饋，如點擊了確定還是取消，confirm方法最終把用戶的操作變成bool的返回值。

下面我們試驗一下剛實現(xiàn)的這個confirm方法。

注意，我們實現(xiàn)的這個confirm方法只能用于異步的方法中，使用時只需要把所在的方法前面標注上async，confirm因為也是同步模式因此前面也要加上await關鍵字。

運行效果如下：

可以看到現(xiàn)在用戶還沒點擊“確定”或“取消”按鈕，所以當前程序只執(zhí)行了console.log(1)就暫停了。

然后當我點擊了確定，可以看到console.log(2)也執(zhí)行了，說明程序邏輯從暫停狀態(tài)轉(zhuǎn)換為了繼續(xù)運行狀態(tài)，我們重寫的這個confirm方法成功了。

有了confirm，alert和prompt就好做了，原理都一樣，prompt無非就是加了個讓用戶輸入字符串的輸入框，下面我把完整的代碼分享給大家，實現(xiàn)了alert，confirm和prompt.。

好了，到這功能的實現(xiàn)都講清楚了，代碼呢也都一字不落的貼出來了，那么大家可能要問了，這有什么用嗎？哈哈，業(yè)務場景，一個到處都是原生confirm的老項目，老板突然覺得原生confirm難看，在各個瀏覽器樣式不統(tǒng)一，讓你改了，你可以選擇UI框架，但基本上要把原來的邏輯改成各種回調(diào)函數(shù)，想想就頭大吧，當然也可以像這種，重寫confirm方法，然后查找替換，把所有confirm前面加上await，所在方法前面加上async。還有就是不想寫回調(diào)函數(shù)的又不想用系統(tǒng)自帶的confirm的，可以試試。

今天就先分享到這里，雖然現(xiàn)在不從事碼農(nóng)工作了，但是業(yè)余時間還是會繼續(xù)研究，跟大家分享編程經(jīng)驗與心得，本文有什么不對的地方還請大佬們批評指導。

#編程#?

在線咨詢

上一篇：Web 服務原理
下一篇：calendar - 日歷相關│Python標準庫

您的項目需求

*請認真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。