WO2019071830A1 - Flash与JS页面的高效渲染通讯方法、存储介质、设备及系统 - Google Patents
Flash与JS页面的高效渲染通讯方法、存储介质、设备及系统 Download PDFInfo
- Publication number
- WO2019071830A1 WO2019071830A1 PCT/CN2017/117382 CN2017117382W WO2019071830A1 WO 2019071830 A1 WO2019071830 A1 WO 2019071830A1 CN 2017117382 W CN2017117382 W CN 2017117382W WO 2019071830 A1 WO2019071830 A1 WO 2019071830A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- data
- server
- page
- flash
- flash player
- Prior art date
Links
- 238000009877 rendering Methods 0.000 title claims abstract description 61
- 238000004891 communication Methods 0.000 title claims abstract description 58
- 238000000034 method Methods 0.000 title claims abstract description 44
- 238000012544 monitoring process Methods 0.000 claims abstract description 25
- 239000000872 buffer Substances 0.000 claims description 43
- 238000012545 processing Methods 0.000 claims description 15
- 238000004590 computer program Methods 0.000 claims description 12
- 230000006870 function Effects 0.000 claims description 3
- 230000008569 process Effects 0.000 abstract description 14
- 230000005540 biological transmission Effects 0.000 abstract description 5
- 238000011161 development Methods 0.000 abstract description 2
- 230000004044 response Effects 0.000 description 10
- 238000010586 diagram Methods 0.000 description 2
- 230000035807 sensation Effects 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000007812 deficiency Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
- H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
- H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
- H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
- H04N21/4424—Monitoring of the internal components or processes of the client device, e.g. CPU or memory load, processing speed, timer, counter or percentage of the hard disk space used
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/81—Monomedia components thereof
- H04N21/8166—Monomedia components thereof involving executable data, e.g. software
- H04N21/8173—End-user applications, e.g. Web browser, game
Definitions
- the invention relates to the field of Flash live broadcast development technology, in particular to an efficient rendering communication method, a storage medium, a device and a system for a Flash and a JS page.
- the domestic large-scale live broadcast platform basically uses the Flash player and JS page mashup scheme to build a web-side live broadcast platform.
- the advantage of using this mashup scheme is that it avoids the shackles of JS that can't use Socket (socket), and avoids JS using webSocket (a new protocol for HTML5, which implements a full double of browser and server). Worker communication) Insecure problem with timely communication with the server (because the content of the webSocket communication message is plain text can be directly truncated).
- the Flash player is used as the middle layer of the communication layer: when the Flash player receives the message sent by the server, the page IO (Input/Output, input/output) interface is called to be transmitted to the JS page. .
- the Flash player needs to play the video and render its own business, and also needs to be the intermediate key for communication with the JS page and the server, which makes the overall communication performance very low.
- the existing rendering operations are not based on the underlying rendering mode, but based on the rendering mode of the business logic layer, the rendering efficiency will be caused by the large amount of communication between the Flash player and the JS page.
- Performance bottleneck problem (the existing mashup scheme directly calls the IO interface every time you receive data that needs to be transparently transmitted to the JS page, so that when the number of times the IO interface needs to be called for a certain period of time is limited, the rendered image has The feeling of Caton, the user experience is poor.
- the object of the present invention is to overcome the deficiencies of the above background art, and provide an efficient rendering communication method, a storage medium, a device and a system for a Flash and a JS page, which can solve a large amount of communication between a Flash player and a JS page in a rendering process.
- the performance bottleneck problem is caused, so that the rendered picture has no feeling of jamming and the user experience is good.
- the technical solution adopted by the present invention is to provide an efficient rendering communication method for Flash and JS pages, and the method includes the following operations:
- the server receives the data and stores the data in the data cache pool;
- the data in the current data buffer pool is divided into N parts by using the IO data interface agreed with the JS page for receiving the Flash player. It is sent to the JS page in N times, and N is a positive integer greater than 1 and less than or equal to 10; after receiving the data sent by the Flash player, the JS page updates the current JS page according to the underlying rendering of the data.
- the specific operation of establishing a Socket connection between the Flash player and the server, and setting an event listener for monitoring whether the server has data is: instantiating a Flash Player Socket object, and set the server IP to be connected and the server post parameter to be connected, establish a Socket connection with the server; then set the event listener for monitoring whether the server has data.
- the data in the current data buffer pool is sent to the JS page one by one.
- the present invention also provides a storage medium having stored thereon a computer program, the computer program being executed by the processor to implement the steps of the efficient rendering communication method of the Flash and JS pages.
- the present invention also provides an efficient rendering communication device for Flash and JS pages, comprising a memory, a processor, and a computer program stored on the memory and running on the processor, the processor implementing the computer program to implement the above Steps for efficient rendering communication methods for Flash and JS pages.
- the invention also provides an efficient rendering communication system for Flash and JS pages, the system comprising a data buffer pool creation module, a server connection and monitoring setting module, a data buffer module and a rendering communication processing module;
- the data cache pool creation module is configured to: create and initialize a data cache pool, where the data cache pool is used to cache data received by the Flash player from the server;
- the server connection and monitoring setting module is configured to: establish a Socket connection between the Flash player and the server, and set an event monitor for monitoring whether the server has data sent;
- the data caching module is configured to: when the server detects that the data is sent, receive the data of the server and store the data in the data buffer pool;
- the rendering communication processing module is configured to: monitor a frame rate event of the bottom layer of the Flash player, and once the frame rate event is monitored, use the IO data interface agreed with the JS page for receiving the Flash player to buffer the current data.
- the data in the pool is divided into N parts and sent to the JS page N times, N is a positive integer greater than 1 and less than or equal to 10; after receiving the data sent by the Flash player, the JS page updates the underlying rendering according to the data. Current JS page.
- the server connection and monitoring setting module establishes a Socket connection between the Flash player and the server, and sets a specific operation for monitoring whether the server has data sent by the event: in Flash
- the player instantiates a Socket object, sets the server IP to be connected, and the server post parameter to be connected, establishes a Socket connection with the server, and then sets an event listener for monitoring whether the server has data.
- the rendering communication processing module sends the data in the current data buffer pool to the JS page.
- the rendering communication processing module divides the data in the current data buffer pool into N shares and sends the data to the JS page in N times, and then clears the current data buffer pool.
- the data in the current data buffer pool is divided into N shares and sent to the JS page N times, instead of being sent to the JS page at one time, thereby avoiding the use of data in the data buffer pool.
- the data With a single IO operation, the data will be large, which will increase the page consumption and reduce the overall processing efficiency.
- the value range of N is set to not exceed 10, that is, 1 millisecond is sent once, which can reduce the peak of data communication, and can ensure that the picture is not stuck, because the entire process of performing rendering in each frame frequency is guaranteed (event scheduling)
- the total time of the logical operation, update page) will not exceed 33 milliseconds. Therefore, compared with the prior art, the present invention solves the performance bottleneck caused by a large amount of communication between the Flash player and the JS page in the rendering process, so that the rendered picture has no jamming feeling and the user experience is good.
- the IO data interface IOHandle for receiving the Flash player is used in response to the IO operation of the Flash player and the JS page.
- all IO operations can be restricted to the response interface IOHandle of the frame rate event ENTER_FRAME for processing, thereby controlling the number of IO communications in the response interface IOHandle, avoiding IO operations in other places, increasing the number of IO operations, and facilitating Unified IO operation management.
- the current data buffer pool is cleared. This makes it easy for the data cache pool to cache new data sent by the server in time to avoid mixing with previously processed data, so that new data can be sent to JS when the next frame rate event is triggered (ie, within the next frame rate).
- the page does not mix old data, avoiding repeated data transmission, which ensures accuracy and improves efficiency, and further improves communication performance.
- FIG. 1 is a flowchart of an efficient rendering communication method of a Flash and a JS page according to an embodiment of the present invention
- FIG. 2 is a schematic structural diagram of an efficient rendering communication device for Flash and JS pages according to an embodiment of the present invention
- FIG. 3 is a structural block diagram of an efficient rendering communication system for Flash and JS pages according to an embodiment of the present invention.
- the Flash player rendering is composed of one frame and one frame, such as a 30-frame Flash animation, which renders a picture in 30.33 milliseconds, and renders 30 pictures in a second like a slide, so that the user See a 30 frame Flash animation.
- a 30-frame Flash animation which renders a picture in 30.33 milliseconds, and renders 30 pictures in a second like a slide, so that the user See a 30 frame Flash animation.
- 24 pictures are played in one second, and the user does not have a sensation in the naked eye. The more pictures played in one second, the smoother the Flash animation is.
- the picture is played less than 24 pictures in one second, the user starts to feel stuck, and the less the picture played in one second, the stronger the feeling of the card.
- the Flash player can ensure that there are enough pictures rendered per second (preferably more than 24 pictures) while performing IO communication with the JS page, and the average rendering time per frame is less than 33 milliseconds. .
- the rendering process of the Flash frame can be divided into three processes according to the sequence: A, event scheduling, that is, the listening process of the underlying frame rate event of the Flash player; B, logical operation, that is, the IO operation of the Flash player and the JS page. Process; C, update the page, that is, the process of rendering and updating the page. Only when the three processes of ABC are completed, the total time is less than 33 milliseconds to ensure that the page is not stuck. The IO operation of each Flash and JS page takes about 1 millisecond, so in order to ensure that the card is not stuck, the IO operation of the Flash player and the JS page must be controlled within one frame lifetime (ie, one frame rate). Only operate 10 times or less (there can be very small fluctuations depending on the browser, but usually no more than 10 times).
- an embodiment of the present invention provides an efficient rendering communication method for a Flash and a JS page, and the method includes the following steps:
- Step S1 Create and initialize a data cache pool, where the data cache pool is used to cache data received by the Flash player from the server, including but not limited to various animation images, animation information, and data sources required for the Flash player to play the animation. Information, etc.
- a data cache pool can be created by creating an array of data cache pools. For example, this can be done with the following code:
- Step S2 Establish a Socket connection between the Flash player and the server; and set an event listener for monitoring whether the server has data.
- step S2 specifically includes the following operations:
- Step S201 instantiating a Socket object in the Flash player, and setting a server IP (Internet Protocol) to be connected and a server post parameter to be connected (post is a method for transmitting data to the server through an HTTP post mechanism, For the post mode, the server uses Request.Form to get the submitted data) and establishes a Socket connection with the server.
- server IP Internet Protocol
- Step S202 Setting an event monitor for monitoring whether the server has data sent.
- the event monitoring is set in advance, in order to prepare the Flash player to receive the data sent by the server in time.
- the listen event can be set to ProgressEvent.SOCKET_DATA; this event fires when the server sends a message to the Flash player.
- the implementation codes of steps S201 and S202 can be as follows:
- Socket new socket() // instantiate a Socket object
- Socket.conet(ip,post) //Set the server IP to be connected and the server post parameter to be connected, and establish a Socket connection with the server;
- Socket.addEventlistener(ProgressEvent.SOCKET_DATA, SOCKET_DATAHANDLE) //Set the event listener for listening to whether the server has data.
- the listen event is ProgressEvent.SOCKET_DATA
- the response method is SOCKET_DATAHANDLE, which is step S3 in the following.
- the response process is The details are described in step S3, and are not described here.
- Step S3 once the server detects that the data is sent, the data of the server is received and the data is stored in the data buffer pool.
- the server's data is received and stored in the data cache pool.
- the implementation code of the SOCKET_DATAHANDLE method can be: IODATALIST.push(data).
- Step S4 Listening to the frame rate event of the bottom layer of the Flash player, once the frame rate event is monitored, the data in the current data buffer pool is divided by using the IO data interface IOHandle that is agreed with the JS page for receiving the Flash player. It is sent to the JS page for N times and N times. N is a positive integer greater than 1 and less than or equal to 10; after receiving the data sent by the Flash player, the JS page updates the current JS page according to the underlying rendering of the data.
- the implementation code for listening to the underlying frame rate event of the Flash player may be stage.addEventlistener(ENTER_FRAME, IOHandle); wherein ENTER_FRAME represents a frame rate event and the response method is IOHandle.
- the system underlying method ExternalInterface.call("iohandle", datalist) can be called, wherein the datalist is in the data cache pool. The data set transmitted this time after being divided into N shares.
- step S4 once the frame rate event is detected, the IO data interface IOHandle for receiving the Flash player transmission agreed with the JS page is used to respond to the IO operation of the Flash player and the JS page, so that Limit all IO operations to the response interface IOHandle of the frame rate event ENTER_FRAME, so as to control the number of IO communications in the response interface IOHandle, to avoid IO operations in other places, which will increase the number of IO operations, which is convenient for unified. IO operation management.
- step S4 the data in the current data buffer pool is divided into N shares and sent to the JS page N times, instead of being sent to the JS page at a time, considering that if the amount of data in the data buffer pool IODATALIST is too large, The IO operation data will be large, which will increase the page consumption, and the overall processing efficiency will be reduced.
- the N-time transmission can solve the above problem, and in order to ensure that the page is not stuck, in this embodiment, the N is taken.
- the value range is set to no more than 10, preferably 10 times, that is, 1 millisecond is sent once, which can reduce the peak of data communication and ensure that the picture is not stuck. Therefore, the above method solves the performance bottleneck caused by a large amount of communication between the Flash player and the JS page in the rendering process, so that the rendered picture has no feeling of jamming and the user experience is good.
- the number of data in the current data buffer pool is less than N. If the above occurs, the data in the current data buffer pool is sent to the JS page one by one.
- Step S5 After the data in the data buffer pool is sent, the current data buffer pool is cleared. It can be understood that, after step S4, the current data buffer pool is also emptied in step S5, so as to facilitate the data cache pool to cache new data sent by the server in time to avoid mixing with the previously processed data, so as to When a frame rate event is triggered (ie, within the next frame rate), new data is sent to the JS page without mixing the old data, thereby avoiding repeated transmission of the data, that is, ensuring accuracy and improving efficiency, further improving Communication performance.
- the embodiment of the present invention further provides a storage medium, where the computer program is stored, and when the computer program is executed by the processor, the Flash and the JS in the foregoing embodiments can be implemented.
- the steps of the page's efficient rendering communication method includes a U disk, a mobile hard disk, a ROM (Read-Only Memory), a RAM (Random Access Memory), a disk or an optical disk, and the like.
- the medium of the code includes a U disk, a mobile hard disk, a ROM (Read-Only Memory), a RAM (Random Access Memory), a disk or an optical disk, and the like. The medium of the code.
- the embodiment of the present invention further provides an efficient rendering communication device for Flash and JS pages, including a memory, a processor, and a memory and a storage device.
- an efficient rendering communication device for Flash and JS pages including a memory, a processor, and a memory and a storage device.
- an embodiment of the present invention further provides an efficient rendering communication system for a Flash and a JS page.
- the system includes a data cache pool creation module, a server connection and a listening setting module, a data cache module, and a rendering communication processing module. among them:
- the data cache pool creation module is used to: create and initialize a data cache pool, which is used to cache data received by the Flash player from the server.
- the server connection and monitoring setting module is used to: establish a Socket connection between the Flash player and the server, and set an event monitor for monitoring whether the server has data.
- the specific implementation process includes: instantiating a Socket object in the Flash player, setting the server IP to be connected and the server post parameter to be connected, establishing a Socket connection with the server; and then setting whether to listen to the server for data. Event listener.
- the data caching module is configured to: when the server detects that the data is sent, receive the data of the server and store the data in the data buffer pool;
- the rendering communication processing module is configured to: monitor the frame rate event of the underlying Flash player, and once the frame rate event is monitored, use the IO data interface agreed with the JS page for receiving the Flash player to transmit the current data in the buffer pool.
- the data is divided into N parts and sent to the JS page N times, N is a positive integer greater than 1 and less than or equal to 10; after receiving the data sent by the Flash player, the JS page updates the current JS according to the underlying rendering of the data. page. Further, if the number of data in the current data buffer pool is less than N, the rendering communication processing module sends the data in the current data buffer pool to the JS page. Further, the rendering communication processing module divides the data in the current data buffer pool into N shares and sends the data buffer pool to the JS page after N times.
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Databases & Information Systems (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Computer Security & Cryptography (AREA)
- Information Transfer Between Computers (AREA)
Abstract
本发明公开了一种Flash与JS页面的高效渲染通讯方法、存储介质、设备及系统,涉及Flash直播开发技术领域。该方法包括:创建并初始化数据缓存池;建立Flash播放器与服务器之间的Socket连接,并设置事件监听;一旦监听到服务器有数据发来,则接收服务器的数据并存入数据缓存池中;监听Flash播放器底层的帧频事件,一旦监听到帧频事件,则利用IO数据接口,将当前数据缓存池中的数据分为N份并分N次发送给JS页面;JS页面收到Flash播放器发来的数据后,根据该数据进行底层的渲染来更新当前JS页面。本发明能解决渲渲染过程中因Flash播放器与JS页面的大量通讯而引起性能瓶颈问题,使得渲染的画面无卡顿感,用户体验佳。
Description
本发明涉及Flash直播开发技术领域,具体来讲是一种Flash与JS页面的高效渲染通讯方法、存储介质、设备及系统。
目前,国内大型直播平台基本都是使用Flash播放器与JS页面混搭方案来构建web端直播平台。采用这种混搭方案的好处是:避免了JS不能用Socket(套接字)的及时通讯的尴尬,也避免了JS使用webSocket(是HTML5一种新的协议,它实现了浏览器与服务器全双工通信)与服务器及时通讯的不安全的问题(因webSocket通讯消息内容是明文可以直接被截断)。
但是,现有的混搭方案中,均采用Flash播放器作为通讯层中间键:当Flash播放器收到服务器发来的消息,则调用页面IO(Input/Output,输入/输出)接口传递到JS页面。而这一方式中,Flash播放器需要播放视频并渲染自己的业务,同时还需要作为与JS页面、服务器通讯的中间键,这就使得整体的通讯性能很低。特别是在Flash播放器渲染过程中,由于现有的渲染操作都不是基于底层的渲染模式,而是基于业务逻辑层面的渲染模式,因此渲染效率会因Flash播放器与JS页面的大量通讯而引起性能瓶颈问题(现有的混搭方案中每次收到需要透传给JS页面的数据时直接调用IO接口,这样当一定时间内需要调用IO接口次数多时性能受限),从而使得渲染的画面有卡顿感,用户体验差。
发明内容
本发明的目的是为了克服上述背景技术的不足,提供一种Flash与JS页面的高效渲染通讯方法、存储介质、设备及系统,能解决渲渲染过程中因Flash播放器与JS页面的大量通讯而引起性能瓶颈问题,使得渲染的画面无卡顿感,用户体验佳。
为达到以上目的,本发明采取的技术方案是:提供一种Flash与JS页面的高效渲染通讯方法,该方法包括以下操作:
创建并初始化数据缓存池,该数据缓存池用于缓存Flash播放器从服务器接收到的数据;
建立Flash播放器与服务器之间的Socket连接,并设置一个用于监听服务器是否有数据发来的事件监听;
一旦监听到服务器有数据发来时,则接收服务器的数据并将该数据存入数据缓存池中;
监听Flash播放器底层的帧频事件,一旦监听到帧频事件,则利用与JS页面约定好的用于接收Flash播放器传送的IO数据接口,将当前数据缓存池中的数据分为N份并分N次发送给JS页面,N为大于1小于等于10的正整数;JS页面收到Flash播放器发来的数据后,根据该数据进行底层的渲染来更新当前JS页面。
在上述技术方案的基础上,所述建立Flash播放器与服务器之间的Socket连接,并设置一个用于监听服务器是否有数据发来的事件监听的具体操作为:在Flash播放器中实例化一个Socket的对象,并设置需要连接的服务器IP以及需要连接的服务器post参数,与服务器建立Socket连接;再设置用于监听服务器是否有数据发来的事件监听。
在上述技术方案的基础上,若当前数据缓存池中的数据的条数不 足N条时,将当前数据缓存池中的数据一条一条发送给JS页面。
在上述技术方案的基础上,将当前数据缓存池中的数据分为N份并分N次发送给JS页面后,将当前数据缓存池清空。
本发明还提供一种存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现上述Flash与JS页面的高效渲染通讯方法的步骤。
本发明还提供一种Flash与JS页面的高效渲染通讯设备,包括存储器、处理器及存储在存储器上并在所述处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现上述Flash与JS页面的高效渲染通讯方法的步骤。
本发明还提供一种Flash与JS页面的高效渲染通讯系统,该系统包括数据缓存池创建模块、服务器连接及监听设置模块、数据缓存模块、渲染通讯处理模块;
所述数据缓存池创建模块用于:创建并初始化数据缓存池,该数据缓存池用于缓存Flash播放器从服务器接收到的数据;
所述服务器连接及监听设置模块用于:建立Flash播放器与服务器之间的Socket连接,并设置一个用于监听服务器是否有数据发来的事件监听;
所述数据缓存模块用于:一旦监听到服务器有数据发来时,则接收服务器的数据并将该数据存入数据缓存池中;
所述渲染通讯处理模块用于:监听Flash播放器底层的帧频事件,一旦监听到帧频事件,则利用与JS页面约定好的用于接收Flash播放器传送的IO数据接口,将当前数据缓存池中的数据分为N份并分N次发送给JS页面,N为大于1小于等于10的正整数;JS页面收到Flash播放器发来的数据后,根据该数据进行底层的渲染来更新当前 JS页面。
在上述技术方案的基础上,所述服务器连接及监听设置模块建立Flash播放器与服务器之间的Socket连接,并设置一个用于监听服务器是否有数据发来的事件监听的具体操作为:在Flash播放器中实例化一个Socket的对象,并设置需要连接的服务器IP以及需要连接的服务器post参数,与服务器建立Socket连接;再设置用于监听服务器是否有数据发来的事件监听。
在上述技术方案的基础上,若当前数据缓存池中的数据的条数不足N条时,所述渲染通讯处理模块将当前数据缓存池中的数据一条一条发送给JS页面。
在上述技术方案的基础上,所述渲染通讯处理模块将当前数据缓存池中的数据分为N份并分N次发送给JS页面后,将当前数据缓存池清空。
本发明的有益效果在于:
(1)本发明中,是将当前数据缓存池中的数据分为N份并分N次发送给JS页面,而不是一次发送给JS页面,可以避免因数据缓存池中数据量过多时而采用单次的IO操作,数据就会很大,从而会增加页面消耗,整体处理效率会降低的问题。并且,N的取值范围设置为不超过10,也就是1毫秒发一次,这样可以降低数据通讯峰值,又能保证画面不卡顿,因为保证了每一帧频内执行渲染整个过程(事件调度、逻辑操作、更新页面)的总时间不会超过33毫秒。因此,相较于现有技术来说,本发明通过上述方式解决了渲染过程中因Flash播放器与JS页面的大量通讯而引起性能瓶颈问题,使得渲染的画面无卡顿感,用户体验佳。
(2)本发明中,一旦监听到帧频事件则利用与JS页面约定好的 用于接收Flash播放器传送的IO数据接口IOHandle来响应Flash播放器与JS页面的IO操作。这样可以将所有的IO操作限制在帧频事件ENTER_FRAME的响应接口IOHandle中做处理,从而在响应接口IOHandle中控制IO通讯的次数,避免程序在其他地方还有IO操作,会增加IO操作次数,便于统一的IO操作管理。
(3)本发明中,当数据缓存池中的数据发送完成后,会将当前数据缓存池清空。这样可便于让数据缓存池能及时缓存服务器发来的新数据而避免与之前处理过数据相混合,以便在下一次的帧频事件触发时(即下一次帧频内)将新的数据发送给JS页面而不会混合旧数据,避免了数据的重复发送,即保证了准确性又提升了效率,进一步提升了通讯性能。
图1为本发明实施例中Flash与JS页面的高效渲染通讯方法的流程图;
图2为本发明实施例中Flash与JS页面的高效渲染通讯设备的结构示意图;
图3为本发明实施例中Flash与JS页面的高效渲染通讯系统的结构框图。
下面结合附图及具体实施例对本发明作进一步的详细描述。
可以理解的是,Flash播放器渲染是由一帧一帧拼成的,比如一个30帧的Flash动画,是以30.33毫秒渲染一个画面,一秒钟类似幻灯片依次渲染30个画面,这样用户就看到一个30帧的Flash动画。一般一秒播放24张图片,用户肉眼是不会有卡顿感。一秒播放的图 片越多Flash动画越流畅,相反当一秒播放图片小于24张图片用户开始有卡顿感,当一秒播放的图片越少时卡顿感越强。所以,为了解决卡顿感的问题,Flash播放器在与JS页面进行IO通讯的同时得保证每秒渲染的画面够多(最好大于24张图片),及时平均每一帧渲染时间小于33毫秒。
而Flash帧的渲染过程,可依照先后顺序划分为三个过程:A、事件调度,即对Flash播放器底层帧频事件的监听过程;B、逻辑操作,即Flash播放器与JS页面的IO操作过程;C、更新页面,即对页面的渲染及更新过程。只有保证ABC这三个过程执行完毕总时间小于33毫秒才能保证页面不卡。而每一条Flash与JS页面的IO操作耗时大约是1毫秒,所以为了保证不卡,必须得控制Flash播放器与JS页面的IO操作在1个帧的生命周期内(即一次帧频内)只操作10次以下(根据浏览器的不同可以有很微小的浮动,但通常也不会超过10次)。
基于上述设计思路,参见图1所示,本发明实施例提供一种Flash与JS页面的高效渲染通讯方法,该方法包括以下步骤:
步骤S1、创建并初始化数据缓存池,该数据缓存池用于缓存Flash播放器从服务器接收到的数据,包括但不限于Flash播放器播放动画时所需的各种动画画面、动画信息、数据源信息等。
具体来说,在实际操作中,可通过建立一个数据缓存池数组的方式来创建数据缓存池。例如,可通过以下代码实现:
IODATALIST(IODATALIST=new Array()),其中,IODATALIST为数据缓存池。
步骤S2、建立Flash播放器与服务器之间的Socket(套接字)连接;并设置一个用于监听服务器是否有数据发来的事件监听。
具体来说,在一种实施方式中,步骤S2具体包括以下操作:
步骤S201、在Flash播放器中实例化一个Socket的对象,并设置需要连接的服务器IP(Internet Protocol,网际协议)以及需要连接的服务器post参数(post是通过HTTP post机制向服务器传送数据的方式,对于post方式,服务器端用Request.Form获取提交的数据),与服务器建立Socket连接。
步骤S202、设置一个用于监听服务器是否有数据发来的事件监听。在该步骤中,事先设置好事件监听,是为了下一步Flash播放器能及时接收到服务器发来的数据做准备。
举例来说,实际操作时,可将监听事件设置为ProgressEvent.SOCKET_DATA;该事件当服务器向Flash播放器发送消息时触发。具体来说,步骤S201、S202的实现代码可如下:
Socket=new socket() //实例化一个Socket的对象;
Socket.conet(ip,post) //设置需要连接的服务器IP以及需要连接的服务器post参数,与服务器建立Socket连接;
Socket.addEventlistener(ProgressEvent.SOCKET_DATA,SOCKET_DATAHANDLE) //设置用于监听服务器是否有数据发来的事件监听;其中,监听事件为ProgressEvent.SOCKET_DATA,响应方法为SOCKET_DATAHANDLE,即下文中的步骤S3,响应过程在步骤S3中详细介绍,此处不赘述。
步骤S3、一旦监听到服务器有数据发来时,则接收服务器的数据并将该数据存入数据缓存池中。如上文中举例所述,一旦监听到ProgressEvent.SOCKET_DATA事件,响应SOCKET_DATAHANDLE方法,接收服务器的数据并将该数据存入数据缓存池中。具体来说,SOCKET_DATAHANDLE方法的实现代码可为:IODATALIST.push(data)。
步骤S4、监听Flash播放器底层的帧频事件,一旦监听到帧频事件,则利用与JS页面约定好的用于接收Flash播放器传送的IO数据接口IOHandle,将当前数据缓存池中的数据分为N份并分N次发送给JS页面,N为大于1小于等于10的正整数;JS页面收到Flash播放器发来的数据后,根据该数据进行底层的渲染来更新当前JS页面。
具体来说,监听Flash播放器底层的帧频事件的实现代码可为stage.addEventlistener(ENTER_FRAME,IOHandle);其中,ENTER_FRAME代表帧频事件,响应方法为IOHandle。另外,将当前数据缓存池中的数据发送给JS页面时(即响应IO操作时),可调用系统底层方法ExternalInterface.call("iohandle",datalist)来实现,其中,datalist则为数据缓存池中被分为N份后,本次传送的数据集合。
可以理解的是,步骤S4中,一旦监听到帧频事件,则利用与JS页面约定好的用于接收Flash播放器传送的IO数据接口IOHandle来响应Flash播放器与JS页面的IO操作,这样可以将所有的IO操作限制在帧频事件ENTER_FRAME的响应接口IOHandle中做处理,从而在响应接口IOHandle中控制IO通讯的次数,避免程序在其他地方还有IO操作,会增加IO操作次数,便于统一的IO操作管理。
另外,步骤S4中,将当前数据缓存池中的数据分为N份并分N次发送给JS页面,而不是一次发送给JS页面,是考虑到如果数据缓存池IODATALIST中里面数据量过多时单次的IO操作数据就会很大,从而会增加页面消耗,整体处理效率会降低;而分N次发送则可以解决上述问题,并且,为了保证页面不卡顿,本实施例中,N的取值范围设置为不超过10,优选为10次,也就是1毫秒发一次,这样可以降低数据通讯峰值,又能保证画面不卡顿。因此,通过上述方式则解决了渲渲染过程中因Flash播放器与JS页面的大量通讯而引起性能 瓶颈问题,使得渲染的画面无卡顿感,用户体验佳。
进一步的,在实际应用中,可能出现当前数据缓存池中的数据的条数不足N条的情况。若出现上述情况,则将当前数据缓存池中的数据一条一条发送给JS页面。
步骤S5、当数据缓存池中的数据发送完成后,将当前数据缓存池清空。可以理解的是,步骤S4之后,还会在步骤S5中将当前数据缓存池清空,是为了便于让数据缓存池能及时缓存服务器发来的新数据而避免与之前处理过数据相混合,以便在下一次的帧频事件触发时(即下一次帧频内)将新的数据发送给JS页面而不会混合旧数据,避免了数据的重复发送,即保证了准确性又提升了效率,进一步提升了通讯性能。
对应上述的Flash与JS页面的高效渲染通讯方法,本发明实施例还提供一种存储介质,其上存储有计算机程序,该计算机程序被处理器执行时可实现上述各实施例中的Flash与JS页面的高效渲染通讯方法的步骤。需要说明的是,所述存储介质包括U盘、移动硬盘、ROM(Read-Only Memory,只读存储器)、RAM(Random Access Memory,随机存取存储器)、磁碟或者光盘等各种可以存储程序代码的介质。
另外,参见图2所示,对应上述的Flash与JS页面的高效渲染通讯方法,本发明实施例还提供一种Flash与JS页面的高效渲染通讯设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,该处理器执行计算机程序时可实现上述各实施例中的Flash与JS页面的高效渲染通讯方法的步骤。
参见图3所示,本发明实施例还提供一种Flash与JS页面的高效渲染通讯系统,该系统包括数据缓存池创建模块、服务器连接及监听设置模块、数据缓存模块、渲染通讯处理模块。其中:
数据缓存池创建模块用于:创建并初始化数据缓存池,该数据缓存池用于缓存Flash播放器从服务器接收到的数据。
服务器连接及监听设置模块用于:建立Flash播放器与服务器之间的Socket连接,并设置一个用于监听服务器是否有数据发来的事件监听。其具体实现流程包括:在Flash播放器中实例化一个Socket的对象,并设置需要连接的服务器IP以及需要连接的服务器post参数,与服务器建立Socket连接;再设置用于监听服务器是否有数据发来的事件监听。
数据缓存模块用于:一旦监听到服务器有数据发来时,则接收服务器的数据并将该数据存入数据缓存池中;
渲染通讯处理模块用于:监听Flash播放器底层的帧频事件,一旦监听到帧频事件,则利用与JS页面约定好的用于接收Flash播放器传送的IO数据接口,将当前数据缓存池中的数据分为N份并分N次发送给JS页面,N为大于1小于等于10的正整数;JS页面收到Flash播放器发来的数据后,根据该数据进行底层的渲染来更新当前JS页面。进一步地,若当前数据缓存池中的数据的条数不足N条时,所述渲染通讯处理模块将当前数据缓存池中的数据一条一条发送给JS页面。更进一步地,所述渲染通讯处理模块将当前数据缓存池中的数据分为N份并分N次发送给JS页面后,将当前数据缓存池清空。
需要说明的是:上述实施例提供的系统在实现Flash播放器与JS页面间的高效渲染通讯时,仅以上述各功能模块的划分进行举例说明,实际应用中,可根据需要而将上述功能分配由不同的功能模块完成,即将系统的内部结构划分成不同的功能模块,以完成以上描述的全部或部分功能。
本发明不局限于上述实施方式,对于本技术领域的普通技术人员 来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也视为本发明的保护范围之内。
本说明书中未作详细描述的内容属于本领域专业技术人员公知的现有技术。
Claims (10)
- 一种Flash与JS页面的高效渲染通讯方法,其特征在于,该方法包括以下操作:创建并初始化数据缓存池,该数据缓存池用于缓存Flash播放器从服务器接收到的数据;建立Flash播放器与服务器之间的Socket连接,并设置一个用于监听服务器是否有数据发来的事件监听;一旦监听到服务器有数据发来时,则接收服务器的数据并将该数据存入数据缓存池中;监听Flash播放器底层的帧频事件,一旦监听到帧频事件,则利用与JS页面约定好的用于接收Flash播放器传送的IO数据接口,将当前数据缓存池中的数据分为N份并分N次发送给JS页面,N为大于1小于等于10的正整数;JS页面收到Flash播放器发来的数据后,根据该数据进行底层的渲染来更新当前JS页面。
- 如权利要求1所述的Flash与JS页面的高效渲染通讯方法,其特征在于:所述建立Flash播放器与服务器之间的Socket连接,并设置一个用于监听服务器是否有数据发来的事件监听的具体操作为:在Flash播放器中实例化一个Socket的对象,并设置需要连接的服务器IP以及需要连接的服务器post参数,与服务器建立Socket连接;再设置用于监听服务器是否有数据发来的事件监听。
- 如权利要求1所述的Flash与JS页面的高效渲染通讯方法,其特征在于:若当前数据缓存池中的数据的条数不足N条时,将当前数据缓存池中的数据一条一条发送给JS页面。
- 如权利要求1所述的Flash与JS页面的高效渲染通讯方法,其特征在于:将当前数据缓存池中的数据分为N份并分N次发送给 JS页面后,将当前数据缓存池清空。
- 一种存储介质,其上存储有计算机程序,其特征在于:所述计算机程序被处理器执行时实现上述权利要求1至4中任一项所述方法的步骤。
- 一种Flash与JS页面的高效渲染通讯设备,包括存储器、处理器及存储在所述存储器上并在所述处理器上运行的计算机程序,其特征在于:所述处理器执行所述计算机程序时实现上述权利要求1至4中任一项所述方法的步骤。
- 一种Flash与JS页面的高效渲染通讯系统,其特征在于:该系统包括数据缓存池创建模块、服务器连接及监听设置模块、数据缓存模块、渲染通讯处理模块;所述数据缓存池创建模块用于:创建并初始化数据缓存池,该数据缓存池用于缓存Flash播放器从服务器接收到的数据;所述服务器连接及监听设置模块用于:建立Flash播放器与服务器之间的Socket连接,并设置一个用于监听服务器是否有数据发来的事件监听;所述数据缓存模块用于:一旦监听到服务器有数据发来时,则接收服务器的数据并将该数据存入数据缓存池中;所述渲染通讯处理模块用于:监听Flash播放器底层的帧频事件,一旦监听到帧频事件,则利用与JS页面约定好的用于接收Flash播放器传送的IO数据接口,将当前数据缓存池中的数据分为N份并分N次发送给JS页面,N为大于1小于等于10的正整数;JS页面收到Flash播放器发来的数据后,根据该数据进行底层的渲染来更新当前JS页面。
- 如权利要求7所述的Flash与JS页面的高效渲染通讯系统, 其特征在于:所述服务器连接及监听设置模块建立Flash播放器与服务器之间的Socket连接,并设置一个用于监听服务器是否有数据发来的事件监听的具体操作为:在Flash播放器中实例化一个Socket的对象,并设置需要连接的服务器IP以及需要连接的服务器post参数,与服务器建立Socket连接;再设置用于监听服务器是否有数据发来的事件监听。
- 如权利要求7所述的Flash与JS页面的高效渲染通讯系统,其特征在于:若当前数据缓存池中的数据的条数不足N条时,所述渲染通讯处理模块将当前数据缓存池中的数据一条一条发送给JS页面。
- 如权利要求7所述的Flash与JS页面的高效渲染通讯系统,其特征在于:所述渲染通讯处理模块将当前数据缓存池中的数据分为N份并分N次发送给JS页面后,将当前数据缓存池清空。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710932695.0 | 2017-10-10 | ||
CN201710932695.0A CN107743266B (zh) | 2017-10-10 | 2017-10-10 | Flash与JS页面的高效渲染通讯方法、存储介质、设备及系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2019071830A1 true WO2019071830A1 (zh) | 2019-04-18 |
Family
ID=61237053
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2017/117382 WO2019071830A1 (zh) | 2017-10-10 | 2017-12-20 | Flash与JS页面的高效渲染通讯方法、存储介质、设备及系统 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN107743266B (zh) |
WO (1) | WO2019071830A1 (zh) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109831701B (zh) * | 2019-01-28 | 2021-12-21 | 四川长虹电器股份有限公司 | 数字电视设备浏览器以及跨页面系统事件的扩展方法 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7269784B1 (en) * | 2001-01-22 | 2007-09-11 | Kasriel Stephane | Server-originated differential caching |
CN105677688A (zh) * | 2014-11-21 | 2016-06-15 | 博雅网络游戏开发(深圳)有限公司 | 页面数据加载方法和系统 |
CN105824874A (zh) * | 2016-02-01 | 2016-08-03 | 乐视移动智能信息技术(北京)有限公司 | 移动终端及其网页渲染方法、装置 |
CN106156148A (zh) * | 2015-04-14 | 2016-11-23 | 腾讯科技(深圳)有限公司 | 一种页面的渲染方法、装置和终端设备 |
CN106991096A (zh) * | 2016-01-21 | 2017-07-28 | 阿里巴巴集团控股有限公司 | 动态页面渲染方法及装置 |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101478669B (zh) * | 2008-08-29 | 2012-06-27 | 百视通网络电视技术发展有限责任公司 | 一种iptv系统上基于浏览器的媒体播放控制方法 |
CN104519075A (zh) * | 2013-09-26 | 2015-04-15 | 中兴通讯股份有限公司 | 一种数据传输方法及设备 |
CN106303674B (zh) * | 2015-06-11 | 2019-07-09 | 阿里巴巴集团控股有限公司 | 数据传输方法、装置和智能电视系统 |
CN105898520A (zh) * | 2016-04-07 | 2016-08-24 | 合网络技术(北京)有限公司 | 视频帧截取方法和装置 |
CN106131142A (zh) * | 2016-06-27 | 2016-11-16 | 乐视控股(北京)有限公司 | 多媒体数据存储方法及装置 |
CN106330878A (zh) * | 2016-08-18 | 2017-01-11 | 乐视控股(北京)有限公司 | 管理视频流解析的方法及装置 |
-
2017
- 2017-10-10 CN CN201710932695.0A patent/CN107743266B/zh not_active Expired - Fee Related
- 2017-12-20 WO PCT/CN2017/117382 patent/WO2019071830A1/zh active Application Filing
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7269784B1 (en) * | 2001-01-22 | 2007-09-11 | Kasriel Stephane | Server-originated differential caching |
CN105677688A (zh) * | 2014-11-21 | 2016-06-15 | 博雅网络游戏开发(深圳)有限公司 | 页面数据加载方法和系统 |
CN106156148A (zh) * | 2015-04-14 | 2016-11-23 | 腾讯科技(深圳)有限公司 | 一种页面的渲染方法、装置和终端设备 |
CN106991096A (zh) * | 2016-01-21 | 2017-07-28 | 阿里巴巴集团控股有限公司 | 动态页面渲染方法及装置 |
CN105824874A (zh) * | 2016-02-01 | 2016-08-03 | 乐视移动智能信息技术(北京)有限公司 | 移动终端及其网页渲染方法、装置 |
Also Published As
Publication number | Publication date |
---|---|
CN107743266A (zh) | 2018-02-27 |
CN107743266B (zh) | 2020-01-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN106713485B (zh) | 云计算移动终端 | |
US7937452B2 (en) | Framework for rendering plug-ins in remote access services | |
CN109343902B (zh) | 音频处理组件的运行方法、装置、终端及存储介质 | |
US20150149933A1 (en) | User interface widget unit sharing for application user interface distribution | |
JP7100154B6 (ja) | プロセッサコアのスケジューリング方法、装置、端末及び記憶媒体 | |
US10616366B2 (en) | Message transmission method and device | |
US20080267067A1 (en) | Controlling the flow of data updates between a receiving station and a sending station | |
WO2022193595A1 (zh) | 对象播放方法及装置 | |
CA2557111A1 (en) | System and method for building mixed mode execution environment for component applications | |
CN102668495A (zh) | 低延时传输协议的方法和系统 | |
CN102298491B (zh) | 嵌入式图形界面系统及其图像生成方法 | |
WO2015117445A1 (zh) | 任务窗口的处理方法及装置 | |
CN104935443A (zh) | 组播数据处理方法、装置、系统、发送设备及接收客户端 | |
WO2023040825A1 (zh) | 媒体信息的传输方法、计算设备及存储介质 | |
CN111078348B (zh) | 一种界面管理方法、装置、设备和存储介质 | |
US9614900B1 (en) | Multi-process architecture for a split browser | |
CN105706441A (zh) | 针对通信会话中的内容共享的自适应采样周期 | |
CN113992949B (zh) | 混流服务切换方法及其装置、设备、介质、产品 | |
KR20170107667A (ko) | 원격화면 전송 방법 및 원격화면 전송 시스템 | |
WO2019056645A1 (zh) | 视图切换 | |
WO2024061308A1 (zh) | 通知处理方法、终端设备、服务端及计算机存储介质 | |
WO2019071830A1 (zh) | Flash与JS页面的高效渲染通讯方法、存储介质、设备及系统 | |
US20230336494A1 (en) | Data processing method and apparatuses, devices, computer-readable storage medium, and computer program product | |
CN107251527A (zh) | 共享的场景对象同步 | |
CN108377243B (zh) | 一种直播流的传输方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 17928632 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 17928632 Country of ref document: EP Kind code of ref document: A1 |