A multi-source stock market data processing method and device for a stock market terminal

Abstract

The application discloses a kind of securities market terminal-oriented multi-source market data processing method, comprising the following steps: S1, multi-source market data acquisition step: S2, multi-source market data hierarchical identification step;S3, market data hierarchical description structure generation step;S4, incremental update data packet generation step;S5, incremental update data packet analysis restoration and cache step;S6, change data page area mapping and local refresh step;S7, rendering task dynamic scheduling step.The application also discloses a kind of securities market terminal-oriented multi-source market data processing device.The application reduces the analysis pressure of terminal to invalid data, improves the processing efficiency of securities market data on terminal side, and can be widely applied in securities market data processing and terminal display control technical field.

Description

Technical Field

[0001] This invention relates to the field of securities market data processing and terminal display control technology, and in particular to a method and apparatus for processing multi-source market data for securities market terminals. Background Technology

[0002] With the digitalization and mobilization of securities trading, securities market data terminals have become essential tools for investors to view market information, analyze trends, and make trading decisions. Securities market data terminals typically include securities trading apps, securities market analysis clients, financial information terminals, and stock trading software, all of which need to display real-time market data for multiple securities on the terminal interface.

[0003] In existing technologies, securities market data terminals typically acquire multi-source market data from market data servers, trading servers, information servers, or other financial data services, and display it on the corresponding market data page. This multi-source market data typically includes basic market data, order book data, intraday chart data, candlestick chart data, tick-by-tick transaction data, technical indicator data, fund flow data, news announcements data, and risk event data, etc.

[0004] Taking a stock quote page on a securities trading app as an example, the page typically consists of multiple quote modules. The top of the page displays basic quote information such as the security name, security code, latest price, price change, and trading volume; the middle of the page displays a time-sharing chart or candlestick chart; and the bottom of the page displays modules such as order book data, tick-by-tick transactions, fund flows, news announcements, financial data, and technical indicators. The data for different modules can be provided by different interfaces or services. After receiving the data, the terminal renders it onto the corresponding interface area according to the preset page structure.

[0005] Current securities market data terminals typically use interface data or page modules as the basic processing unit. When an interface returns new market data, the terminal parses the data corresponding to that interface and updates the corresponding page module. When multiple modules receive updated data simultaneously, the terminal may continuously refresh multiple page areas within a short period of time.

[0006] Due to the limited screen size of mobile devices, stock market information pages are typically long pages or multi-tab pages. Users can usually only see a portion of the page at a time, such as the price area, intraday chart area, candlestick chart area, or order book area, while other modules may be located off-screen or require switching tabs to view.

[0007] Securities market data is characterized by high-frequency changes, multi-source heterogeneity, and high real-time requirements. Different types of data differ in refresh frequency, data volume, computational complexity, transmission cost, and display priority. For example, the latest price, price change, order book, and tick-by-tick data change frequently; candlestick charts, technical indicators, and fund flow statistics involve time series processing or indicator calculations; and data such as price limits, trading halts, abnormal fluctuations, major announcements, and risk warnings are event-triggered data.

[0008] Existing securities market terminals are capable of requesting, parsing, and displaying various types of market data. However, their technical implementation typically uses interfaces or page modules as the basic processing units, lacking a unified hierarchical description, incremental update, cache control, and rendering scheduling mechanism for multi-source market data.

[0009] Therefore, it can be seen that existing securities market data terminals have at least the following problems when processing and displaying multi-source market data: Multi-source market data lacks a unified hierarchical processing mechanism.

[0010] Current securities market data terminals typically request and process market data according to page modules or interface types. While basic market data, order book data, tick-by-tick transactions, intraday charts, candlestick charts, technical indicators, fund flows, and risk events all belong to the market data page, their refresh frequencies, real-time requirements, computational complexity, and display priorities differ. Without unified layered processing, high-real-time data, computationally intensive data, and low-frequency cached data are easily mixed and processed, increasing the terminal's parsing and refresh burden. If the terminal only processes data according to interfaces or page modules without unified layered descriptions and priority distinctions for different types of market data, it becomes difficult to adopt differentiated processing strategies based on data characteristics. This easily leads to the mixed processing of high-real-time data, computationally intensive data, and low-frequency cached data, increasing the terminal's data parsing and page refresh burden.

[0011] Market data is prone to duplicate transmission and parsing.

[0012] Securities market data changes frequently, but not all fields change within adjacent time slices. For example, only the latest price, a certain order book level, or the data point at the end of the intraday chart may change. If the existing solution returns and parses the data as a whole by interface or module, it will cause unchanged fields to be repeatedly transmitted and processed, increasing network traffic, CPU (Central Processing Unit) usage, memory usage, and parsing time.

[0013] Page refreshes tend to focus on refreshing the entire module, resulting in a lot of invalid rendering.

[0014] Current market data pages typically consist of multiple modules, including price, order book, intraday chart, candlestick chart, and tick-by-tick transaction area. When some fields in a module change, the terminal may trigger a refresh of the entire module or even multiple areas. Without field-level, region-level, or data-point-level local refresh mechanisms, a large amount of invalid rendering can occur, increasing the rendering load on the GPU (Graphics Processing Unit) and causing page stuttering, frame drops, or unsmooth scrolling.

[0015] Data processing and rendering scheduling were not fully integrated with the visible area of ​​the terminal page.

[0016] Mobile market data pages are limited by screen size, and typically only a portion is displayed at any given time. Existing solutions that continue parsing and rendering invisible modules waste resources. Furthermore, in scenarios with weak network conditions, low battery, high CPU / GPU load, or rapid page scrolling, processing all data using a fixed refresh strategy can easily lead to market data delays, chart stuttering, and unstable page display.

[0017] There is a lack of clear mapping and scheduling relationship between the UI (User Interface) page module and the underlying data processing.

[0018] Current market data pages are typically divided into modules such as price area, intraday chart area, candlestick chart area, order book area, transaction details area, and news announcement area from a product interface perspective. However, the underlying data processing often relies primarily on data returned by APIs, lacking a unified mapping relationship between data fields, data levels, and specific rendering areas. Therefore, when a certain data field changes, the terminal struggles to directly determine the minimum refresh area and perform fine-grained rendering scheduling. Summary of the Invention

[0019] The purpose of this invention is to overcome the shortcomings of the aforementioned background technology and provide a method and apparatus for processing multi-source market data for securities market terminals, thereby solving the problems of repeated transmission, repeated parsing, invalid rendering, high terminal resource consumption, and untimely updating of key market data that easily occur when existing securities market pages refresh multiple types of market data at high frequency.

[0020] This invention provides a method for processing multi-source market data for a securities market terminal, comprising the following steps: S1, acquiring multi-source market data of securities; S2, performing layered identification of the multi-source market data based on the data's real-time nature, change frequency, computational complexity, event attributes, and page display area; S3, generating a layered description structure of market data based on the data layering results, wherein the layered description structure includes at least a securities identifier, a data level identifier, a data field identifier, a change identifier, a data timestamp, a priority identifier, a caching strategy identifier, and a rendering area identifier; S4, comparing the current time-slice market data with the previous time-slice market data, and generating incremental update data packets only for the changed data fields; S5, the securities market terminal receiving the incremental update data packets and parsing, restoring, and caching them according to the data level, refresh priority, and caching strategy; S6, the securities market terminal mapping the changed data to the corresponding area of ​​the market page according to the rendering area identifier, and performing a partial refresh of the corresponding area; S7, the securities market terminal dynamically scheduling the parsing order, refresh frequency, and rendering tasks of different data layers according to network status, terminal performance, page visible area, and the user's current operation status.

[0021] In the above technical solution, step S2 involves dividing the multi-source market data into a data layer consisting of a basic market data layer, an order book trading layer, a chart analysis layer, a risk event layer, and a historical cache layer.

[0022] In the above technical solution, in step S3, the market data hierarchical description structure further includes a data packet length for identifying the total length of the current incremental update data packet, and a data body for storing the market data field values ​​that actually need to be updated.

[0023] In the above technical solution, in step S3, the generation of the hierarchical description structure of market data is encoded using a variable-length binary protocol.

[0024] In the above technical solution, the specific process of step S4 is as follows: S41. Obtain multi-source market data for the current time slice; S42. Read the market data that has been sent, cached, or rendered in the previous time slice as the comparison object for the current time slice data; S43. Based on the security identifier, data level identifier, and data field identifier, perform field-level comparison between the current time slice market data and the previous time slice market data to determine the changes in each market field; S44. For fields of market data that have changed, identify the corresponding changed fields through a combination structure of field change bitmap, changed field set, or field number plus length value, and write the timestamp, refresh priority, rendering area identifier, and field value into the incremental update data packet; S45. When the system detects a risk event, generate a risk event layer incremental update data packet and set a higher refresh priority so that the terminal can prioritize parsing and rendering this type of event data; S46. According to the market data layer description structure, combine the changed fields and their corresponding data bodies into an incremental update data packet and send it to the securities market terminal. Based on the data level identifier, change identifier, and rendering area identifier of the incremental update data packet, perform parsing, caching, and partial refresh.

[0025] In the above technical solution, the specific process of step S5 is as follows: S51. After receiving the incremental update data packet, parse the total packet length, protocol version number, security identifier, data level identifier, field dictionary version number, field change bitmap, data timestamp, refresh priority identifier, caching strategy identifier, rendering area identifier, and data body length information in the data packet; S52. According to the security identifier, search for the corresponding security market data record in the local cache. If the corresponding cache already exists locally, write the incremental data to the corresponding cache position; if the corresponding cache does not exist locally, create a new data cache record for the security based on the current data packet; S53. Determine the parsing order according to the data level identifier and refresh priority identifier, and prioritize parsing key fields in the basic market data layer and order book trading layer, as well as risk events. For component-level data; for chart analysis layer and historical cache layer data, delayed parsing or on-demand parsing is performed based on page visibility, terminal performance, and caching strategy; S54, only updated data fields that have changed are updated. For unchanged fields, the original data in the local cache is retained without repeated parsing or overwriting. For time series data, new data points or new records are written to the corresponding time series cache based on the data timestamp; S55, the terminal determines whether the current data can be cached, the cache validity period, and whether an expiration update is required based on the caching strategy identifier; S56, a set of data to be rendered is generated based on the rendering area identifier and sent to the changed data page area mapping and partial refresh module; the changed data page area mapping and partial refresh module generates the corresponding rendering task, which is then scheduled by the rendering task dynamic scheduling module.

[0026] In the above technical solution, step S5 parses and restores the data packet according to the binary encoding protocol. The specific steps are as follows: S51': Read the total length and data body length of the data packet to determine if the current data packet is complete; if the data packet length does not meet the header field or data body length requirements, discard the data packet or wait for subsequent data to complete; read the protocol version number and field dictionary version number to determine the applicable field dictionary, data level definition, and rendering area definition for the current data packet; if the terminal does not support the corresponding protocol version, downgrade according to the compatibility strategy or discard unrecognizable fields; S52': Parse the security target identifier and locate the corresponding security target data cache object in the local cache of the securities market terminal; if the corresponding cache object does not exist locally, then based on the current security target identifier and data level... Create a new cache object; S53', parse the data level identifier, refresh priority identifier, and cache policy identifier to determine the parsing queue, cache writing method, and subsequent rendering scheduling strategy for the current data packet; S54', parse the field change bitmap. For fields with a value of 0 in the field change bitmap, the terminal retains the original cached value and does not read the field value from the data body; read the field values ​​from the data body sequentially according to the order of fields with a value of 1 in the field change bitmap; directly read the preset length of fixed-length fields, and read the field length and field content sequentially when reading variable-length fields; for time-series data, determine the addition point, replacement point, or discard point based on the data timestamp; S55', for short-term overwrite cache, the terminal overwrites the previous cached value with the current field value; for time-series append cache, the terminal adds the time-division point, K... Line points or transaction records are inserted into the corresponding sequence positions; for long-term caches, the terminal determines whether to replace the original data based on the version number, timestamp, or expiration condition; S56' generates a rendering task based on the rendering area identifier and field set, including at least the security identifier, target rendering area, set of changed fields, refresh priority, and data timestamp; when multiple incremental update data packets arrive consecutively, the rendering tasks are merged according to the refresh priority and rendering area.

[0027] In the above technical solution, the specific process of step S6 is as follows: S61, determine the page area corresponding to the changed data according to the rendering area identifier; S62, determine whether the target page area is within the current visible range according to the page scroll position, tab status and module expansion status: if it is within the visible range, add the area to the rendering queue; if it is not within the visible range, only update the cache; S63, the terminal determines the rendering order according to the refresh priority, prioritizes rendering key fields in the basic market data layer and order book trading layer, as well as risk event data, and delays or merges the rendering of data with low real-time requirements or high computational load.

[0028] In the above technical solution, the specific process of step S7 is as follows: S71, adjust the rendering strategies of various data layers according to the current network status, CPU load, GPU load, memory usage, power status and user operation status; S72, only refresh the page area corresponding to the changed data; S73, for the page area that has not changed, the terminal maintains the original display state.

[0029] The present invention also provides a multi-source market data processing device for securities market terminals, which has a computer program that can execute a multi-source market data processing method for securities market terminals.

[0030] The present invention provides a multi-source market data processing method and apparatus for securities market terminals, which has the following advantages: This reduces redundant transmission and parsing of market data, improving data processing efficiency. By comparing the current time-slice market data with the previous time-slice data, incremental update data packets are generated only for changed market data fields or newly added records. Unchanged data fields are not repeatedly transmitted or parsed. This reduces redundant data transmission during high-frequency market data refresh, lowers the parsing pressure on the terminal for invalid data, and improves the processing efficiency of securities market data on the terminal side.

[0031] Reduce unnecessary page rendering and improve market data page refresh efficiency. By using rendering area identifiers, changed data is mapped to specific display areas on the stock market page, such as price areas, order book areas, intraday chart areas, candlestick chart areas, tick-by-tick transaction areas, and risk warning areas. After receiving incremental update data, the terminal only refreshes the page areas corresponding to the changed data, avoiding repeated rendering of the entire page or unchanged modules. This reduces unnecessary redrawing, lowers GPU rendering load, and improves the smoothness of market data page display in high-frequency refresh scenarios.

[0032] Improve the timeliness and stability of key market data display. Prioritize basic market data, key order book fields, and risk event data through data hierarchy and refresh priority indicators. For data with high real-time requirements, such as latest price, percentage change, bid / ask spread, price limits, trading halts, abnormal fluctuations, and risk warnings, the terminal can prioritize parsing, caching, and rendering. Especially when multiple data modules are updated simultaneously, this avoids excessive processing resources being consumed by computationally intensive chart data or low-frequency historical data, thereby improving the timeliness of key market data display.

[0033] Reduce terminal resource consumption and improve adaptability under weak network or low-performance device conditions. Dynamically schedule parsing and rendering tasks for different data layers based on terminal network status, CPU / GPU load, memory usage, battery status, visible page area, and user operation status. When the network is poor, terminal resources are scarce, the page scrolls rapidly, or the target module is invisible, the refresh frequency of low-priority data can be reduced, and some rendering tasks can be delayed or merged to prioritize the display of basic market data and risk event data. This reduces network, CPU, GPU, memory, and power consumption, improving the display stability of the securities market terminal under different device and network environments.

[0034] Enhance the ability to expand subsequent business operations and page modules. A hierarchical description structure for market data provides a unified description of securities, data levels, data fields, change states, caching strategies, and rendering areas. When new market data fields, data types, page modules, or display areas are added later, expansions can be based on the existing hierarchical description structure without completely changing the original data processing and rendering scheduling flow, thereby reducing the complexity of subsequent system modifications. Attached Figure Description

[0035] Figure 1 This is a flowchart illustrating the overall process of the multi-source market data processing method for securities market terminals according to the present invention. Figure 2 This is an overall flowchart of Embodiment 1 of the multi-source market data processing method for securities market terminals of the present invention. In the flowchart, steps S1-S7 correspond to the processing flow of the multi-source market data acquisition step, the multi-source market data layer identification step, the market data layer description structure generation step, the incremental update data packet generation step, the incremental update data packet parsing, restoration and caching step, the change data page area mapping and partial refresh step, and the rendering task dynamic scheduling step, respectively. In the flowchart, "supporting data" refers to the data foundation for the above steps, such as the previous time slice cache, field dictionary or historical cache, and does not represent independent method steps. Figure 3 This is a flowchart of the incremental update data packet generation process in step S4 of embodiment 1 of the multi-source market data processing method for securities market terminals of the present invention. Steps 1-6 in the figure correspond to the processes of obtaining multi-source market data of the current time slice, obtaining market cache data of the previous time slice, comparing by securities, data level and data field, writing the changed data field, setting refresh priority and outputting incremental update data packet. Figure 4This is a schematic diagram of the mapping and partial refresh relationship of the change data page area in steps S6-S7 of the multi-source market data processing method for securities market terminals of the present invention. It shows that the basic market change field 401, order book change field 402, chart data point 403, tick transaction record 404 and risk event field 405 are mapped to the price area 421, order book area 422, chart area 423, tick transaction area 424 and risk warning area 425 respectively through the change data page area mapping and partial refresh module 410, and the corresponding minimum refresh areas 431, 432, 433, 434 and 435 are partially refreshed. Figure 5 This is a schematic diagram of the layered description structure of market data in binary encoding in step S3' of the multi-source market data processing method for securities market terminals of the present invention. It shows that the incremental update data packet consists of a packet header 500 and a data body 513. The packet header 500 includes, in sequence, the total packet length 501, the protocol version number 502, the securities target identifier 503, the data level identifier 504, the field dictionary version number 505, the field change bitmap 506, the data timestamp 507, the refresh priority identifier 508, the caching strategy identifier 509, the rendering area identifier 510, the data body length 511, and the verification identifier 512. The data body 513 is used to store the corresponding field values ​​in the order of the fields with a value of 1 in the field change bitmap 506. Figure 6 This is a flowchart of step S5' in embodiment 2 of the multi-source market data processing method for securities market terminals of the present invention, which includes binary encoding parsing and restoration and caching, mapping of changed data page areas and partial refresh steps, and dynamic scheduling of rendering tasks. It shows the process of the terminal parsing packet header, identifying changed fields, writing to cache, determining visible areas, generating rendering tasks and performing partial refresh. Figure 7 This is a diagram showing the overall architecture of the multi-source market data processing device for securities market terminals according to the present invention. Figure 8 This is a schematic diagram of the multi-source market data processing device for securities market terminals according to the present invention, showing the connection relationship between the multi-source market data acquisition module, the multi-source market data hierarchical identification module, the market data hierarchical description structure generation module, the incremental update data packet generation module, the incremental update data packet parsing, restoration and caching module, the changed data page area mapping and partial refresh module, the rendering task dynamic scheduling module and the terminal status detection module. Detailed Implementation

[0036] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments, but these embodiments should not be construed as limiting the present invention.

[0037] Existing securities market data terminals typically need to simultaneously display multiple types of data, including basic market data, order book, intraday charts, candlestick charts, tick-by-tick transactions, technical indicators, fund flows, news announcements, and risk events. These different data types vary in their real-time nature, frequency of change, computational complexity, and page display area. If they are still refreshed uniformly according to interfaces or page modules, it can easily create processing and rendering pressure on the terminal.

[0038] This invention performs layered identification, encoding description, and incremental updates of multi-source market data, and schedules the data based on the rendering area of ​​the terminal page. This allows the terminal to process and refresh only the data that has changed and its corresponding area, thereby reducing the processing of invalid data and improving the refresh efficiency and display stability of the market data page.

[0039] Example 1 This embodiment uses multi-source market data from a securities market terminal as the processing object. The multi-source market data includes basic market data, order book data, intraday chart data, candlestick chart data, tick-by-tick transaction data, technical indicator data, capital flow data, news announcement data, and risk event data.

[0040] See Figures 1 to 2 The multi-source market data processing method for securities market terminals in this embodiment mainly includes the following steps: S1. Steps for obtaining multi-source market data: Obtain multi-source market data for the securities; S2. Multi-source market data layer identification steps: Based on the data's real-time nature, change frequency, computational complexity, event attributes, and page display area, multi-source market data is layered and identified. S3. Steps for generating a hierarchical description structure for market data: Based on the data hierarchical results, generate a hierarchical description structure for market data. The hierarchical description structure for market data includes at least a security identifier, a data level identifier, a data field identifier, a change identifier, a timestamp, a refresh priority, a caching strategy identifier, and a rendering area identifier. S4. Incremental update data packet generation steps: Compare the current time slice market data with the previous time slice market data, and generate incremental update data packets only for the data fields that have changed; S5. Incremental Update Data Packet Parsing, Restoration, and Caching Steps: After receiving the incremental update data packet, the securities market terminal parses, restores, and caches it according to the data level, refresh priority, and caching strategy. S6. Change data page area mapping and partial refresh steps: The securities market terminal maps the change data to the corresponding area of ​​the market page according to the rendering area identifier, and performs a partial refresh on the corresponding area. S7. Dynamic scheduling steps for rendering tasks: The securities market terminal dynamically schedules the parsing order, refresh frequency, and rendering tasks of different data layers based on network status, terminal performance, visible page area, and the user's current operation status.

[0041] The following sections provide detailed explanations of the steps for acquiring multi-source market data, identifying multi-source market data layers, generating a layered description structure for market data, generating incremental update data packets, parsing, restoring, and caching incremental update data packets, mapping and partially refreshing changed data page areas, and dynamically scheduling rendering tasks.

[0042] Through the above steps, this embodiment can form a processing mechanism of "multi-source market data acquisition step - multi-source market data layer identification step - market data layer description structure generation step - incremental update data packet generation step - incremental update data packet parsing, restoration and caching step - change data page area mapping and partial refresh step - rendering task dynamic scheduling step", which enables the market terminal to prioritize the display of key market data in high-frequency data refresh scenarios and reduce repeated transmission, repeated parsing and full page redrawing.

[0043] S1. Steps for obtaining multi-source market data In the multi-source market data acquisition step, the system acquires multi-source market data of the securities and uses the multi-source market data as input for the subsequent multi-source market data hierarchical identification step.

[0044] The multi-source market data can come from securities market servers, exchange market data sources, intermediate gateways, terminal local caches, or historical market databases, and includes at least one or more of the following: basic market data, order book trading data, chart analysis data, risk event data, and historical cache data.

[0045] During the acquisition process, the system can aggregate multi-source market data according to the security identifier, data source, data timestamp, and data type, enabling subsequent steps to perform hierarchical identification, incremental updates, and rendering scheduling based on the same security and the same time slice.

[0046] S2. Steps for Layered Identification of Multi-Source Market Data In the multi-source market data layering identification step, this embodiment divides the multi-source market data into the following data layers based on the real-time nature, frequency of change, computational complexity, caching requirements, and page display area of ​​the securities market data: (1) Basic market data layer The basic market data layer includes information such as security name, security code, latest price, price change, percentage change, trading volume, trading value, opening price, highest price, lowest price, and previous closing price. This layer of data typically corresponds to the price area at the top of the market data page and has high real-time requirements, making it suitable for priority parsing and incremental field-level refresh.

[0047] (2) Order book trading layer The order book trading layer includes data such as bid and ask prices, five-level order book, ten-level order book, individual transaction time, transaction price, transaction volume, and transaction direction. This layer of data changes frequently and typically corresponds to the order book area and individual transaction area, making it suitable for incremental updates at the level of order book level or record level.

[0048] (3) Chart Analysis Layer The chart analysis layer includes data such as intraday charts, candlestick charts, moving averages, MACD, KDJ, RSI, and volume bars. This layer typically involves time series processing or indicator calculations, resulting in relatively high computational complexity. It can be parsed, partially updated, or rendered with delays based on the visible area of ​​the page and the user's interaction status.

[0049] (4) Risk event layer The risk event layer includes event-based data such as price limits (up or down), trading suspensions, resumption of trading, abnormal fluctuations, major announcements, and risk warnings. This layer of data is typically triggered by events and requires high real-time display. After triggering, a higher refresh priority can be set, and the data will be rendered first in the risk warning or status indicator area.

[0050] (5) Historical caching layer The historical cache layer includes historical candlestick charts, historical transaction data, historical technical indicators, historical fund flows, financial data, and basic information. This layer has a low data change frequency and a relatively large data volume, making it suitable for processing using local caching, segmented loading, or on-demand request methods.

[0051] Through the above-described layering approach, this embodiment can determine the encoding method, update frequency, caching strategy, parsing priority, and rendering area of ​​different data layers according to their characteristics, thereby supporting the securities market terminal to perform more refined data processing and page refresh control.

[0052] S3. Steps for generating a hierarchical description structure for market data In the step of generating the hierarchical description structure for market data, the hierarchical description structure for market data is used to uniformly describe the market data in the incremental update data packet, so that the securities market terminal can determine the securities target, data level, changed fields, refresh priority, caching strategy and page rendering area corresponding to the current data packet according to the description structure after receiving the data packet.

[0053] The hierarchical description structure of market data can be set in the header of the incremental update data packet, while the main body of the data packet stores the actual changed market data field values. After receiving the incremental update data packet, the terminal first parses the hierarchical description structure of market data, then parses the main body of the data packet according to the field information in the description structure, and writes the parsed data to the corresponding cache area or maps it to the corresponding page area for partial refresh.

[0054] The hierarchical description structure of the market data includes at least the following components: Data packet length The data packet length is used to identify the total length of the current incremental update data packet, which helps the securities market terminal determine the boundaries of the current data packet and verify its integrity. The data packet length can be represented by a fixed-length field or a variable-length field, depending on the actual transmission protocol.

[0055] Securities Identifier The security identifier is used to identify the security product corresponding to the current data packet. The security identifier may include a market identifier and a security code. For example, the market identifier is used to distinguish between the Shanghai Stock Exchange, Shenzhen Stock Exchange, Beijing Stock Exchange, Hong Kong Stock Exchange, US Stock Exchange, or other trading markets, while the security code is used to identify the specific security product.

[0056] By identifying the security, the terminal can match the current data packet with the corresponding security data record in the local cache and determine which security's market data page or watchlist item the data packet should update.

[0057] Data hierarchy identifier The data level identifier is used to identify the data level to which the market data contained in the current data packet belongs. The data level may include the basic market data layer, the order book trading layer, the chart analysis layer, the risk event layer, and the historical cache layer.

[0058] For example, the basic market data layer corresponds to basic fields such as the latest price, price change, and trading volume; the order book trading layer corresponds to five-level order book, ten-level order book, and tick-by-tick transaction data; the chart analysis layer corresponds to intraday charts, candlestick charts, and technical indicator data; the risk event layer corresponds to event data such as limit up, limit down, trading suspension, abnormal fluctuations, major announcements, and risk warnings; and the historical cache layer corresponds to historical candlestick charts, historical trading volume, historical indicators, or financial data.

[0059] The terminal determines the parsing priority, caching method, and rendering strategy of the current data packet based on the data layer identifier.

[0060] Data field identifier Data field identifiers are used to identify the specific market data fields contained in the current data packet. Different data layers can correspond to different sets of data fields.

[0061] For example, the data field identifiers in the basic market data layer can correspond to fields such as latest price, change, percentage change, trading volume, turnover, opening price, highest price, lowest price, and previous closing price; the data field identifiers in the order book trading layer can correspond to fields such as bid price, bid volume, ask price, ask volume, five-level order book, ten-level order book, and tick-by-tick transaction records; the data field identifiers in the chart analysis layer can correspond to fields such as intraday points, candlestick points, moving averages, MACD, KDJ, and RSI.

[0062] By using data field identifiers, the terminal can determine which fields are contained in the data packet body and write the field values ​​into the corresponding data structure or page area.

[0063] Change indicator The change flag is used to indicate whether the current data field has changed relative to the previous time slice or the previous cache state. For fields that have not changed, they may not be written to the data packet body, or only the unchanged flag may be written; for fields that have changed, the corresponding field value or the changed value is written to the data packet body.

[0064] For example, when only the latest price and percentage change of a security change, the change identifier only marks the change in the latest price and percentage change fields; other fields are not transmitted again. The terminal only parses and refreshes the changed fields based on the change identifier.

[0065] Data timestamp Data timestamps are used to identify the current market data's corresponding market time or generation time. For high-frequency market data, data timestamps can be used to determine the order of data, preventing terminals from overwriting new data with expired data due to network latency, out-of-order arrival, or other reasons.

[0066] For time series data such as intraday charts, candlestick charts, and tick-by-tick transactions, data timestamps can also be used to determine the insertion position of new data points or transaction records in the time series.

[0067] Refresh priority flag The refresh priority flag indicates the terminal's priority in parsing and rendering the current data packet. Different data layers and different fields can correspond to different priorities.

[0068] For example, risk event layer data can be set to the highest priority; the latest price, percentage change, best bid price, and best ask price in the basic market data layer can be set to a higher priority; and historical candlestick charts, technical indicators, and capital flow statistics in the chart analysis layer can be set to a lower priority.

[0069] The terminal determines the parsing and rendering order of different data packets based on the refresh priority identifier. When terminal resources are insufficient, network conditions are poor, or multiple data packets arrive simultaneously, the terminal prioritizes processing high-priority data packets.

[0070] Cache policy identifier The caching policy identifier indicates whether the current data can be cached, the cache validity period, the cache version, or the cache expiration condition. Different data layers can use different caching policies.

[0071] For example, data in the basic market data layer and order book trading layer changes rapidly and has a short cache validity period; historical candlestick data in the chart analysis layer can be reused within a certain period; financial data and basic information data in the historical cache layer can have a longer cache validity period; and data in the risk event layer can become invalid after the event is resolved or the server returns an updated status.

[0072] The terminal determines whether to read the local cache, overwrite the existing cache, request data again, and trigger a page refresh based on the caching policy identifier.

[0073] Rendering area identifier The rendering area identifier is used to identify the specific display area on the securities market page corresponding to the current data. The display area may include the price area, order book area, intraday chart area, candlestick chart area, tick-by-tick transaction area, risk warning area, and information announcement area, etc.

[0074] For example, basic market data can correspond to price ranges; order book data can correspond to order book areas and tick-by-tick transaction areas; chart analysis data can correspond to intraday chart areas, candlestick chart areas, and technical indicator areas; risk event data can correspond to risk warning areas or top status warning areas; and historical cache data can correspond to historical chart areas, financial data areas, or basic information areas.

[0075] By using rendering area identifiers, the terminal can directly map changed data to the corresponding page area and only refresh that area, avoiding full page redrawing or refreshing irrelevant modules.

[0076] Data body The data body stores the field values ​​of the market data that actually need to be updated. The field content in the data body corresponds to the data field identifier and change identifier. For fields that have not changed, the data body may not contain the field value; for fields that have changed, the data body stores the current value, the changed value, or the newly added data record for that field.

[0077] For example, when only the latest price changes in the basic market data layer, the data body only stores the latest price field value; when the buy price and buy volume change in the order book trading layer, the data body only stores the buy price and buy volume; when a new time point is added to the intraday chart, the data body only stores the newly added intraday time point; when a risk event is triggered, the data body stores information such as event type, event status, and event time.

[0078] In one implementation, the hierarchical description structure of the market data can be composed of the following fields in order: Data packet length, security identifier, data level identifier, data field identifier, change identifier, data timestamp, refresh priority identifier, caching strategy identifier, rendering area identifier, and data body.

[0079] S4. Steps for generating incremental update data packets In the incremental update data packet generation step, the incremental update data packet is used to reduce the repeated transmission and parsing of securities market data during high-frequency refresh. The system does not send all market data fields in each refresh cycle; instead, it compares the market data of the current time slice with the market data of the previous time slice, generating incremental update data packets only for the data fields that have changed.

[0080] The incremental update data packet generation step includes the following steps, such as... Figure 3 As shown: Step 1: Obtain multi-source market data for the current time slice.

[0081] The system obtains securities market data for the current time slice from market data servers, trading servers, information servers, or other financial data services. The securities market data includes one or more of the following: basic market data, order book trading data, chart analysis data, risk event data, and historical cache data.

[0082] Step 2: Obtain the market data cache from the previous time slice.

[0083] The system reads market data that has been sent, cached, or rendered in the previous time slice and uses it as the comparison object for the current time slice data. The market data cached in the previous time slice can be stored in the server cache, the terminal local cache, or the intermediate data processing module.

[0084] Step 3: Compare data by security, data level, and data field.

[0085] The system compares the current time-slice market data with the previous time-slice market data based on the security identifier, data level identifier, and data field identifier to determine whether each market data field has changed.

[0086] For example, the basic market data layer can compare fields such as the latest price, price change, and trading volume; the order book layer can compare prices and quantities at various levels of the buy and sell orders; the chart analysis layer can compare newly added data points or current candlestick data in the intraday chart; and the risk event layer can compare whether new or deactivated risk events have been added.

[0087] Step 4: Write the data fields that have changed.

[0088] For market data fields that have changed, the system identifies the corresponding changed fields using a field change bitmap, a set of changed fields, or a combination of field number and length value, and writes the timestamp, refresh priority, rendering area identifier, and field value into the incremental update data packet. For fields that have not changed, the system either does not write the corresponding field value into the data body, or only retains the unchanged state in the packet header change identifier. In the implementation using a field change bitmap, the data body arranges the field values ​​of the changed fields in dictionary order.

[0089] Step 5: Set a higher priority for event-type data.

[0090] When the system detects risk events such as limit up, limit down, suspension of trading, resumption of trading, abnormal fluctuations, major announcements, and risk warnings, it generates incremental update data packets for the risk event layer and sets a higher refresh priority so that the terminal can prioritize parsing and rendering such event data.

[0091] Step 6: Output the incremental update data packet.

[0092] The system describes market data in a hierarchical structure, combining changed fields and their corresponding data volumes into incremental update data packets, which are then sent to the securities market terminal. Upon receiving the data packet, the terminal parses, caches, and partially refreshes it based on the data level, change identifier, and rendering area identifier.

[0093] By taking the above steps, only the data fields that have changed are transmitted and processed within adjacent refresh cycles. This reduces the repeated transmission of unchanged market data fields, lowers the terminal's parsing pressure, and provides a data foundation for subsequent partial rendering of the page.

[0094] S5. Incremental Update Data Packet Parsing, Restoration, and Caching Steps In the incremental update data packet parsing, restoration, and caching steps, after receiving the incremental update data packet, the securities market terminal performs parsing, restoration, caching, and scheduling processing on the data according to the hierarchical description structure of the market data in the data packet.

[0095] The incremental update data packet parsing, restoration, and caching steps include the following steps: Step 1: Analyze the hierarchical description structure of market data.

[0096] After receiving the incremental update data packet, the securities market terminal first parses the data packet to obtain information such as the total packet length, protocol version number, securities target identifier, data level identifier, field dictionary version number, field change bitmap, data timestamp, refresh priority identifier, caching strategy identifier, rendering area identifier, and data body length.

[0097] Step 2: Match the local securities data cache.

[0098] The terminal searches for the corresponding market data record of a security in its local cache based on the security identifier. If the corresponding cache already exists locally, the incremental data is written to the corresponding cache location; if the corresponding cache does not exist locally, a new data cache record for that security is created based on the current data packet.

[0099] Step 3: Parse according to data level and priority.

[0100] The terminal determines the parsing order based on the data level identifier and refresh priority identifier. For key fields in the basic market data layer and order book trading layer, as well as data in the risk event layer, the terminal parses them first. For data in the chart analysis layer and historical cache layer, the terminal can perform delayed parsing or parsing on demand, depending on the page visibility, terminal performance, and caching strategy.

[0101] Step 4: Update the cache based on the change flag.

[0102] The terminal updates only the data fields that have changed based on the change identifier. For unchanged fields, the terminal retains the original data in the local cache without re-parsing or overwriting it. For time-series data such as intraday charts, candlestick charts, and tick-by-tick transactions, the terminal writes the new data points or records to the corresponding time-series cache based on the data timestamp.

[0103] Step 5: Determine the validity of the data based on the caching strategy.

[0104] The terminal determines whether the current data can be cached, the cache validity period, and whether it needs to be expired and updated based on the caching policy identifier. For low-frequency data such as historical candlestick charts, historical indicators, and financial data, the terminal can prioritize reusing local cache; for high real-time data such as basic market data, order book data, and risk events, the terminal can adopt a shorter cache validity period or a real-time overwrite strategy.

[0105] Step 6: Output the data to be rendered.

[0106] After the terminal completes parsing, restoration, and caching, it generates a set of data to be rendered based on the rendering region identifier and sends it to the changed data page region mapping and partial refresh module. The changed data page region mapping and partial refresh module generates corresponding rendering tasks, which are then scheduled by the rendering task dynamic scheduling module. The set of data to be rendered only includes data that has changed and requires updating the corresponding page region.

[0107] Through the above steps, the securities market terminal can only parse, restore, and cache the changed data fields after receiving the incremental update data packet, avoiding repeated processing of unchanged data, and providing a data foundation for subsequent steps of changing data page area mapping, partial refresh, and dynamic scheduling of rendering tasks.

[0108] S6~S7, Steps for mapping and partially refreshing changed data page areas, and steps for dynamically scheduling rendering tasks. In the steps of mapping and partially refreshing the changed data page area and dynamically scheduling the rendering task, after completing the parsing, restoration and caching of the incremental update data packet, the securities market terminal performs partial refresh and dynamic scheduling of the rendering task on the market page according to the rendering area identifier, refresh priority, page visibility status and terminal running status.

[0109] The steps of mapping and partially refreshing the changed data page area and dynamically scheduling the rendering task include the following steps: Figure 4 As shown: Step 1: The terminal determines the page area corresponding to the changed data based on the rendering area identifier. The page area includes the price area, order book area, intraday chart area, candlestick chart area, tick-by-tick transaction area, risk warning area, and information announcement area, etc. Figure 4 In the embodiment shown, the basic market change field 401, order book change field 402, chart data point 403, tick transaction record 404, and risk event field 405 are mapped to the price area 421, order book area 422, chart area 423, tick transaction area 424, and risk warning area 425 respectively through the change data page area mapping and partial refresh module 410.

[0110] Step 2: The terminal determines whether the target page area is within the current visible range based on the page scroll position, tab status, and module expansion status. If it is within the visible range, the area is added to the rendering queue; if it is not within the visible range, only the cache needs to be updated, and rendering is not performed immediately.

[0111] Step 3: The terminal determines the rendering order based on refresh priority. Key fields in the basic market data layer and order book trading layer, as well as data in the risk event layer, are rendered first; data with lower real-time requirements or higher computational demands, such as data in the chart analysis layer and historical cache layer, can be rendered later or merged.

[0112] Step 4: The terminal adjusts the rendering strategy for different data layers based on the current network status, CPU load, GPU load, memory usage, battery status, and user operation status. For example, when the network status is poor or the terminal resource usage is high, the refresh frequency of the chart analysis layer and the historical cache layer is reduced, while priority is given to ensuring the display of the basic market data layer and the risk event layer.

[0113] Step 5: The terminal only refreshes the page area corresponding to the data that has changed. For example, when the latest price changes, the latest price field in the price area is refreshed; when the order book level changes, the corresponding order book level is refreshed; when a new data point is added to the intraday chart, only the new point is appended; when a new record is added to the tick-by-tick transaction, only the new record is inserted; when a risk event is triggered, the risk warning area is refreshed first. Specifically, the minimum refresh area 431 is the location of the changed field in the price area 421, the minimum refresh area 432 is the changed order book level in the order book area 422, the minimum refresh area 433 is the newly added or replaced data point in the chart area 423, the minimum refresh area 434 is the new record in the tick-by-tick transaction area 424, and the minimum refresh area 435 is the changed warning content in the risk warning area 425.

[0114] Step 6: For page areas that have not changed, the terminal maintains the original display state and does not perform repeated rendering.

[0115] Through the above steps, the securities market terminal can perform fine-grained rendering scheduling of the market page based on changes in market data, page visibility, and terminal operation status, reducing full-page redraws and invalid rendering, and improving the stability of page display in high-frequency market refresh scenarios.

[0116] Example 2 This embodiment is basically the same as Embodiment 1, except that: S3', Binary Encoding Protocol for Hierarchical Description Structure of Market Data In another implementation, the hierarchical description structure of the market data can employ binary encoding, key-value pair encoding, or other structured encoding methods, depending on the actual transmission protocol. Regardless of the encoding method used, the terminal should be able to perform data hierarchy determination, change field identification, caching strategy determination, and page rendering area positioning based on the description structure.

[0117] To ensure that the hierarchical description structure of the market data can be stably parsed by the securities market terminal, this embodiment employs a variable-length binary protocol to encode the incremental update data packets of the hierarchical description structure of the market data in one implementation. The incremental update data packet includes two parts: a header 500 and a data body 513. The header 500 is used to describe the security, data level, changed fields, priority, caching strategy, and rendering area, while the data body 513 is used to store the changed field values ​​or newly added data points.

[0118] The packet header 500 includes the following fields in sequence: total packet length 501, protocol version number 502, security identifier 503, data level identifier 504, field dictionary version number 505, field change bitmap 506, data timestamp 507, refresh priority identifier 508, caching strategy identifier 509, rendering area identifier 510, data body length 511, and verification identifier 512. Figure 5 As shown; data body 513 is located after header 500.

[0119] Total packet length 501: This occupies 32 bits and is used to represent the total byte length of the current incremental update data packet. The terminal can use this to determine the packet boundary and perform integrity verification.

[0120] Protocol version number 502: This occupies 8 bits and is used to distinguish different versions of the market data layering encoding protocol. When adding new data layers, field dictionaries, or rendering areas later, the protocol version number can be used to maintain compatibility.

[0121] Security Identifier 503: In one implementation, it includes a market identifier and a security code identifier. The market identifier occupies 8 bits and is used to distinguish between the Shanghai Stock Exchange, Shenzhen Stock Exchange, Beijing Stock Exchange, Hong Kong Stock Exchange, US Stock Exchange, or other markets; the security code identifier occupies 32 bits and is used to represent the mapped internal code of the security.

[0122] Data layer identifier 504: Occupies 8 bits and is used to identify the data layer to which the current data packet belongs. For example, 00000001 represents the basic market data layer, 00000010 represents the order book trading layer, 00000011 represents the chart analysis layer, 00000100 represents the risk event layer, 00000101 represents the historical cache layer, and other values ​​can be reserved for extended layers.

[0123] Field dictionary version number 505: Occupies 8 bits and is used to identify the field dictionary version used in the current data packet. Different data layers correspond to different field dictionaries. The fields in the field dictionary are arranged in a fixed order. The position and meaning of existing fields remain unchanged, and newly added fields are appended to the end of the dictionary.

[0124] Field Change Bitmap 506: The length varies with the length of the field dictionary, and each bit corresponds one-to-one with a field in the current data layer's field dictionary. A bit of 0 indicates that the corresponding field has not changed and the data body does not carry the field value; a bit of 1 indicates that the corresponding field has changed or been added, and the data body carries the corresponding field value in the order of the field dictionary.

[0125] Data timestamp 507: Occupies a 64-bit binary number and is used to represent the time when market data was generated or the market data time. The terminal can use the data timestamp to determine out-of-order data, expired data, and the position of intraday points, candlestick points, or individual transaction records in the time series cache.

[0126] Refresh Priority Flag 508: Occupies 8 bits and is used to represent the parsing and rendering priority of data packets. The smaller the value, the higher the priority; for example, the risk event layer can be set to 01, the key fields of the basic market data layer can be set to 02, the order book trading layer can be set to 03, and the chart analysis layer and the historical cache layer can be set to lower priority.

[0127] Caching policy identifier 509: Occupies an 8-bit binary number and is used to represent the caching policy for the current data packet. For example, 00 means no caching, 01 means short-term overwrite caching, 10 means time-series append caching, and 11 means long-term caching or version-based invalidation caching.

[0128] Rendering area identifier 510: Occupies a 16-bit binary number and is used to identify the page rendering area corresponding to the changing field. For example, 0001 represents the price area, 0002 represents the order book area, 0003 represents the intraday chart area, 0004 represents the candlestick chart area, 0005 represents the tick-by-tick transaction area, 0006 represents the risk warning area, and 0007 represents the information announcement area. Other values ​​can be reserved for page module expansion.

[0129] Data body length 511: This 32-bit binary number represents the byte length of the data body. The terminal can use this length to locate the start and end positions of the data body and parse the field values ​​sequentially in conjunction with the field change bitmap.

[0130] Checksum 512: Occupies a 16-bit or 32-bit binary number and is used to perform integrity checks on the packet header and data body to prevent the terminal from using incomplete or truncated data packets for cache overwriting and page refresh.

[0131] Data body 513 is arranged sequentially according to the fields with a value of 1 in the field change bitmap 506. For the basic market data layer, field values ​​may include the latest price, change, percentage change, trading volume, and turnover; for the order book trading layer, field values ​​may include the order book level number, buy / sell direction, price, and quantity; for the chart analysis layer, field values ​​may include time points, price points, volume points, and indicator values; for the risk event layer, field values ​​may include event type, event status, event trigger time, and prompt text identifier.

[0132] In a preferred embodiment, the fields of the basic market data layer and the order book trading layer use fixed-length numerical encoding to reduce parsing overhead; the chart analysis layer and the historical cache layer can use variable-length data segments to adapt to time series data of different lengths; the risk event layer can use a combination of event type encoding and event parameter encoding to quickly trigger a refresh of the page prompt area.

[0133] Through the aforementioned binary encoding protocol, the securities market terminal can, upon receiving an incremental update data packet, first determine the data level, changed fields, parsing order, caching strategy, and rendering area based on the packet header, and then parse the actual changed data based on the field change bitmap and data body length, thereby avoiding repeated parsing of unchanged fields.

[0134] It should be noted that, in the preferred binary implementation, the aforementioned data field identifiers and change identifiers can be represented jointly by the field dictionary version number and the field change bitmap. The terminal first determines the order and meaning of each field in the current data layer based on the field dictionary version number, and then determines which fields have changed based on the field change bitmap; therefore, the field dictionary version number and the field change bitmap constitute the specific encoding implementation of the data field identifiers and change identifiers.

[0135] Through the aforementioned hierarchical description structure of market data, this invention can establish a unified data description mechanism between market data transmission and terminal display, enabling the terminal to no longer process data solely according to the interface or page module as a whole, but to perform fine-grained parsing, caching, and local rendering based on data hierarchy, field changes, refresh priority, and rendering area.

[0136] S5' Incremental update data packet parsing and restoration and caching step binary encoding parsing and restoration In the incremental update data packet parsing, restoration, and caching step, after receiving the incremental update data packet, the securities market terminal parses and restores the data packet according to the binary encoding protocol. The parsing and restoration sub-step includes the following steps: Figure 6 As shown: Step 1: Read the total packet length and data body length to determine if the current data packet is complete. If the data packet length does not meet the requirements of the packet header field or the data body length, discard the data packet or wait for subsequent data to be completed.

[0137] Step 2: Read the protocol version number and field dictionary version number to determine the applicable field dictionary, data level definition, and rendering area definition for the current data packet; if the terminal does not support the corresponding protocol version, downgrade the processing according to the compatibility strategy or discard unrecognizable fields.

[0138] Step 3: Parse the security identifier and locate the corresponding security data cache object in the terminal's local cache; if the corresponding cache object does not exist locally, create a new cache object based on the current security identifier and data level.

[0139] Step 4: Parse the data level identifier, refresh priority identifier, and caching strategy identifier to determine the parsing queue, cache writing method, and subsequent rendering scheduling strategy for the current data packet.

[0140] Step 5: Parse the field change bitmap to obtain the set of fields that have changed in this data layer, according to the field dictionary order. For fields with a value of 0 in the field change bitmap, the terminal retains the original cached value and does not read the field value from the data body.

[0141] Step 6: Read the field values ​​from the data body sequentially according to the field order of values ​​of 1 in the field change bitmap. For fixed-length fields, the terminal reads directly according to the preset length; for variable-length fields, the terminal reads the field length first, and then reads the field content; for time series data, the terminal determines the addition point, replacement point, or discard point based on the data timestamp.

[0142] Step 7: Write to the cache according to the caching strategy identifier. For short-term overwrite cache, the terminal overwrites the previous cache value with the current field value; for time-series append cache, the terminal inserts the new intraday points, candlestick points, or transaction records into the corresponding sequence positions; for long-term cache, the terminal determines whether to replace the original data based on the version number, timestamp, or expiration condition.

[0143] Step 8: Generate a rendering task based on the rendering area identifier and field set. The rendering task should include at least the security identifier, target rendering area, set of changed fields, refresh priority, and data timestamp.

[0144] Step 9: When multiple incremental update data packets arrive consecutively, the terminal can merge the rendering tasks according to the refresh priority and the rendering area. For example, multiple basic market data fields of the same security can be merged to refresh the price area; multiple intraday points can be merged and appended to the intraday chart area; data in invisible areas can be written to the cache first and not rendered immediately.

[0145] Through the above parsing and restoration sub-steps, the terminal can restore the binary incremental update data packet into a cache update task and a partial page rendering task, and ensure that unchanged fields are not parsed repeatedly, invisible areas are not immediately redrawn, and key market information and risk events are displayed first.

[0146] Example 3 This embodiment further discloses the technical solution using a specific example of a certain time slice: Step 1: Execute the multi-source market data acquisition step. In a specific embodiment, the securities market terminal displays the individual stock market page of a certain security, which includes a top price area, an order book area, a time-sharing chart area, a tick-by-tick transaction area, and a risk warning area. The system acquires the basic market data and order book transaction data of the security in the current time slice, and reads the data snapshot sent in the previous time slice from the terminal's local cache or intermediate gateway.

[0147] Step 2: Perform the multi-source market data layered identification step and the market data layered description structure generation step. When a new time slice arrives, the system identifies the latest price and percentage change as basic market data, and the best bid price and best bid volume as order book trading data, and generates a field change bitmap based on the corresponding field dictionary. The system comparison found that only the latest price changed from 10.20 to 10.25, the percentage change changed from 1.49% to 1.98%, the best bid price changed from 10.19 to 10.24, and the best bid volume changed from 1200 lots to 1100 lots. The other fields did not change. Therefore, the bitmap positions corresponding to the changed fields were set to 1, and the positions corresponding to the unchanged fields remained 0.

[0148] Step 3: Execute the incremental update data packet generation step. The system can generate incremental update data packets for the basic market data layer and the order book trading layer separately, or it can send multiple incremental update data packets for the same data layer in the same batch. In the basic market data layer incremental update data packet, the header includes the security identifier, basic market data layer identifier, field dictionary version number, field change bitmap, data timestamp, higher refresh priority, short-term overwrite caching strategy, and price area rendering area identifier. The data body only carries the latest price and percentage change field values ​​in the order of the field dictionary. In the order book trading layer incremental update data packet, the header includes the order book trading layer identifier, the corresponding field change bitmap, and the order book area rendering area identifier. The data body only carries the buy-one price and buy-one quantity field values.

[0149] Step 4: Perform incremental update data packet parsing, restoration, and caching. After receiving the incremental update data packet, the terminal first determines the integrity of the data packet based on the total packet length and data body length, and then determines the field parsing rules based on the protocol version number and field dictionary version number. After reading the field change bitmap, the terminal only parses the latest price, price change, best bid price, and best bid volume from the data body, and writes the parsing results into the basic market data cache and order book cache of the security. For fields with a value of 0 in the field change bitmap, the terminal retains the cached value from the previous time slice.

[0150] Step 5: Perform the mapping and partial refresh of the changed data page area. Subsequently, the terminal generates two rendering tasks based on the rendering area identifier: a partial refresh task for the price area and a partial refresh task for the order book area. If the price area and order book area are currently within the visible range, the terminal prioritizes refreshing the display controls corresponding to the latest price, percentage change, best bid price, and best bid volume. If the order book area is currently not visible, the terminal can only update the order book cache and delay rendering, performing a merge refresh based on the latest cache once that area enters the visible range.

[0151] Step 6: Execute the dynamic scheduling step for rendering tasks. If the same time slice also contains newly added points or historical candlestick data on the intraday chart, and the intraday chart area is not within the visible range, or the terminal's CPU / GPU load is high, the dynamic scheduling module for rendering tasks can first write the chart analysis layer data into the time series cache and reduce its real-time rendering priority. Therefore, in high-frequency market data refresh scenarios, the terminal can prioritize the display of key prices and risk events, while reducing the parsing of unchanged fields, drawing of invisible areas, and full-page redrawing.

[0152] Example 4 This embodiment also provides a multi-source market data processing device for securities market terminals. The device can be deployed on a securities market server, a securities market terminal, or implemented by the server and the terminal in collaboration.

[0153] The multi-source market data processing device for securities market terminals includes the following modules, such as... Figures 7 to 8 As shown: Multi-source market data acquisition module: This is used to obtain multi-source market data for securities. The multi-source market data includes one or more of the following: basic market data, order book data, chart analysis data, risk event data, and historical cached data.

[0154] Multi-source market data layered identification module: This tool is used to identify the hierarchical structure of multi-source market data based on its real-time nature, frequency of change, computational complexity, event attributes, and page display area, thereby determining its data level.

[0155] Market data layered description structure generation module: This is used to generate a hierarchical description structure for market data based on the data hierarchical results. The hierarchical description structure for market data includes one or more of the following: security identifier, data level identifier, data field identifier, change identifier, field dictionary version number, field change bitmap, data timestamp, refresh priority identifier, caching strategy identifier, and rendering area identifier.

[0156] Incremental update data packet generation module: It is used to compare the market data of the current time slice with the market data of the previous time slice, identify the data fields that have changed, and generate incremental update data packets based on the changed fields.

[0157] Incremental update of data packet parsing, restoration, and caching module: This is used to parse the hierarchical description structure and data body of market data after receiving incremental update data packets in the securities market terminal, and write the changed data into the corresponding cache according to the data level, change identifier and caching strategy.

[0158] Module for mapping changed data page areas and partial refresh: It is used to perform partial refresh, delayed refresh, or merged refresh on the corresponding area of ​​the market data page based on the rendering area identifier, refresh priority, page visibility status, and terminal running status.

[0159] Rendering task dynamic scheduling module: It is used to dynamically schedule rendering tasks of different data layers based on refresh priority, page visibility status and terminal running status, including prioritizing key market data and risk events, and delaying or merging invisible areas or low-priority chart data.

[0160] Terminal status detection module: This system is used to detect the network status, CPU load, GPU load, memory usage, battery status, foreground / background status of the securities market terminal, the visible area of ​​the current page, and the user's operation status, and provides the detection results to the rendering task dynamic scheduling module.

[0161] Through the coordinated operation of the above modules, the device can achieve multi-source market data acquisition, multi-source market data hierarchical identification, generation of market data hierarchical description structure, generation of incremental update data packets, parsing, restoring and caching of incremental update data packets, mapping of changed data page areas and partial refresh, and dynamic scheduling of rendering tasks.

[0162] Technical principles and key technical features of this invention: Steps for acquiring multi-source market data: Acquire multi-source market data for securities and aggregate the multi-source market data according to securities identifier, data source, data timestamp, and data type.

[0163] Multi-source market data layering identification steps: The basic market data, order book trading, chart analysis, risk events and historical cache data in the securities market terminal are identified in layers, instead of being refreshed uniformly according to page modules.

[0164] The steps for generating a hierarchical description structure for market data are as follows: By using security identifiers, data level identifiers, field dictionary version numbers, field change bitmaps or field identifiers, refresh priority, caching strategies, and rendering area identifiers, a hierarchical description structure for market data packages is generated to provide a unified description of the market data packages.

[0165] Incremental update data packet generation steps: Compare the current time slice market data with the previous time slice data, and generate incremental update data packets only for data fields that have changed or newly added records.

[0166] Incremental update data packet parsing, restoration, and caching steps: The terminal parses and restores only the changed data fields based on the field change bitmap, data level identifier, refresh priority identifier, and caching policy identifier, and writes the changed data into the corresponding cache.

[0167] Steps for mapping and partially refreshing changed data page areas: By rendering area identifiers, the changed data is mapped to page areas such as price area, order book area, intraday chart area, candlestick chart area, tick-by-tick transaction area, and risk warning area, and the corresponding areas are partially refreshed.

[0168] Dynamic scheduling steps for rendering tasks: The terminal prioritizes, delays, or merges rendering tasks for different data layers based on refresh priority, page visibility, and running status.

[0169] Of course, this invention is not limited to the above-described embodiments. Without departing from the principles of multi-source market data hierarchical description, incremental updates, and rendering scheduling, the following technical solutions can also be adopted: First, in addition to binary encoding, the hierarchical description structure of market data can also use TLV encoding, Protocol Buffers encoding, FlatBuffers encoding, JSON key-value pair encoding, or other structured encoding methods. As long as the encoding method can carry the security identifier, data level identifier, field change identifier, refresh priority, caching strategy, and rendering area identifier, the technical effect of this invention can be achieved.

[0170] Second, the incremental comparison process can be executed on the market data server side, or on the terminal side, intermediate gateway side, or edge cache node. When executed on the server side, network transmission volume can be reduced; when executed on the terminal side, local cache on the terminal can be reused and the computational pressure on the server side can be reduced; when executed on the intermediate gateway side, incremental data of different granularities can be distributed according to the capabilities of different terminal devices.

[0171] Third, field change identifiers can adopt a combination of field bitmaps, lists of changed fields, field numbers plus length values, or event-driven structures. For data layers with a fixed number of fields, field bitmaps are preferred; for data layers with a large number of fields, lists of changed fields or TLV structures can be used.

[0172] Fourth, rendering scheduling strategies can employ fixed-priority queues, dynamic-weight queues, frame budget queues, or task queues integrated with the terminal UI framework lifecycle. The terminal can dynamically adjust the refresh rate of low-priority data layers based on CPU load, GPU load, memory usage, battery status, network status, and page visibility.

[0173] Fifth, the visible area of ​​a page can be determined based on scroll position, tab selection status, component mounting status, page foreground / background status, or user operation status. For invisible areas, the terminal can simply update the cache; when the area enters the visible range, a merge rendering is then performed based on the latest cache.

[0174] Sixth, this invention can be applied not only to individual stock quote pages, but also to watchlists, stock ranking lists, ETF / fund quotes, Hong Kong stock quotes, US stock quotes, futures quotes, or other financial quote terminal pages that require high-frequency refresh and partial rendering.

[0175] The key technical inspiration of this invention lies in: I. Steps for acquiring multi-source market data: This involves acquiring multi-source market data for securities from securities market servers, exchange market data sources, intermediate gateways, local caches on terminals, or historical market databases, and then using this data as input for subsequent hierarchical identification and incremental updates.

[0176] II. Multi-source market data layer identification steps: Based on real-time performance, frequency of change, computational complexity, event attributes, caching requirements, and page display area, basic market data, order book trading, chart analysis, risk events, and historical cache data are divided into different data layers, and differentiated encoding, caching, and rendering strategies are adopted for different data layers.

[0177] III. Steps for generating a hierarchical description structure for market data, especially generating a data package description structure that simultaneously includes security identifier, data level identifier, data field identifier, field dictionary version number, field change bitmap, data timestamp, refresh priority identifier, caching strategy identifier, and rendering area identifier.

[0178] IV. Steps for generating incremental update data packets based on bitmaps or sets of changed fields: This involves comparing the current time slice market data with the cached data from the previous time slice, and generating incremental update data packets only for fields, order book levels, transaction records, chart data points, or risk events that have changed.

[0179] Fifth, the incremental update data packet parsing, restoration, and caching steps involve the securities market terminal parsing and restoring only the changed data fields based on the hierarchical description structure of market data, field change bitmap, data level identifier, refresh priority identifier, and caching strategy identifier, and writing the changed data into the corresponding cache.

[0180] VI. The steps of mapping and partially refreshing the changed data page area are as follows: the changed data is directly mapped to the smallest refresh area such as the price area, order book area, intraday chart area, candlestick chart area, tick transaction area, and risk warning area through the rendering area identifier, and the smallest refresh area is partially refreshed.

[0181] VII. Dynamic scheduling steps for rendering tasks: The terminal side dynamically schedules rendering tasks based on refresh priority, page visibility status, and terminal running status. This includes prioritizing the rendering of key market data and risk events, and delaying or merging refresh tasks for invisible areas and low-priority chart data.

[0182] 8. A device structure consisting of a multi-source market data acquisition module, a multi-source market data hierarchical identification module, a market data hierarchical description structure generation module, an incremental update data packet generation module, an incremental update data packet parsing, restoration and caching module, a changed data page area mapping and partial refresh module, a rendering task dynamic scheduling module and a terminal status detection module, as well as a server, terminal or a collaborative system of the two.

[0183] In general, this invention is applicable to application scenarios such as securities trading apps, securities market analysis terminals, financial information terminals, and stock trading clients that require the display of real-time market data on the terminal interface. The data objects processed by this invention include multi-source market data such as basic market data of securities, order book trading data, intraday chart data, candlestick chart data, tick-by-tick transaction data, technical indicator data, capital flow data, and risk event data.

[0184] This invention improves the display stability and processing efficiency of securities market data in high-frequency data refresh scenarios by performing hierarchical description, incremental updates, cache control, and terminal rendering scheduling on the aforementioned multi-source market data. This is achieved by enabling securities market terminals to adopt different data processing and display refresh strategies for different types of market data based on the real-time nature, frequency of change, computational complexity, event attributes, and terminal page display status of the market data.

[0185] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

[0186] The contents not described in detail in this specification are existing technologies known to those skilled in the art.

Claims

1. A method for processing multi-source market data for securities market terminals, characterized in that: Includes the following steps: S1. Obtain multi-source market data for securities; S2. Based on the data's real-time nature, frequency of change, computational complexity, event attributes, and page display area, multi-source market data is hierarchically identified. S3. Based on the data layering results, generate a market data layering description structure, which includes at least a security identifier, a data level identifier, a data field identifier, a change identifier, a data timestamp, a priority identifier, a caching strategy identifier, and a rendering area identifier. S4. Compare the current time slice market data with the previous time slice market data, and generate incremental update data packets only for the data fields that have changed; S5. The securities market terminal receives incremental update data packets and parses, restores, and caches them according to data level, refresh priority, and caching strategy. S6. The securities market terminal maps the changed data to the corresponding area of ​​the market page according to the rendering area identifier, and performs partial refresh on the corresponding area. S7: The securities market terminal dynamically schedules the parsing order, refresh frequency, and rendering tasks of different data layers based on network status, terminal performance, visible page area, and the user's current operation status.

2. The multi-source market data processing method for securities market terminals according to claim 1, characterized in that: In step S2, the multi-source market data is divided into a data layer consisting of a basic market data layer, an order book trading layer, a chart analysis layer, a risk event layer, and a historical cache layer.

3. The multi-source market data processing method for securities market terminals according to claim 2, characterized in that: In step S3, the market data hierarchical description structure also includes a data packet length for identifying the total length of the current incremental update data packet, and a data body for storing the actual market data field values ​​that need to be updated.

4. The multi-source market data processing method for securities market terminals according to claim 3, characterized in that: In step S3, the hierarchical description structure of market data is generated using a variable-length binary protocol for encoding.

5. The multi-source market data processing method for securities market terminals according to claim 4, characterized in that: The specific process of step S4 is as follows: S41. Obtain multi-source market data for the current time slice; S42. Read the market data that has been sent, cached, or rendered in the previous time slice and use it as the comparison object for the current time slice data; S43. Based on the security identifier, data level identifier, and data field identifier, perform a field-level comparison between the current time slice market data and the previous time slice market data to determine the changes in each market data field. S44. For fields of market data that have changed, identify the corresponding changed fields by using a field change bitmap, a set of changed fields, or a combination of field number and length value, and write the timestamp, refresh priority, rendering area identifier, and field value into the incremental update data packet. S45. When the system detects a risk event, it generates an incremental update data packet for the risk event layer and sets a higher refresh priority so that the terminal can parse and render this type of event data first. S46. According to the hierarchical description structure of market data, the changed fields and their corresponding data bodies are combined into an incremental update data packet and sent to the securities market terminal. Based on the data level identifier, change identifier and rendering area identifier of the incremental update data packet, it is parsed, cached and partially refreshed.

6. The multi-source market data processing method for securities market terminals according to claim 5, characterized in that: The specific process of step S5 is as follows: S51. After receiving the incremental update data packet, parse the total packet length, protocol version number, security identifier, data level identifier, field dictionary version number, field change bitmap, data timestamp, refresh priority identifier, caching strategy identifier, rendering area identifier, and data body length information in the data packet. S52. Based on the security identifier, search for the corresponding security market data record in the local cache. If the corresponding cache already exists locally, write the incremental data to the corresponding cache location. If the corresponding cache does not exist locally, a new data cache record for the security will be created based on the current data packet. S53. Determine the parsing order based on the data level identifier and refresh priority identifier, prioritizing the parsing of key fields in the basic market data layer, order book trading layer, and risk event layer data; for chart analysis layer and historical cache layer data, perform delayed parsing or on-demand parsing based on page visibility, terminal performance, and caching strategy. S54. Only update the data fields that have changed. For fields that have not changed, retain the original data in the local cache and do not parse and overwrite them repeatedly. For time series data, write the new data points or new records to the corresponding time series cache according to the data timestamp. S55. The terminal determines whether the current data can be cached, the cache validity period, and whether it needs to be expired and updated based on the caching policy identifier. S56. Generate a set of data to be rendered based on the rendering region identifier and send it to the changed data page region mapping and partial refresh module; the changed data page region mapping and partial refresh module generates the corresponding task to be rendered and is scheduled by the rendering task dynamic scheduling module.

7. The multi-source market data processing method for securities market terminals according to claim 6, characterized in that: Step S5 involves parsing and restoring the data packet according to a binary encoding protocol. The specific steps are as follows: S51': Read the total length and data body length of the data packet to determine if the current data packet is complete; if the data packet length does not meet the requirements of the header field or data body length, discard the data packet or wait for subsequent data to be completed; read the protocol version number and field dictionary version number to determine the field dictionary, data level definition and rendering area definition applicable to the current data packet; if the terminal does not support the corresponding protocol version, downgrade the processing according to the compatibility strategy or discard unrecognized fields; S52' Parse the security identifier and locate the corresponding data cache object in the local cache of the securities market terminal; if the corresponding cache object does not exist locally, create a new cache object based on the current security identifier and data level; S53': Parse the data level identifier, refresh priority identifier, and cache strategy identifier to determine the parsing queue, cache writing method, and subsequent rendering scheduling strategy for the current data packet; S54': Parse the field change bitmap. For fields with a value of 0 in the field change bitmap, the terminal retains the original cached value and does not read the field value from the data body. Read field values ​​sequentially from the data body according to the field order of values ​​1 in the field change bitmap; read fixed-length fields directly by their preset length, and read variable-length fields sequentially by their length and content; for time series data, determine the addition point, replacement point, or discard point based on the data timestamp. S55' For short-term overwrite cache, the terminal overwrites the previous cache value with the current field value; for time-series append cache, the terminal inserts the new time-sharing point, candlestick point or transaction record into the corresponding sequence position; for long-term cache, the terminal determines whether to replace the original data based on the version number, timestamp or expiration condition. S56' Generate a rendering task based on the rendering region identifier and field set, including at least the security identifier, target rendering region, set of changed fields, refresh priority, and data timestamp; when multiple incremental update data packets arrive consecutively, merge the rendering tasks according to refresh priority and rendering region.

8. The multi-source market data processing method for securities market terminals according to claim 7, characterized in that: The specific process of step S6 is as follows: S61. Determine the page area corresponding to the changed data based on the rendering area identifier; S62. Based on the page scroll position, tab status, and module expansion status, determine whether the target page area is currently within the visible range: if it is within the visible range, add the area to the rendering queue; if it is not within the visible range, only update the cache. S63. The terminal determines the rendering order based on the refresh priority, prioritizing the rendering of key fields in the basic market data layer, the order book trading layer, and risk event data, while delaying or merging the rendering of data with lower real-time requirements or higher computational requirements.

9. The multi-source market data processing method for securities market terminals according to claim 8, characterized in that: The specific process of step S7 is as follows: S71. Adjust the rendering strategies of various data layers based on the current network status, CPU load, GPU load, memory usage, power status, and user operation status. S72. Only refresh the page area corresponding to the changed data; S73. For page areas that have not changed, the terminal maintains the original display state.

10. A multi-source market data processing device for a securities market terminal, comprising a computer program, characterized in that: The computer program is capable of executing the multi-source market data processing method for a securities market terminal as described in any one of claims 1 to 9.

Images