Data acquisition method and device
By using a shared collection instance mechanism, the problem of exclusive hardware resources is solved, enabling multiple WebRTC instances to work in parallel and making efficient use of resources, thus optimizing the user experience.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- ALIPAY (HANGZHOU) INFORMATION TECH CO LTD
- Filing Date
- 2026-02-28
- Publication Date
- 2026-05-19
AI Technical Summary
Under the existing technical architecture, the exclusive use of hardware resources on the same device prevents multiple services from being called simultaneously, resulting in a poor user experience and low resource utilization efficiency.
The shared collection instance mechanism allows multiple WebRTC instances to be bound to a shared collection instance on the same hardware device, enabling unified data distribution and avoiding duplicate collection.
It enables multiple business processes to work in parallel without interruption, improving resource utilization efficiency and optimizing user experience.
Smart Images
Figure CN122069253A_ABST
Abstract
Description
Technical Field
[0001] This specification relates to one or more embodiments in the field of computer technology, and more particularly to a data acquisition method and apparatus. Background Technology
[0002] With the continuous evolution of mobile internet and real-time communication technologies, more and more applications are adopting WebRTC as the underlying communication framework to achieve high-quality, low-latency real-time audio and video functions. At the same time, AI multimodal technologies (such as visual recognition and speech understanding) are also gradually being integrated into the same application, and typically rely on WebRTC to complete low-latency data uploads and real-time feedback.
[0003] However, under the current technical architecture, hardware devices such as cameras and microphones are exclusive resources at the operating system level. Once a service starts a WebRTC instance and begins audio and video capture, the relevant hardware devices are locked, and other services will not be able to access the same devices simultaneously unless the previous service actively releases the resources, i.e., stops capturing or disconnects.
[0004] Therefore, a more efficient data acquisition method is needed. Summary of the Invention
[0005] This specification describes one or more embodiments of a data acquisition method and apparatus that can improve resource utilization efficiency and optimize user experience.
[0006] Firstly, a data acquisition method is provided, applied to a target application, wherein a data acquisition manager is deployed in the target application, and the method is executed through the data acquisition manager, including:
[0007] Receive a second registration request from a second WebRTC instance, the second registration request indicating at least the target data category that the second WebRTC instance needs to collect;
[0008] In response to the existence of a shared collection instance that matches the target data category, and the shared collection instance is already bound to the first WebRTC instance, the second WebRTC instance is added and bound to the shared collection instance;
[0009] The target data collected by the target hardware associated with the shared acquisition instance is distributed to the first WebRTC instance and the second WebRTC instance.
[0010] Secondly, a data acquisition device is provided, installed in a target application, the device comprising:
[0011] A receiving unit is configured to receive a second registration request from a second WebRTC instance, the second registration request indicating at least the target data category that the second WebRTC instance needs to collect;
[0012] An adding unit is used to add and bind the second WebRTC instance to the shared collection instance in response to the existence of a shared collection instance that matches the target data category and the shared collection instance is already bound to the first WebRTC instance;
[0013] The sending unit is used to distribute the target data collected by the target hardware associated with the shared acquisition instance to the first WebRTC instance and the second WebRTC instance.
[0014] Thirdly, a computer storage medium is provided on which a computer program is stored, which, when executed in a computer, causes the computer to perform the method of the first aspect.
[0015] Fourthly, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method of the first aspect.
[0016] The data acquisition method and apparatus provided in one or more embodiments of this specification achieve hardware device reuse and data distribution through a shared acquisition instance mechanism. Specifically, when the first WebRTC instance requests a certain type of data, the acquisition manager creates a corresponding shared acquisition instance and binds it to the hardware device to start acquisition; subsequent WebRTC instances requesting the same type of data can be directly bound to the existing shared acquisition instance. Data acquired by the same hardware device is uniformly distributed to all bound instances through the shared acquisition instance, thereby avoiding duplicate acquisition and improving resource utilization efficiency. At the same time, this sharing mechanism also allows different services to work in parallel without interruption, further optimizing the user experience. Attached Figure Description
[0017] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 This is a schematic diagram illustrating an implementation scenario of one embodiment disclosed in this specification;
[0019] Figure 2 This diagram illustrates an interaction of a data acquisition method according to an embodiment of this specification.
[0020] Figure 3 This document illustrates the interaction diagram of the logout methods for each WebRTC instance in one example.
[0021] Figure 4 A schematic diagram of a data acquisition apparatus according to one embodiment of this specification is shown. Detailed Implementation
[0022] The solution provided in this specification will now be described with reference to the accompanying drawings.
[0023] Currently, the main solutions to the problem of multiple services within the same application simultaneously requesting the collection of audio and video data are as follows:
[0024] First, resource preemption and forced service switching. This involves forcibly terminating the currently running WebRTC instance when a new service requires device access, releasing hardware resources, and then starting a new instance. The disadvantages of this approach are: poor user experience (current service is suddenly interrupted); long connection rebuilding time; prone to signaling storms, increasing server load; and inconsistent with the design principles of modern multitasking operating systems.
[0025] Second, multiple sender reuse within a single WebRTC instance. This involves creating only one WebRTC instance and adding multiple senders (tracks) within that instance to send audio and video data from different services to their respective remote services. The disadvantages of this approach are: rigid architecture (all services must share the same connection channel); weak security isolation; inability to meet the independent control signaling requirements of each service; and poor scalability (difficult to adapt to scenarios involving dynamic start-up and shutdown of services).
[0026] Third, operating system-level virtual devices. Virtual camera devices are created, and the data collected in reality is copied and distributed to multiple virtual output ports for different instances to use. The disadvantages of this approach are: limited support for virtual devices on Android / iOS, often requiring jailbreaking or special permissions; poor compatibility, especially on low-end devices; and high development and maintenance costs, which does not conform to the principles of lightweight design and easy integration.
[0027] To address this, this solution proposes a shared data collection instance mechanism to achieve hardware device reuse and data distribution. Specifically, when the first WebRTC instance requests a certain type of data, the system creates a corresponding shared data collection instance and binds it to the hardware device to initiate data collection. Subsequent WebRTC instances requesting the same type of data can directly bind to the existing shared data collection instance. Data collected by the same hardware device is then uniformly distributed to all bound instances via the shared data collection instance, thereby avoiding duplicate data collection and improving resource utilization efficiency. Simultaneously, this sharing mechanism allows different services to work in parallel without interruption, further optimizing the user experience.
[0028] Figure 1This is a schematic diagram illustrating an implementation scenario of one of the embodiments disclosed in this specification. Figure 1 In this context, the target application and the cloud server can communicate via WebRTC technology. The target application typically contains multiple business modules that require the collection of audio and / or video data. For example, if the target application is a telemedicine app, its services may include video consultations and real-time medical record scanning and recognition; if the target application is an educational app, its services may cover online classes, whiteboard note recognition, and homework photo-based Q&A; if the target application is an intelligent customer service app, its services may involve voice calls and product image recognition-assisted responses; if the target application is an AR navigation / industrial inspection app, its services may include remote expert collaborative calls and physical object recognition guidance.
[0029] exist Figure 1 In the process shown, when a certain service in the target application starts, the service creates a WebRTC instance and uses the instance to collect the required audio and video data.
[0030] To achieve resource sharing among WebRTC instances, this solution integrates a collection manager into the target application. This collection manager is responsible for creating shared collection instances. When multiple services create their own WebRTC instances and request data collection, these instances can all be bound to the same shared collection instance. Subsequently, data collected by the hardware devices associated with the shared collection instance will be uniformly distributed to all bound WebRTC instances, thereby avoiding duplicate collection and significantly improving resource utilization efficiency.
[0031] Figure 2 An interactive diagram illustrating a data acquisition method according to an embodiment of this specification is shown. Figure 2 As shown, the method may include the following steps:
[0032] Step S202: Business 1 in the target application creates a WebRTC instance A.
[0033] Taking the aforementioned telemedicine app as an example, after starting video consultation (i.e., service 1), this service will create a WebRTC instance to collect video data. Similarly, taking an education app as an example, after starting online classes (i.e., service 1), this service will also create a WebRTC instance to collect video data.
[0034] It should be understood that once a WebRTC instance is created, the types of data it needs to collect are typically determined. These data types include audio, images, and video. For example, if a WebRTC instance is created from a video consultation within a telemedicine app, the required data type is video. Conversely, if a WebRTC instance is created from a voice call within a smart customer service app, the required data type is audio.
[0035] In step S204, WebRTC instance A sends a registration request to the data collection manager.
[0036] The registration request should at least indicate the target data category that WebRTC instance A needs to collect. Additionally, it may include the identifier of WebRTC instance A, etc.
[0037] In step S206, the collection manager queries locally whether there is a shared collection instance that matches the target data category, and whether the shared collection instance is already bound to at least one WebRTC instance.
[0038] Here, the shared acquisition instance can be referred to as a processor (an abstract piece of code or process), which encapsulates the acquisition logic of the image acquisition device / audio acquisition device. The image acquisition device can be, for example, a camera, scanner, or thermal imager. The audio acquisition device can be, for example, a microphone, contact sensor, or electromagnetic pickup.
[0039] Specifically, when the target data category is video, a local query can be performed to check if a capture instance X for performing audio data acquisition and a capture instance Y for performing image data acquisition exist. Similarly, when the target data category is audio, a local query can be performed to check if a capture instance X for performing audio data acquisition exists. Likewise, when the target data category is image, a local query can be performed to check if a capture instance Y for performing image data acquisition exists.
[0040] In step S208, in response to the absence of a shared collection instance matching the target data category, the collection manager creates the shared collection instance and binds the WebRTC instance A to the shared collection instance.
[0041] Taking video as an example, we can create the above-mentioned capture instance X and capture instance Y, and bind WebRTC instance A to capture instance X and capture instance Y respectively. Taking audio as an example, we can create the above-mentioned capture instance X and bind WebRTC instance A to capture instance X. Taking images as an example, we can create the above-mentioned capture instance Y and bind WebRTC instance A to capture instance Y.
[0042] Step S210: The acquisition manager initiates the acquisition of target data from the target hardware associated with the shared acquisition instance.
[0043] For example, in the above acquisition instance X, the audio acquisition device is activated to acquire audio data; and in the above acquisition instance Y, the image acquisition device is activated to acquire image data. Furthermore, the audio or image acquisition device can return a readiness notification to the acquisition manager.
[0044] Additionally, the collection manager can add WebRTC instance A and its startup status to the target list for querying when returning collected data. This target list records each WebRTC instance bound to the shared collection instance and its running status. The running status can include, but is not limited to, startup and shutdown states.
[0045] This completes the registration of WebRTC instance A.
[0046] In step S212, Service 1 sends a start collection request to WebRTC instance A, and WebRTC instance A forwards the start collection request to the collection manager.
[0047] Step S214: The acquisition manager acquires the target data acquired by the target hardware associated with the shared acquisition instance.
[0048] Specifically, if the target data category is video, acquire the audio data acquired by the audio acquisition device associated with acquisition instance X, and acquire the image data acquired by the image acquisition device associated with acquisition instance Y. If the target data category is audio, acquire the audio data acquired by the audio acquisition device associated with acquisition instance X. If the target data category is image, acquire the image data acquired by the image acquisition device associated with acquisition instance Y.
[0049] Step S216: The acquisition manager sends the target data to WebRTC instance A.
[0050] Specifically, the collection manager can query the target list and, when it determines that WebRTC instance A is in the running state, send the target data to WebRTC instance A.
[0051] It should be understood that when the target data category is video, the target data here includes both audio and image data. When the target data category is audio, the target data here includes only audio data. When the target data category is image, the target data here includes only image data.
[0052] Step S218: Business 2 in the target application creates a WebRTC instance B.
[0053] Taking the aforementioned telemedicine app as an example, service 2 could be real-time medical record scanning and recognition. Taking an education app as another example, service 2 could be providing Q&A via photo-based homework assignments.
[0054] In step S220, WebRTC instance B sends a registration request to the data collection manager.
[0055] The registration request should at least indicate the target data category that WebRTC instance B needs to collect. Additionally, it may include the identifier of WebRTC instance B, etc.
[0056] In step S222, the collection manager queries locally whether there is a shared collection instance that matches the target data category, and whether the shared collection instance is already bound to at least one WebRTC instance.
[0057] Specifically, if the target data category is video, a local query can be performed to check if the aforementioned acquisition instance X and acquisition instance Y exist. If the target data category is audio, a local query can be performed to check if acquisition instance X exists. If the target data category is image, a local query can be performed to check if acquisition instance Y exists.
[0058] Step S224: In response to the existence of a shared collection instance that matches the target data category and that the shared collection instance is already bound to WebRTC instance A, add WebRTC instance B to the shared collection instance.
[0059] Taking video as an example, WebRTC instance B can be added and bound to both capture instance X and capture instance Y. Similarly, taking audio as an example, WebRTC instance B can be added and bound to capture instance X. And taking images as an example, WebRTC instance B can be added and bound to capture instance Y.
[0060] Additionally, the collection manager can also add the WebRTC instance B and its startup status to the target list for the collection manager to query when returning collected data.
[0061] This completes the registration of WebRTC instance B.
[0062] In step S226, Service 2 sends a start collection request to WebRTC instance B, and WebRTC instance B forwards the start collection request to the collection manager.
[0063] Step S228: The acquisition manager acquires the target data acquired by the target hardware associated with the shared acquisition instance.
[0064] Specifically, if the target data category is video, acquire both audio and image data. If the target data category is audio, acquire the audio data. If the target data category is image, acquire the image data.
[0065] In step S230, the acquisition manager distributes the target data to WebRTC instance A and WebRTC instance B.
[0066] Specifically, the data collection manager can query the target list to obtain the running status of WebRTC instance A and WebRTC instance B. Since both WebRTC instances are in the started state, the target data can be distributed to WebRTC instance A and WebRTC instance B.
[0067] Of course, in practice, when there are multiple shared collection instances, such as the collection instance X and collection instance Y mentioned above, the target data will be returned strictly according to the binding relationship when it is distributed.
[0068] For example, suppose WebRTC instance A is bound to both capture instances X and Y, while WebRTC instance B is bound only to capture instance X. Then the capture manager can return both the acquired audio and image data to WebRTC instance A, and only the audio data to WebRTC instance B.
[0069] It should be understood that when other services in the target application create WebRTC instances, their registration and data collection processes can refer to the above steps S220-S230, which will not be repeated here.
[0070] In summary, this solution eliminates the direct ownership of the data collection manager by a single WebRTC instance. Instead, it binds multiple WebRTC instances to a shared data collection instance, allowing multiple WebRTC instances to register data callback interfaces with the data collection manager. Once collected data arrives, it is broadcast to all WebRTC instances, resulting in the following technical effects:
[0071] First, it enables multiple WebRTC instances to concurrently access audio and image acquisition devices; second, it eliminates service interruptions caused by resource monopolies; third, it reduces resource consumption and avoids repeated initialization of acquisition devices; and fourth, it improves user experience and supports complex multimodal real-time interactive scenarios.
[0072] The above describes the registration and data collection process for each WebRTC instance. The following describes the process of destroying each WebRTC instance after data collection is completed.
[0073] Figure 3This document illustrates the logout method interaction diagram for each WebRTC instance in one example. (Example follows) Figure 3 As shown, the method may include the following steps:
[0074] In step S302, Service 1 sends a stop collection request to WebRTC instance A.
[0075] In step S304, WebRTC instance A sends a deregistration request to the collection manager.
[0076] Step S306: The collection manager unbinds the WebRTC instance A from the shared collection instance.
[0077] For example, if the target data category collected by WebRTC instance A is video, then unbind WebRTC instance A from collection instances X and Y. If the target data category collected by WebRTC instance A is audio, then unbind WebRTC instance A from collection instance X. If the target data category collected by WebRTC instance A is image, then unbind WebRTC instance A from collection instance Y.
[0078] In step S308, if the shared collection instance still has other binding relationships, only return a deregistration completion notification to WebRTC instance A.
[0079] Specifically, when there are multiple shared acquisition instances, for each shared acquisition instance, it can be determined whether it has other binding relationships (i.e., binding with other WebRTC instances). If so, the shutdown operation of the associated target hardware is not performed. If not, the shared acquisition instance is destroyed, and the associated target hardware is shut down.
[0080] For example, if WebRTC instance A is bound to capture instances X and Y, and WebRTC instance B is bound to capture instance X, then after unbinding WebRTC instance A from capture instances X and Y, capture instance X will still be bound to WebRTC instance B. Therefore, the audio capture device associated with capture instance X will not be shut down; that is, the audio capture device will continue to capture audio data. Since capture instance Y has no other binding relationships, it can be destroyed, and the image capture device can be shut down.
[0081] Additionally, the running status of WebRTC instance A in the target list can be changed to disabled. This causes the collection manager to send target data only to WebRTC instance B.
[0082] In step S310, Service 2 sends a stop collection request to WebRTC instance B.
[0083] In step S312, WebRTC instance B sends a deregistration request to the collection manager.
[0084] Step S314: The collection manager unbinds the WebRTC instance B from the shared collection instance.
[0085] For example, if the target data category collected by WebRTC instance B is video, then unbind WebRTC instance B from collection instances X and Y. If the target data category collected by WebRTC instance B is audio, then unbind WebRTC instance B from collection instance X. If the target data category collected by WebRTC instance B is image, then unbind WebRTC instance B from collection instance Y.
[0086] Step S316: If there are no other binding relationships between the shared acquisition instance and the target hardware, destroy the shared acquisition instance and shut down the target hardware.
[0087] In the example above, acquisition instance X can be destroyed, and its associated audio acquisition device can be shut down. At this point, all shared acquisition instances are destroyed, and their associated target hardware is shut down, thus preventing memory leaks and device occupancy.
[0088] It should be understood that in this solution, multiple WebRTC instances share a collection instance, and the shared collection instance is automatically destroyed after all WebRTC instances are deregistered. In fact, the lifecycle of the collection instance is dynamically managed through a reference counting mechanism, which avoids the repeated creation and destruction of collection instances, thereby enabling seamless switching and parallel business operation.
[0089] In summary, the data acquisition method provided in this specification supports multiple WebRTC instances working simultaneously by offering a unified acquisition manager. Furthermore, the acquisition manager's long-term viability until all services exit reduces ICE reconnection and lowers the probability of lag. In addition, separating data acquisition and communication logic improves modularity and facilitates maintenance. Finally, the method destroys and releases shared acquisition instances after all binding relationships are resolved, improving resource utilization.
[0090] It should be noted that this solution also has good scalability and platform portability. That is, only the access method of the acquisition manager needs to be modified, without affecting the standard processes such as PeerConnection, SDP negotiation, encoding and decoding, and network transmission, making it easy to integrate and promote.
[0091] Corresponding to the data acquisition method described above, one embodiment of this specification also provides a data acquisition device, which is installed in the target application. For example... Figure 4 As shown, the device may include:
[0092] The receiving unit 402 is configured to receive a second registration request from the second WebRTC instance, the second registration request indicating at least the target data category that the second WebRTC instance needs to collect;
[0093] Binding unit 404 is used to add a second WebRTC instance to the shared collection instance in response to the existence of a shared collection instance that matches the target data category and that the shared collection instance is already bound to the first WebRTC instance;
[0094] The sending unit 406 is used to distribute the target data collected by the target hardware associated with the shared acquisition instance to the first WebRTC instance and the second WebRTC instance.
[0095] In one embodiment, a first WebRTC instance is created by a first service, and a second WebRTC instance is created by a second service. Both the first and second services are services within the target application.
[0096] In one embodiment, the apparatus further includes a creation unit 408 and a startup unit 410;
[0097] Receiving unit 402 is configured to receive a first registration request from a first WebRTC instance, the first registration request indicating at least a target data category;
[0098] Create unit 408 to create the shared collection instance in response to the absence of a shared collection instance that matches the target data category, and bind the first WebRTC instance to the shared collection instance;
[0099] The startup unit 410 is used to start the target hardware associated with the shared acquisition instance to acquire target data.
[0100] In one embodiment, the target data category includes audio, images, or video;
[0101] The aforementioned shared data collection instances that match the target data category include:
[0102] There exists a first acquisition instance for performing audio data acquisition; and / or,
[0103] There exists a second acquisition instance for performing image data acquisition.
[0104] In one embodiment, the device further includes:
[0105] Adding unit 412 is used to add the second WebRTC instance and its startup status to the target list, which is used to record each WebRTC instance bound to the shared acquisition instance and its running status;
[0106] In one embodiment, the sending unit 406 is specifically used for:
[0107] Query the target list to obtain the running status of the first and second WebRTC instances;
[0108] The target data is distributed to the target instances in the first and second WebRTC instances that are in the running state of "startup".
[0109] In one embodiment, the device further includes:
[0110] Release unit 414 is used to receive a first deregistration request from the first WebRTC instance and release the binding relationship between the first WebRTC instance and the shared collection instance;
[0111] The sending unit 406 is also configured to, in response to the shared acquisition instance being still bound to the second WebRTC instance, return a deregistration completion notification only to the first WebRTC instance.
[0112] In one embodiment, the device further includes a destruction unit 416;
[0113] The release unit 414 is also used to receive a second deregistration request from the second WebRTC instance and release the binding relationship between the second WebRTC instance and the shared collection instance;
[0114] The destruction unit 416 is used to destroy the shared acquisition instance and shut down the target hardware in response to the absence of a binding relationship between the shared acquisition instance and the target hardware.
[0115] In one embodiment, the device further includes:
[0116] Modification unit 418 is used to change the running status of the first WebRTC instance in the target list to the disabled status. The target list is used to record each WebRTC instance bound to the shared collection instance and its running status.
[0117] The functions of each functional module of the apparatus in the above embodiments of this specification can be implemented through the steps of the above method embodiments. Therefore, the specific working process of the apparatus provided in one embodiment of this specification will not be repeated here.
[0118] The data acquisition device provided in one embodiment of this specification can improve resource utilization efficiency and optimize user experience.
[0119] According to another embodiment, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed in a computer, causes the computer to perform a combination Figure 2 or Figure 3 The method described.
[0120] According to another embodiment, a computing device is also provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements a combination... Figure 2 or Figure 3 The method described.
[0121] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the medium or device embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.
[0122] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.
[0123] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this specification. It should be understood that the above description is only a specific embodiment of this specification and is not intended to limit the scope of protection of this specification. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of this specification should be included within the scope of protection of this specification.
Claims
1. A data acquisition method applied to a target application, wherein a data acquisition manager is deployed in the target application, and the method is executed through the data acquisition manager, comprising: Receive a second registration request from a second WebRTC instance, the second registration request indicating at least the target data category that the second WebRTC instance needs to collect; In response to the existence of a shared collection instance that matches the target data category, and the shared collection instance is already bound to the first WebRTC instance, the second WebRTC instance is added and bound to the shared collection instance; The target data collected by the target hardware associated with the shared acquisition instance is distributed to the first WebRTC instance and the second WebRTC instance.
2. The method according to claim 1, wherein, The first WebRTC instance is created by a first service, and the second WebRTC instance is created by a second service. Both the first service and the second service are services in the target application.
3. The method according to claim 1, wherein, Before receiving the second registration request from the second WebRTC instance, the method further includes: Receive a first registration request from the first WebRTC instance, the first registration request indicating at least the target data category; In response to the absence of a shared collection instance matching the target data category, the shared collection instance is created, and the first WebRTC instance is bound to the shared collection instance; Initiate the acquisition of target data using the target hardware associated with the shared acquisition instance.
4. The method according to claim 1, wherein, The target data categories include audio, images, or video; The existence of shared collection instances that match the target data category includes: There exists a first acquisition instance for performing audio data acquisition; And / or, There exists a second acquisition instance for performing image data acquisition.
5. The method according to claim 1, further comprising: Add the second WebRTC instance and its startup status to the target list; The target list is used to record each WebRTC instance bound to the shared collection instance and its running status; The distribution to the first WebRTC instance and the second WebRTC instance includes: Query the target list to obtain the running status of the first WebRTC instance and the second WebRTC instance respectively; The target data is distributed to the target instances in the first WebRTC instance and the second WebRTC instance that are in the running state of the startup state.
6. The method according to claim 1, further comprising: Receive a first deregistration request from the first WebRTC instance to release the binding relationship between the first WebRTC instance and the shared acquisition instance; In response to the shared acquisition instance also being bound to a second WebRTC instance, a deregistration completion notification is returned only to the first WebRTC instance.
7. The method according to claim 6, further comprising: Receive a second deregistration request from the second WebRTC instance to release the binding relationship between the second WebRTC instance and the shared acquisition instance; In response to the absence of a binding relationship between the shared acquisition instance and the target hardware, the shared acquisition instance is destroyed and the target hardware is shut down.
8. The method according to claim 6, further comprising: Change the running status of the first WebRTC instance in the target list to the disabled status; The target list is used to record each WebRTC instance bound to the shared collection instance and its running status.
9. A data acquisition device, disposed in a target application, the device comprising: A receiving unit is configured to receive a second registration request from a second WebRTC instance, the second registration request indicating at least the target data category that the second WebRTC instance needs to collect; An adding unit is used to add and bind the second WebRTC instance to the shared collection instance in response to the existence of a shared collection instance that matches the target data category and the shared collection instance is already bound to the first WebRTC instance; The sending unit is used to distribute the target data collected by the target hardware associated with the shared acquisition instance to the first WebRTC instance and the second WebRTC instance.
10. A computer-readable storage medium having a computer program stored thereon, wherein, When the computer program is executed in the computer, it causes the computer to perform the method of any one of claims 1-8.
11. A computing device comprising a memory and a processor, wherein, The memory stores executable code, and when the processor executes the executable code, it implements the method of any one of claims 1-8.