一種應用於多系統的設備請求處理方法及裝置與流程

2023-12-12 13:41:42 2

本發明屬於通信設備技術領域，涉及一種設備虛擬化技術，尤其涉及一種應用於多系統的設備請求處理方法及裝置。

背景技術：

Linux系統是一種開源電腦作業系統內核，「內核」指的是一個提供硬體抽象層、磁碟及文件系統控制、多任務等功能的系統軟體。而不同的硬體設備有各自不同的控制方法和操作邏輯，如果內核針對每一套硬體都做一份特別的適配則會對內核開發難度和上層應用程式使用硬體帶來極大的困難；為了適配於大量的不同的硬體平臺，因此Linux內核對每一個子系統都定義了一套標準的操作框架，不同硬體平臺廠商按照該框架來完成自己的設備驅動設計，並將驅動交給該框架統一管理。

為了使上層應用進程在不同硬體平臺使用同類型設備時可以有統一的調用方法，在某些操作框架中，Linux自身實現了一個規範化的驅動，用於管理內核中的某一類設備；該驅動向用戶層提供標準的調用接口，同時隱藏底層該設備驅動的實現細節；底層具體硬體的設備驅動通過該驅動提供的函數向其註冊，並讓其負責控制自身的函數調用，用戶進程只需要通過規範的接口標準調用該規範化的設備驅動就能夠完成對硬體的控制，例如Linux內核中的顯示處理框架和音頻處理框架就採用了這種方式。

音頻處理架構為基於ALSA(Advanced Linux Sound Architecture，高級Linux聲音架構的簡稱)，該架構主要分為兩個部分:用戶空間部分和驅動部分。用戶空間部分主要是由Google定製化裁減了ALSA LIB形成了自己獨有的tinyalsa，向用戶空間提供接口，Tinyalsa可以分為三部分，即播放實例、錄音實例和控制項設置實例，Android HAL層通過調用上述實例完成播放、錄音和調控設備等操作。Tinyalsa的每一個實例都有一個完整的流程，例如播放實例的流程包括打開設備、獲取設備參數、設置參數、播放聲音等，這個完成的流程是通過架構的驅動部分來完成的。ALSA driver處於內核，是一個完整的設備驅向用戶空間提供(open、close、read、write、ioctl)來實現使用音頻設備。

在多Android系統同時運行但只有一個音頻設備的情況下，現有技術方案是將虛擬化實現在Framework層中，具體步驟為：APP請求使用音頻服務，binder驅動截獲服務請求，binder驅動作為服務端對請求進行過濾，若通過過濾規則則為其請求Audio Finger服務，否則不予響應或者返回虛假響應。

然而，隨著Android的音頻處理日趨多樣化，現有的技術方案已不適用。首先，Android在播放聲音的時候不僅會涉及到Audio Flinger還會涉及到Audio Manager,Audio Policy等服務，各個服務之間還會交互，對於binder驅動來說過濾機制相當複雜，稍有不當的過濾策略就會影響APP使用音頻服務；其次，當前後臺Android系統發生切換的時候，無法保存前臺設備的狀態和播放進度等，當Android系統再次切換到前臺時，該系統對應的設備狀態是未知的，不可預測的。

技術實現要素：

本發明的目的旨在針對上述現有技術中存在的問題，提供一種應用於多系統的設備請求處理方法及裝置，實現前後臺系統能夠正常使用設備，確保後臺系統無法操控設備，並在後臺系統切換到前臺時，實現任務的喚醒，恢復現場。

為了達到以上目的，本發明採用以下技術方案來實現。

本發明提供了一種應用於多系統的設備請求處理方法，其特徵在於，步驟如下：

S1，經Linux用戶空間接收來自當前系統的設備操作請求；

S2，根據操作請求，打開對應設備；

S3，判斷當前系統處於前臺還是後臺，若當前系統處於前臺，依據操作請求，控制設備執行操作；若當前系統處於後臺，將操作請求對應的任務掛起。

上述應用於多系統的設備請求處理方法，根據操作請求，打開對應設備包括以下分步驟：

S21，根據操作請求獲取當前任務結構體；

S22，根據當前任務結構體判斷當前系統處於前臺還是後臺；

S23，若操作請求來自前臺，搜索當前系統與對應設備的映射關係，若搜索不到則創建並記錄當前系統與對應設備的映射關係，然後記錄設備參數信息，打開對應設備，同時將設備打開成功的消息反饋給當前系統；

S24，若操作請求來自後臺，搜索當前系統與對應設備的映射關係，若搜索不到則創建並記錄當前系統與對應設備的映射關係，然後記錄設備參數信息，再將打開對應設備的任務掛起。

上述應用於多系統的設備請求處理方法，步驟S3或步驟S24中，掛起具體實現方式為將任務對應的進程修改為休眠狀態，並利用Linux內核調度函數將其掛起。

上述應用於多系統的設備請求處理方法，步驟S3中，通過當前任務結構體或者記錄的與當前系統對應的映射關係判斷當前系統處於前臺還是後臺。

上述應用於多系統的設備請求處理方法，進一步包括步驟S4，根據停止操作的請求關閉對應設備或者執行操作結束後關閉對應設備，該步驟包括以下分步驟：

S41，通過當前任務結構體或者記錄的與當前系統對應的映射關係判斷當前系統處於前臺還是後臺；

S42，若當前系統處於前臺，則釋放對應設備、清空設備狀態，然後清空記錄的對應設備參數信息；

S43，若當前系統處於後臺，則清空記錄的對應設備參數信息即可。

上述應用於多系統的設備請求處理方法，其特徵在於，當處於後臺的當前系統切換到前臺時，包括以下步驟：

K1，將來自前臺系統的操作請求掛起，釋放對應設備，完成前臺系統到後臺系統的切換；

K2，根據記錄的與當前系統對應的設備參數信息，重新打開設備，設置設備參數信息，然後喚醒記錄的與當前系統對應的操作請求，加入任務序列，控制設備執行操作。

本發明進一步提供了一種應用於多系統的設備請求處理裝置，其特徵在於，包括：

接收子裝置，用於經Linux用戶空間接收來自當前系統的設備操作請求；

打開子裝置，用於根據操作請求，打開對應設備，記錄設備參數信息；

操作子裝置，判斷當前系統處於前臺還是後臺，若當前系統處於前臺，依據操作請求，控制設備執行操作；若當前系統處於後臺，將操作請求對應的任務掛起。

打開子裝置進一步包括以下單元：

獲取單元，用於根據操作請求獲取當前任務結構體；

第一判斷單元，用於根據當前任務結構體判斷當前系統處於前臺還是後臺；

第一處理單元，若操作請求來自前臺，搜索當前系統與對應設備的映射關係，若搜索不到則創建並記錄當前系統與對應設備的映射關係，然後記錄設備參數信息，打開對應設備，同時將設備打開成功的消息反饋給當前系統；

第二處理單元，若操作請求來自後臺，搜索當前系統與對應設備的映射關係，若搜索不到則創建並記錄當前系統與對應設備的映射關係，然後記錄設備參數信息，再將打開對應設備的任務掛起。

上述述應用於多系統的設備請求處理裝置，進一步包括關閉子裝置，用於根據停止操作的請求或者執行操作結束後關閉對應設備的，該子裝置包括以下單元：

第二判斷單元，用於通過當前任務結構體或者記錄的與當前系統對應的映射關係判斷當前系統處於前臺還是後臺；

第一後處理單元，用於當前系統處於前臺時釋放對應設備、清空設備狀態，然後清空記錄的對應設備參數信息；

第二後處理單元，用於若當前系統處於後臺時清空記錄的對應設備參數信息即可。

上述述應用於多系統的設備請求處理裝置，當處於後臺的當前系統切換到前臺時，進一步包括：

第一切換子裝置，用於將來自前臺系統的操作請求掛起，釋放對應設備，完成前臺系統到後臺系統的切換；

第二切換子裝置，用於根據記錄的與當前系統對應的設備參數信息，重新打開設備，設置設備參數信息，然後喚醒記錄的與當前系統對應的操作請求，加入任務序列，控制設備執行操作。

本發明提供的應用於多系統的設備復用方法及裝置，具有以下至少一項有益效果：

1、由於本發明實現於Linux內核，將處於後臺的系統對應的任務保存並掛起，確保後臺系統無法操控設備，同時保證後臺切換到前臺時，能夠正常使用設備；

2、由於本發明虛擬化技術實現於Linux內核，前後臺系統切換效率更高，且面向設備，架構更加簡潔；

3、由於本發明請求處理方法不僅實現了設備復用，而且完美實現了設備操作的流暢性和無間斷性，避免了因前後臺系統切換可能引起的任務出錯等問題；

4、由於本發明採用的音頻請求處理方法實現於Linux內核的ALSA驅動，具有跨平臺強、跨版本性強等特點，便於移植。

附圖說明

為了更清楚地說明本發明實施例或現有技術中的技術方案，以下將對實施例或現有技術描述中所需要使用的附圖作簡單的介紹，顯而易見地，以下描述中的附圖僅僅是本發明的一些實施例，對於本領域普通技術人員而言，在不付出創造性勞動的前提下，還可以根據這些附圖所示實施例得到其它的實施例及其附圖。

圖1為本發明實施例的應用於多系統的設備請求處理方法流程圖。

圖2為本發明實施例的打開數據處理設備流程圖。

圖3為本發明實施例的關閉對應設備流程圖。

圖4為本發明實施例的前臺系統與後臺系統切換時序圖。

具體實施方式

以下將結合附圖對本發明各實施例的技術方案進行清楚、完整的描述，顯然，所描述實施例僅僅是本發明的一部分實施例，而不是全部的實施例。基於本發明中的實施例，本領域普通技術人員在沒有做出創造性勞動的前提下所得到的所有其它實施例，都屬於本發明所保護的範圍。

本實施例應用於多系統的設備復用方法實現於Linux內核，不再面向系統(如手機軟體APP)實現虛擬化，而是在Linux內核面向設備實現虛擬化。本實施例以面向音頻設備實現虛擬化為例，對應用於多系統的設備請求處理方法進行詳細解釋，但該解釋並不構成對本發明的任何限定。

前面已經介紹過，音頻設備位於音頻ALSA驅動層中。Android系統音頻驅動模塊簡記為ALSA driver，負責處理Android系統傳遞到內核的音頻處理請求，通過讀取上層傳遞的參數和數據設置控制項狀態、播放或錄音等。ALSA driver模塊包括Control設備和Pcm設備，其中Control設備是音頻控制設備(用於管理控制項，即控制項管理設備)；Pcm設備用於播放或錄音(用於對上層傳遞的數據進行解析轉換，即數據處理設備)，其下可以至少有一個substream子設備負責具體的播放或錄音任務(本實施例中假設一個Pcm設備下有一個substream子設備)。下面以針對Control設備和Pcm設備的操作請求為例，對本發明提供的實現與Linux內核、應用於多系統的設備請求處理方法進行詳細解釋。

圖1示出了本實施例提供的應用於多系統的設備請求處理方法流程圖，步驟如下：

S1，經Linux用戶空間接收來自當前系統的設備操作請求。

用戶通過上層系統(例如Android系統)發起設備操作請求，並經Linux用戶空間傳送至Linux內核。

在處理應用於多系統的音頻操作請求時，首先經Linux用戶控制項接收來自當前系統的音頻操作請求，以播放聲音為例，用戶通過上層Android系統發起播放請求，播放請求經Linux用戶空間傳送至Linux內核。

S2，根據操作請求，打開對應設備。

當Linux內核接收到設備操作請求以後，首先要打開對應設備，才能對設備進行操作。對於音頻操作請求，即打開控制項管理設備或/和數據處理設備。這是因為在ALSA驅動中，Pcm設備用於播放、Control設備用於設置控制項狀態，因此需要打開的至少其中一個設備。以播放聲音為例，首先要打開播放設備，才能將播放聲音的數據傳遞給播放設備，由播放設備播放聲音。

上述Control設備用於管理音頻控制項，當Android系統要打開一個Pcm設備或者增減聲音之類的操作之時，首先需要保證該設備處於打開狀態，然後由Control設備管理各個音頻控制項的狀態(如MIX控制項，MUX控制項，輸入、輸出線路等)，確保控制項已達到所需要求的狀態，Control設備只有在內核啟動時，才涉及打開操作，內核啟動後Android系統啟動，打開control設備；Linux內核初始化所有控制項，為每個Android系統建立一張用於記錄所有控制項狀態的控制項表，並對每個控制項最後一次設置的參數進行記錄(該記錄由Linux內核在Android系統關閉設備或者系統切換時進行保存，以為現場恢復提供設備參數)。

根據音頻操作請求，Pcm設備的打開流程如圖2所示，包括以下分步驟：

S21，根據操作請求獲取當前任務結構體。

根據音頻操作請求進程，可以獲取當前進程的當前任務結構體，當前任務結構體包含指向與當前系統對應容器的標識位。

例如，以打開Pcm設備的操作請求為例，其包括

struct task_struct*task＝current；//獲取任務結構體

struct nsproxy*nsproxy＝task->nsproxy；//獲取當前任務對應namespace

if(nsproxy＝＝active_nsproxy){}//判斷容器是否處於前臺

內核在執行打開過程時可以根據current宏(內核提供支持)，獲取到對應當前請求的任務結構體指針(task_struct)，通過該指針能訪問結構體中的namespace指針，這裡的namespace指針即為當前系統對應容器的標識位。

S22，根據當前任務結構體判斷當前系統處於前臺還是後臺。

通過當前結構體中包含的指向與當前系統對應容器的標識位可以確定當前系統處於前臺還是後臺。

例如，將獲取的當前結構體中的namespace指針與前臺系統對應的namespace指針進行比較則可判斷當前系統處於前臺還是後臺。

S23，若操作請求來自前臺，搜索當前系統與對應設備的映射關係，若搜索不到則創建並記錄當前系統與對應設備的映射關係，然後記錄設備參數信息，打開對應設備，同時將設備打開成功的消息反饋給當前系統。

S24，若操作請求來自後臺，搜索當前系統與對應設備的映射關係，若搜索不到則創建並記錄當前系統與對應設備的映射關係，然後記錄設備參數信息，再將打開對應設備的任務掛起。

步驟S23和S24的目的是根據當前系統處於前臺還是後臺來決定是否真實打開對應設備。

以播放聲音為例，當Android系統需要播放聲音時，需要打開設備和設置相關參數，不管Android系統來自前臺還是後臺，都需要先找到當前Android系統與對應設備(這裡是Pcm設備)的映射關係，然後將設備參數信息保存到相應的位置。可以通過多種記錄方式(例如鍊表、HASH表)來保存映射關係。上述映射關係包括設備參數信息、當前進程對應的任務結構體((task_struct)：current)對應的指針、設備文件(struct file*file)結構體指針等；所述設備參數主要包括硬體參數(hw_params)、軟體參數(sw_params)以及對應的命名空間(namespace)指針。若找不到當前Android系統與Pcm設備的映射關係，則需要創建兩者的映射關係，並保存到鍊表等記錄方式中，然後也將設備參數信息保存到鍊表中。

若當前Android系統處於前臺，按照常規操作，記錄完設備參數信息後，打開Pcm設備，完成打開流程，同時將Pcm設備打開成功的消息反饋給當前Android系統，這樣當前Android系統才會繼續傳遞播放聲音的數據。在打開完成之後，傳遞聲音數據之前，進一步將Android系統設置的設備相關參數作為設備參數信息保存到鍊表中，同時將當前設備狀態保存到相應的設備狀態結構體；當多個系統進行切換時，可以通過重設這些參數的方式來恢復設備，從而恢復設備的狀態。

若當前Android系統處於後臺，為了不影響前臺Android系統使用Pcm設備，對於當前Android系統，記錄完設備參數信息後，將打開Pcm設備的任務掛起，這樣打開Pcm設備的任務被阻塞，直到被喚醒才能繼續播放流程。

這裡的掛起操作，可以採用本領域披露的操作方法，本實施例採用的實現方式是將打開Pcm設備任務對應的進程修改為休眠狀態，並利用Linux內核調度函數將其掛起。

S3，判斷當前系統處於前臺還是後臺，若當前系統處於前臺，依據操作請求，控制設備執行操作；若當前系統處於後臺，記錄操作請求或/和將操作請求對應的任務掛起。

本步驟的目的是根據當前系統處於前臺還是後臺來決定是否要依據操作請求，對設備進行操作。由於在步驟S2中可能已經對前後臺進行過判斷，因此，本步驟中對於前後臺的判斷不一定是必須的。當步驟S2中未對前後臺系統進行過判斷時，則需要對前後臺系統進行判斷。

以播放聲音為例，就是根據當前系統處於前臺還是後臺決定是否需要播放聲音；前面已經指出，首先需要將各控制項設置為所需狀態，才能進行相應的操作，因此，Control設備和Pcm設備均會接收到播放聲音的操作請求(ioctl)，下面對Control設備和Pcm設備對於該操作請求的處理過程進行詳細說明。

(1)對於ioctl操作請求，對Control設備的虛擬化處理過程包括以下分步驟:

L31，根據音頻操作請求，獲取當前任務結構體。

前面已經對當前任務結構體進行了解釋，這裡不再贅述。

L32，根據獲取當前任務結構體判斷當前系統處於前臺還是後臺。

在這裡，通過當前任務結構體包含的指向與當前系統對應容器的標識位，便可以確定當前系統處於前臺還是後臺。

L33，若當前系統處於前臺，依據操作請求，控制設備執行操作；在這裡具體為根據音頻操作請求控制控制項管理設備設置控制項狀態，並更新控制項狀態至控制表。

若當前系統處於前臺，根據播放聲音的操作請求，控制control設備設置輸入線路、MIX控制項和MUX控制項等，並將更新後的控制項狀態保存到控制項表。

L34，若當前系統處於後臺，僅對記錄操作請求進行記錄；在這裡具體為根據音頻操作請求更新控制項狀態至控制表，但不控制控制項管理設備設置控制項。

若當前Android系統處於後臺，為了不影響前臺使用控制項，Control設備不能真實設置控制項狀態，而為了保持與上層Android系統保存的控制項狀態一致，仍然需要更新對應Android系統的控制項表中對應控制項狀態。例如，若當前Android系統處於後臺，根據播放聲音的操作請求，更新對應控制表中輸入線路、MIX控制項和MUX控制項等控制項狀態，但不真實操作control設備設置控制項(也相當於忽略此任務)。

當控制項使用完畢後，再由control設備根據ioctl操作請求關閉相應控制項，這也主要是為了支持DAPM(DAPM是Dynamic Audio Power Management的縮寫，直譯過來就是動態音頻電源管理的意思，DAPM是為了使基於linux的行動裝置上的音頻子系統，在任何時候都工作在最小功耗狀態下)機制，以減少功耗。

(2)對於ioctl操作請求，對Pcm設備的虛擬化處理過程包括以下分步驟:

L31』，根據音頻操作請求，獲取當前任務結構體。

前面已經對當前任務結構體進行了解釋，這裡不再贅述。

L32』，根據獲取當前任務結構體判斷當前系統處於前臺還是後臺。

在這裡，通過當前任務結構體包含的與當前系統對應容器的標識位，便可以確定當前系統處於前臺還是後臺。除此之外，也可以先遍歷鍊表找出當前系統與對應設備的映射關係，然後根據映射關係找到設備對應的系統，判斷當前系統處於前臺系統還是後臺系統。

以播放聲音為例，本步驟對應的即是通過ioctl流程來完成任務調度。當通過ioctl寫入數據時，用戶會傳入對應要操作的設備文件指針(struct file*file)，根據該項，遍歷打開設備過程中建立的設備鍊表找到對應的表項，讀取表項中記錄的namespace指針，將其與前臺系統的namespace指針進行比較則可判斷發起「寫入數據」操作請求的Android系統處於前臺還是後臺。

L33』，若當前系統處於前臺，依據操作請求，控制設備執行操作；在這裡具體為根據音頻操作請求控制數據處理設備上層傳遞的數據進行解析轉換，執行音頻操作。

以播放聲音為例，若處於前臺，進行正常io任務(即按操作請求控制設備執行操作)，寫入播放聲音數據、播放聲音。

L34』，若當前系統處於後臺，記錄操作請求並將操作請求對應的任務掛起；在這裡具體為將此次音頻操作請求記錄保存到鍊表中，並利用Linux內核調度函數將其掛起。

以播放聲音為例，若當前Android系統處於後臺，由於沒有真正打開Pcm設備，就不能進行此次io任務，需要將此次io任務保存到鍊表中，然後將此次io任務掛起，這裡採用的是將io任務進程修改為休眠狀態，再利用Linux內核調度函數將其掛起。

當執行完一次操作，為了不影響其它系統使用操作設備，需要將完成操作的設備釋放。此外，當突然接到上層系統的關閉設備請求時，也需要將設備關閉、釋放。

因此，上述應用於多系統的設備請求處理方法進一步包括步驟S4，根據停止操作的請求關閉對應設備或者執行操作結束後關閉對應設備，其流程圖如圖3所示，包括以下步驟；

S41，通過當前任務結構體或者記錄的與當前系統對應的映射關係判斷當前系統處於前臺還是後臺。

本步驟與步驟S3中相關部分解釋相似，這裡不再贅述。

S42，若當前系統處於前臺，則釋放對應設備、清空設備狀態，然後清空記錄的對應設備參數信息。

S43，若當前系統處於後臺，則清空記錄的對應設備參數信息即可。

步驟S42和步驟S43的目的是根據當前系統處於前臺還是後臺來決定關閉設備的策略。

噹噹前系統處於前臺時，按照常規操作，釋放對應設備、清空設備狀態，然後清空記錄的對應設備參數信息。以通過調度ioctl寫入數據為例，當數據寫完之後，就需要先釋放Pcm設備，再情況Pcm設備狀態，然後清空記錄的Pcm設備參數信息。

噹噹前系統處於後臺時，由於沒有真正佔用過此設備，因此只需要刪除鍊表等記錄的對應的設備參數信息即可。以io任務為寫入數據為例，由於io任務已經被掛起，沒有調度ioctl寫入數據，此時只需要刪除鍊表等記錄記錄的Pcm設備參數信息。

前面已經指出，Control設備是在內核啟動時打開，其也在內核關閉時關閉，其關閉流程採用本領域已經披露的常規手段實現，這裡不再贅述。

以上是對應用於多系統的基本操作請求的處理過程，當前後臺系統進行切換時，特別是當後臺系統切換到前臺時，如何實現現場的恢復，接下來進行詳細說明。

當前臺系統與後臺系統進行切換時，主要涉及前臺系統切換到後臺系統和後臺系統切換到前臺系統，時序圖如圖4所示，主要包括以下步驟：

K1，將來自前臺系統的操作請求掛起，釋放對應設備，完成前臺系統到後臺系統的切換。

對於正在進行IO任務的音頻設備來講(例如Pcm設備)，當進行前後臺切換時，需要先將來自前臺Android系統的操作請求掛起(掛起可以採用前面描述的方法)，只有當全部IO任務都掛起後，才可以釋放前臺所佔用的所有設備(如Control設備和Pcm設備)，否則一旦釋放設備，而還有IO任務進行的話，會使Android系統崩潰。

K2，根據記錄的與當前系統對應的設備參數信息，重新打開設備，設置設備參數信息，然後喚醒記錄的與當前系統對應的操作請求，加入任務序列，控制設備執行操作。

釋放設備以後，原處於後臺的系統先找到與該系統有映射關係的設備參數信息，打開相關設備，並根據記錄的設備參數信息重新對設備進行設置，使設備處於可用狀態，當所有相關設備均恢復以後，調用Linux內核調度函數喚醒之前掛起的任務(例如IO任務)，則可繼續執行之前的流程，從而恢復上下文。當執行完操作後，也可以釋放設備，清楚記錄的設備信息，以減少設備佔用。

由於是按照後臺系統記錄的設備參數信息和IO任務進行恢復，因此當系統再次發生切換時，恢復後的處理過程與當初該系統由前臺變換為後臺時沒有區別，可以實現完美銜接。以播放或錄音為例，也即可以實現切換前的現場恢復，不會導致切換回來之後，原有的播放或錄音任務因出錯終止。

本實施例還提供了一種應用於多系統的設備請求處理裝置，包括：

接收子裝置，用於經Linux用戶空間接收來自當前系統的設備操作請求；

打開子裝置，用於根據操作請求，打開對應設備，記錄設備參數信息；

操作子裝置，判斷當前系統處於前臺還是後臺，若當前系統處於前臺，依據操作請求，控制設備執行操作；若當前系統處於後臺，將操作請求對應的任務掛起。

打開子裝置進一步包括以下單元：

獲取單元，用於根據操作請求獲取當前任務結構體；

第一判斷單元，用於根據當前任務結構體判斷當前系統處於前臺還是後臺；

第一處理單元，若操作請求來自前臺，搜索當前系統與對應設備的映射關係，若搜索不到則創建並記錄當前系統與對應設備的映射關係，然後記錄設備參數信息，打開對應設備，同時將設備打開成功的消息反饋給當前系統；

第二處理單元，若操作請求來自後臺，搜索當前系統與對應設備的映射關係，若搜索不到則創建並記錄當前系統與對應設備的映射關係，然後記錄設備參數信息，再將打開對應設備的任務掛起。

上述述應用於多系統的設備請求處理裝置，進一步包括關閉子裝置，用於根據停止操作的請求或者執行操作結束後關閉對應設備的，該子裝置包括以下單元：

第二判斷單元，用於通過當前任務結構體或者記錄的與當前系統對應的映射關係判斷當前系統處於前臺還是後臺；

第一後處理單元，用於當前系統處於前臺時釋放對應設備、清空設備狀態，然後清空記錄的對應設備參數信息；

第二後處理單元，用於若當前系統處於後臺時清空記錄的對應設備參數信息即可。

上述述應用於多系統的設備請求處理裝置，當處於後臺的當前系統切換到前臺時，進一步包括：

第一切換子裝置，用於將來自前臺系統的操作請求掛起，釋放對應設備，完成前臺系統到後臺系統的切換；

第二切換子裝置，用於根據記錄的與當前系統對應的設備參數信息，重新打開設備，設置設備參數信息，然後喚醒記錄的與當前系統對應的操作請求，加入任務序列，控制設備執行操作。

本領域的普通技術人員將會意識到，這裡所述的實施例是為了幫助讀者理解本發明的原理，應被理解為本發明的保護範圍並不局限於這樣的特別陳述和實施例。本領域的普通技術人員可以根據本發明公開的這些技術啟示做出各種不脫離本發明實質的其它各種具體變形和組合，這些變形和組合仍然在本發明的保護範圍內。