Menu display method, device, apparatus, and storage medium

Abstract

The application provides a menu display method and device, equipment and storage medium, wherein the method comprises: in the case of receiving a menu page request, obtaining menu data associated with the menu page request and current logged-in user information; performing feature extraction on the menu data and the user information to obtain menu feature information and user feature information; the menu feature information comprises the data size of each dish item and the dish type to which the dish item belongs; inputting the menu feature information and the user feature information into a pre-trained menu processing model to obtain the priority of the menu data and the total display time consumption; according to the priority of the menu data and the total display time consumption, filtering target data from the menu data; and performing a rendering operation according to the target data to display a corresponding menu page.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a menu display method, apparatus, device, and storage medium. Background Technology

[0002] With the rapid development of internet technology, the functions of web front-end applications are becoming increasingly complex, and the amount of data that pages need to carry and display is also increasing dramatically. However, in traditional web front-end development technologies, for scenarios displaying large amounts of data, such as thousands or even more records, full rendering is usually used. This causes the browser to perform a large number of page reflows and repaints when processing massive DOM nodes, which greatly consumes CPU and memory resources. Especially in scenarios with complex hierarchical structures and large amounts of data, such as menu data, this leads to a significant increase in page initialization loading time, resulting in noticeable delays in user interaction response, seriously affecting user experience. It can also cause a significant decrease in browser performance, or even browser crashes, making it difficult to meet the stability and smoothness requirements of web front-end applications under high concurrency and large data volumes. Summary of the Invention

[0003] In view of this, in order to at least solve the technical problem that the use of full rendering to display menu pages in related technologies leads to a significant decrease in browser performance, making it difficult to meet the stability and smoothness requirements of browsers under high concurrency or massive data, this application provides a menu display method, apparatus, device, and storage medium, and the technical solution adopted is as follows: According to a first aspect of the embodiments of this application, a menu display method is provided, including: Upon receiving a menu page request, retrieve the menu data associated with the menu page request and the currently logged-in user information; the menu data includes multiple dish types and the dish items contained in each dish type; Feature extraction is performed on menu data and user information to obtain menu feature information and user feature information; menu feature information includes the data size of each dish item and the dish type to which it belongs; user feature information includes user profile features and user historical preference features; The menu feature information and user feature information are input into a pre-trained menu processing model to obtain the priority of the menu data and the total display time; whereby the priority is used to characterize the user's preference for each type and / or item of dishes in the menu data; Based on the priority and display time of the menu data, filter out the target data from the menu data; Rendering operations are performed based on the target data to display the corresponding menu page.

[0004] According to a second aspect of the embodiments of this application, a menu display device is provided, comprising: The acquisition module is configured to: upon receiving a menu page request, acquire the menu data associated with the menu page request and the currently logged-in user information; the menu data includes multiple dish types and each dish item contained in each dish type; The feature extraction module is configured to: extract features from the menu data and the user information to obtain menu feature information and user feature information; the menu feature information includes the data size of each dish item and the dish type to which it belongs; the user feature information includes user profile features and user historical preference features; The processing module is configured to: input the menu feature information and the user feature information into a pre-trained menu processing model to obtain the priority and display time of the menu data; wherein, the priority is used to characterize the user's preference for each type of dish and / or each item of dish in the menu data; The filtering module is configured to: filter target data from the menu data based on the priority and display time of the menu data; wherein the priority of the target data is higher than that of non-target data in the menu data, and / or the display time of the target data is lower than that of the non-target data; The rendering module is configured to perform rendering operations based on the target data to display the corresponding menu page.

[0005] According to a third aspect of the embodiments of this application, an electronic device is provided, comprising: processor; Memory used to store processor-executable instructions; The processor executes executable instructions to implement the menu display method provided in the first aspect of the embodiments of this application.

[0006] According to a fourth aspect of the present application, a computer-readable storage medium is provided, on which a computer program is stored, wherein when the computer program is executed by a processor, the steps of the menu display method provided in the first aspect of the present application are implemented.

[0007] The technical solutions provided by the embodiments of this application may include the following beneficial effects: In this embodiment, during the menu display process, a pre-trained menu processing model is invoked to comprehensively analyze menu feature information and user feature information to obtain the priority of menu data and the total display time. This allows for accurate determination of the user's preference for dish types and / or dish items in the menu data, as well as the display efficiency of dish types and / or dish items in the menu data. Next, the priority and display time of the menu data are further combined to filter target data from the menu data. For example, target data with higher priority and / or lower display time is selected, and rendering operations are performed based on the target data. This allows for the priority display of target data with shorter display time and better matching user preferences. Compared to the indiscriminate full rendering of massive menu data in related technologies, this significantly reduces the data required for a single rendering, which is beneficial for improving menu page rendering efficiency, device stability and smoothness, thereby greatly shortening the page loading time perceived by the user and effectively improving the user experience.

[0008] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0009] Figure 1 This is a flowchart illustrating a menu display method according to an exemplary embodiment of this application; Figure 2 This is a flowchart illustrating a rendering optimization strategy according to an exemplary embodiment of this application; Figure 3 This is a flowchart illustrating another rendering optimization strategy according to an exemplary embodiment of this application; Figure 4 This is a functional block diagram of a menu display device according to an exemplary embodiment of this application; Figure 5 This is a schematic structural diagram of an electronic device provided in accordance with an exemplary embodiment of this application. Detailed Implementation

[0010] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0011] The following is an explanation of some technical terms used in the embodiments of this application: Menu type: This refers to the category name for classifying catering products, such as hot dishes, cold dishes, staple food, beverages, etc., and is used for primary classification of menu data.

[0012] Item of food: refers to a specific food item belonging to a particular food type. For example, Kung Pao Chicken and Braised Pork in the hot dish type, and mineral water, sparkling water and boiled water in the beverage type. It can be understood that a food type can include at least one item of food.

[0013] Menu processing model: This refers to a pre-trained machine learning or deep learning model used to predict the priority (i.e., user preference) of each dish type or item, as well as the display time (i.e., rendering and loading time), based on input menu features and user characteristics. This model can be one or a combination of more than one of logistic regression, gradient boosting decision trees, and deep neural networks, but is not limited to these.

[0014] Feature extraction refers to the process of extracting key fields or vectors that can characterize the features of raw data, such as menu data and user information. For example, image size and text length can be extracted from menu data as data size features, age and gender can be extracted from user information as profile features, and historical click behavior can be extracted from user information as user historical preference features, but it is not limited to these.

[0015] The DOM, short for Document Object Model, is a programming interface for HTML or XML documents that structures a page into a tree-like node structure, forming the foundation of front-end rendering. In this application, the reuse and management of the DOM structure are key to optimizing rendering performance.

[0016] Virtual window: refers to a logically visible area defined in the front-end interface. Only the menu data within this area is loaded and rendered, rather than loading all the data at once, thereby reducing memory usage.

[0017] The embodiments of this application will now be described in detail.

[0018] To address the technical problem that related technologies, by employing full-scale rendering to display menu pages, cause a significant drop in browser performance, making it difficult to meet the stability and smoothness requirements of browsers under high concurrency or massive data loads, this application provides a menu display method. During the menu display process, a pre-trained menu processing model is invoked to comprehensively analyze menu feature information and user feature information, obtaining the priority of menu data and the total display time. This accurately determines the user's preference for dish types and / or dish items in the menu data, as well as the display efficiency of dish types and / or dish items. Next, by further combining the priority and display time of the menu data, target data is filtered from the menu data. For example, target data with higher priority and / or lower display time is selected, and rendering operations are performed based on the target data. This allows for the priority display of target data with shorter display times and better matching user preferences. Compared to the indiscriminate full-scale rendering of massive menu data in related technologies, this method significantly reduces the data required for a single rendering, improving menu page rendering efficiency, device stability, and smoothness, thereby greatly shortening the user-perceived page loading time and effectively improving the user experience.

[0019] The following combination Figure 1 The menu display method provided in the embodiments of this application will be described below. Figure 1 This is a flowchart illustrating a menu display method according to an exemplary embodiment of this application. The menu display method includes the following steps: In step S100, upon receiving a menu page request, the menu data associated with the menu page request and the currently logged-in user information are obtained; the menu data includes multiple dish types and each dish item contained in each dish type; In step S200, feature extraction is performed on the menu data and user information to obtain menu feature information and user feature information; the menu feature information includes the data size of each dish item and the dish type to which it belongs; the user feature information includes user profile features and user historical preference features; In step S300, menu feature information and user feature information are input into a pre-trained menu processing model to obtain the priority of the menu data and the total display time; wherein, the priority is used to characterize the user's preference for each type of dish and / or each menu item in the menu data; In step S400, target data is filtered from the menu data according to the priority and display time of the menu data; wherein the priority of the target data is higher than that of the non-target data in the menu data, and / or the display time of the target data is lower than that of the non-target data. In step S500, a rendering operation is performed based on the target data to display the corresponding menu page.

[0020] In the catering industry, to facilitate customer ordering, various online ordering channels are typically provided, such as QR codes, mini-programs, apps, or websites. Users can access the menu page through any of these channels, such as scanning a QR code with their device, opening a mini-program, launching an app, or entering a menu link on a webpage. Any of these actions will generate a menu page request. After the menu page loads successfully, users can browse it to select the desired dishes and submit their order for the restaurant to prepare.

[0021] During peak dining hours, the number of requests to the menu page may surge due to the large number of diners. In this case, to ensure that the dishes that users like can be displayed in a timely manner and / or displayed as quickly as possible, the menu display method provided in this application embodiment can be used to prioritize the display of some dishes, thereby reducing the front-end rendering burden and improving the efficiency of the menu page display, the operating efficiency of the front-end device, and the stability of operation.

[0022] The following example illustrates the working process of the menu display method provided in this application: (Using the example of displaying a menu page on a user device) Upon receiving a menu page request, step S100 is executed, whereby the system obtains the menu data associated with the menu page request and the currently logged-in user information. The menu data may include a set of goods or services to be displayed, organized in a tree, list, or other data structure, including but not limited to multiple dish types and the individual dish items within each dish type. User information refers to various data used to identify and characterize the user, including but not limited to basic information such as user ID, terminal device information, and network information, as well as behavioral information including but not limited to user browsing history and user purchase history. Terminal device information includes the client's current CPU load rate, remaining available RAM size, and current battery level and heat status indicators.

[0023] Next, step S200 is executed to extract features from the menu data and user information. Feature extraction refers to the process of transforming raw data into numerical vectors that can be processed by machine learning models. Feature extraction algorithms can be used to extract features from the menu data and user information. For menu data, the extracted menu feature information includes at least the data size of each dish item and its corresponding dish type. The data size of a dish item includes, but is not limited to, the number of bytes in an image file and the number of characters in the descriptive text. The dish type can be encoded as a category feature; for example, a beverage type can be denoted as 1, and a staple food type as 2, but is not limited to these. For user information, the extracted user feature information includes at least user profile features and user historical preference features. User feature information may include, but is not limited to, age range, gender, and spending level, which can be generated through clustering or classification algorithms. User historical preference features may include, but are not limited to, the dish type that the user clicked or purchased most frequently in the past week. Optionally, user feature information may also include time feature information, such as whether it is currently lunchtime, and geographical feature information, such as the user's city. User characteristic information also includes terminal environment characteristic information, such as the client's current network latency (e.g., Ping value), current network standard (e.g., 5G, 4G, WIFI), and current network bandwidth throughput.

[0024] Subsequently, step S300 is executed, inputting the extracted menu feature information and user feature information into a pre-trained menu processing model. This model, trained on a large amount of historical data, is able to learn the complex nonlinear relationship between features and targets. The model's output includes the priority and display time of the menu data. The priority of the menu data represents the user's preference for dish type and / or dish item; a higher value indicates a stronger preference. The total display time represents the estimated rendering time, which can be in milliseconds. Furthermore, the priority and display time of the menu data can include at least one of the following: the priority and total display time of each dish type, and the priority and display time of each menu item. In this embodiment, by introducing the terminal environment feature information and the multimedia data size in the menu feature information as the joint feature vector input of the model, the display time output by the menu processing model can accurately characterize the objective physical time required for the dish item or dish type to perform DOM structure mounting and image decompression rendering on the front end under the current specific client hardware performance and network environment.

[0025] In some embodiments, to improve the scenario applicability, robustness, and output accuracy of the menu processing model, the menu display method provided in this application also provides a scheme for constructing a training sample set for the menu processing model. That is, the menu processing model is trained by an initial network model based on a pre-constructed training sample set; the process of constructing the training sample set includes: In step S310, the menu sample data within the set historical time period, the actual display time of each sample dish item contained in the menu sample data, and the sample user information and its corresponding historical operation records are obtained; the historical operation records include the user's operation frequency for each sample dish item; the operation frequency includes the click frequency and / or order frequency; In step S320, menu sample feature information and user sample feature information are extracted based on menu sample data, sample user information and their corresponding user historical operation records. Menu sample feature information includes: the data size of each dish item and the dish type to which it belongs. User sample feature information includes: user sample profile features and the dish type and / or dish item preferred by the user. In step S330, for each sample user in the sample user information, the actual priority of the sample user for each sample dish is determined based on the frequency of the sample user's operation on each sample dish. In step S340, for each sample user, a set of input samples is formed by taking the menu sample feature information and the user sample feature information corresponding to the sample user. The actual priority of the sample user for each sample dish and the actual display time of each sample dish are used as sample labels to construct the training samples corresponding to the sample user, so as to obtain a training sample set including the training samples corresponding to multiple sample users.

[0026] Understandably, training the menu processing model relies on the aforementioned high-quality training sample set. The construction process of this training sample set is as follows: First, obtain menu sample data, the actual display time of each sample dish item, sample user information, and their corresponding historical operation records such as click frequency and order frequency within a set historical period, such as the past three months. The actual display time of each sample dish item can be obtained through client-side event tracking logs. Next, based on this raw data, extract menu sample feature information and user sample feature information. Menu feature information may include the size of the dish item data and the type of the dish item; user sample feature information may include user profile feature information and user historical preference feature information. Then, for each sample user, determine the user's actual priority for each dish item based on their operation frequency, where higher operation frequency corresponds to higher priority. Finally, use the feature information as input and the actual priority and actual display time as labels to construct a set of training samples. By collecting a large number of such samples, a complete training set can be formed to train the initial network model. Once the initial network model converges, the menu processing model is obtained. The initial network model can also be one or more of the following combinations: logistic regression, gradient boosting decision tree, and deep neural network, but is not limited to these.

[0027] In other embodiments, to better improve the model's generalization ability and scene adaptability, the user feature information can be further expanded, including but not limited to at least one of the following: time feature information, geographic feature information, user device feature information, and network feature information. Among these, time feature information may include, but is not limited to: hour of the day, day of the week; geographic feature information may include, but is not limited to: GPS coordinates, city level; user device feature information may include, but is not limited to: frame rate, frame time, CPU utilization, GPU utilization, video memory bandwidth, device memory; and network feature information may include, but is not limited to: network bandwidth, network speed, network throughput, and latency.

[0028] Therefore, this user characteristic information can be input into the menu processing model, enabling the model to comprehensively consider the menu data size, user device performance, and network conditions to more accurately infer the display time of the menu data, thereby improving subsequent rendering efficiency.

[0029] Corresponding to the expanded user feature information, during the training sample construction phase, the historical operation records also include at least one of the following: time feature information, geographical feature information, device performance feature information, and network feature information when the user operates on each dish item. Based on this, the user sample feature information also includes the dish types and / or dish items preferred by the user at different times and / or in different geographical locations, and / or the performance parameters and / or network parameters of the user's device used to browse dish types and / or dish items. Performance parameters may include, but are not limited to: frame rate, frame time, CPU utilization, GPU utilization, video memory bandwidth, and device memory; network parameters may include, but are not limited to: network bandwidth, network speed, network throughput, and latency.

[0030] Therefore, by incorporating at least one of the time features, geographical features, device performance, and network features related to user preferences into the training samples, the menu processing model can learn complex spatiotemporal preference patterns such as "users prefer high-calorie foods on weekend evenings" or "users prefer local specialties when traveling for business." Furthermore, it can adaptively adjust the complexity of the recommended menu data based on device performance; for example, high-performance devices can display richer content, while low-performance devices can display a simplified interface. The model can also optimize loading strategies based on network conditions; for instance, it can update images or other multimedia content in the menu in real time under high-speed networks, while prioritizing text content in the menu under low-speed networks. This makes the prediction results more closely match the user's real-time needs and actual usage scenarios.

[0031] After obtaining the output of the menu processing model through any of the above embodiments, step S400 is executed to filter target data from the menu data based on the priority and display time of the menu data. The filtering strategy can be varied. For example, target dish types with a priority higher than a first threshold and a total display time lower than a second threshold can be selected; alternatively, target dish items with a priority higher than the first threshold and a display time lower than the second threshold can be selected. The first and second thresholds can be configured according to actual needs or experience and are not limited here. Alternatively, a comprehensive score can be calculated, which is positively correlated with priority and negatively correlated with total display time, and the type with the highest score can be selected.

[0032] In some embodiments, to find the optimal balance between user satisfaction and system performance, the aforementioned method of calculating a comprehensive score can be used to filter one or more target dish types from multiple dish types. Based on this, the priority and display time of the menu data include the priority and total display time of each dish type, and the target data includes the target dish type. Correspondingly, in step S400 above, filtering the target data from the menu data based on the priority and total display time of the menu data can include: In step S410, the priority and total display time of each dish type are normalized respectively, and the normalized priority and total display time of each dish type are weighted and summed to obtain the first display score of each dish type; wherein, the first display score is positively correlated with the priority and negatively correlated with the total display time. In step S420, the dish type with the highest first display score or higher than the set score threshold is selected as the target dish type.

[0033] Understandably, during step S400, the target dish type can be filtered by executing steps S410 to S420. The filtering process is explained below: First, in step S410, the system normalizes the priority and total display time for each dish type. Normalization aims to map indicators with different dimensions and value ranges to the same scale, such as the [0,1] interval, to facilitate subsequent weighted calculations. Commonly used normalization methods include Min-Max Normalization and Z-score standardization; one can be applied, but is not limited to these. Subsequently, the system performs a weighted sum of the normalized priority and total display time to obtain the first display score for each dish type. This weighted sum formula can be expressed as: Score = α × Norm(Priority) - β × Norm(Duration), where α and β are preset first and second weight coefficients used to adjust the relative importance of preference and performance. Norm(Priority) is the normalized priority value, and Norm(Duration) represents the normalized total display time. According to this formula, the first display score is positively correlated with priority and negatively correlated with total display time. To further improve the system's adaptive resource scheduling capability on different hardware terminals, in this embodiment, the first weight coefficient α and the second weight coefficient β are not fixed values, but can be dynamically adjusted according to the terminal operation characteristic information collected in step S100: when the CPU load rate of the client is detected to be higher than the set detection threshold, such as 80%, or when the remaining available memory space is extremely scarce, the system automatically increases the display time weight coefficient β and simultaneously decreases the preference weight coefficient α, thereby actively eliminating those large images or multimedia dishes that take a long time to load during the screening process, prioritizing the system bottom line of preventing low-end devices from crashing; conversely, when terminal resources are abundant, α is automatically increased to maximize the satisfaction of users' personalized taste recommendations.

[0034] Next, step S420 is executed, in which the system determines the dish type with the highest score or higher than the set score threshold as the target dish type.

[0035] The aforementioned score-based quantitative screening mechanism enables the system to flexibly and accurately find the optimal balance between user satisfaction and system performance.

[0036] After the target dish type is obtained through filtering using any of the above embodiments, step S500 is executed, in which the system performs a rendering operation based on the menu data corresponding to the filtered target dish type to display the corresponding menu page to the user.

[0037] Therefore, through steps S100 to S500, during the menu display process, a pre-trained menu processing model is invoked to comprehensively analyze menu feature information and user feature information, obtaining the priority of menu data and the total display time. This accurately determines the user's preference for dish types and / or dish items in the menu data, as well as the display efficiency of dish types and / or dish items in the menu data. Next, by further combining the priority and display time of the menu data, target data is filtered from the menu data. For example, target data with higher priority and / or lower display time is filtered out, and rendering operations are performed based on the target data. This allows for the priority display of target data with shorter display times and better matching user preferences. Compared to the indiscriminate full rendering of massive menu data in related technologies, this significantly reduces the data required for a single rendering, improving menu page rendering efficiency, device stability, and smoothness, thereby greatly shortening the user-perceived page loading time and effectively improving the user experience. This ensures that the content displayed to the user is both potentially interesting and efficiently loaded by the system.

[0038] In some embodiments, the output granularity of the menu processing model can be refined to the item level to further improve system rendering efficiency and enhance user experience. Based on this, embodiments of this application provide two different rendering optimization strategies: The first rendering optimization strategy: The time taken to display menu data includes the time taken to display each dish item within each dish type, and the target data includes the target dish item.

[0039] Based on this, please refer to Figure 2 , Figure 2 This is a flowchart illustrating a rendering optimization strategy according to an exemplary embodiment of this application. In step S500 above, performing a rendering operation based on the target data may include: In step S511, the dish with the shortest cooking time or less than a set time threshold among all the dishes included in the target dish type is displayed as the target dish. In step S512, a rendering operation is performed based on the menu data corresponding to the target dish item.

[0040] Understandably, during the rendering operation, the system does not render all dishes under the entire target dish type indiscriminately, but rather performs further filtering. Specifically, during step S500, the rendering operation can be performed by executing steps S511 to S512: the system first selects the dishes with the shortest display time or less than a set time threshold from among the dishes included in the target dish type as target dishes, and performs rendering only based on the data of these target dishes.

[0041] This ensures that within a high-priority category, items with excessively large data volumes and extremely slow loading times are further eliminated, while lightweight items with fast loading times are prioritized for display, thereby guaranteeing an extremely smooth page and improving the user experience.

[0042] The second rendering optimization strategy: The priority and display time of menu data include the priority and display time of each dish item contained in each dish type, and the target data includes the target dish type.

[0043] Based on this, please refer to Figure 3 , Figure 3 This is a flowchart illustrating another rendering optimization strategy according to an exemplary embodiment of this application. In step S500 above, performing a rendering operation based on the target data may include: In step S521, the priority and display time of each dish item included in the target dish type are normalized respectively, and the normalized priority and display time of each dish item are weighted and summed to obtain the second display score of each dish item; wherein, the second display score is positively correlated with the priority and negatively correlated with the total display time. In step S522, the dish with the highest score or higher than the set score threshold is selected as the target dish. In step S523, a rendering operation is performed based on the menu data corresponding to the target dish item.

[0044] Understandably, the schemes described in steps S521 to S523 involve the system performing a secondary screening on dish items within the target dish type, similar to the schemes described in steps S511 to S512. Specifically, the priority and display time of each dish item are normalized, and a second display score is calculated. This score is also positively correlated with priority and negatively correlated with display time. The system selects the dish item with the highest second display score or that is above a threshold as the target dish item for rendering.

[0045] Therefore, rendering is performed only based on the menu data corresponding to the high-scoring target dishes. This fine-grained filtering mechanism achieves precise optimization from the "type level" to the "single item level," ensuring that every dish the user sees is high-quality content that is both appealing and loads quickly, thereby improving the user experience.

[0046] In some embodiments, the menu display method provided in this application can be used not only for initial page loading but also for subsequent interactive queries and scrolling, to more quickly display the dishes currently queried by the user and achieve rapid display. Based on this, in the embodiments where the priority of menu data and display time include the priority and display time of each dish item contained in each dish type, the menu display method provided in this application may further include: In step S610, a menu index relationship corresponding to user information is established; the menu index relationship includes: the correspondence between each menu type and its contained menu items, and the correspondence between each menu item, its priority, and display time. In step S620, upon receiving a dish query request that is triggered by the menu page and associated with user information, the type of dish to be queried is determined based on the dish query request; In step S630, the candidate dish items included in the dish type to be queried, as well as the priority and display time of each candidate dish item, are obtained from the dish index relationship; In step S640, the dishes to be displayed are determined based on the priority and display time of each candidate dish; In step S650, a rendering operation is performed based on the dish data corresponding to the dish to be displayed, so as to display the dish to be displayed.

[0047] Understandably, after completing the initial screening, the system will establish a dish index relationship for the current user through step S610. This index relationship is an efficient data structure, such as a hash table or inverted index, which maintains the mapping relationship between dish type, dish item, priority, and display time. When a user triggers a dish query request on an already loaded page, such as searching for "spicy," the system does not need to re-invoke the menu processing model. Instead, by executing steps S620 to S640, it directly and quickly retrieves the dish type that meets the query conditions from the local index, quickly filters out the high-priority and low-time dishes under that type for display, and then renders and displays the dishes in step S650, thereby greatly improving the query response speed.

[0048] For scenarios involving long list scrolling, to further improve rendering efficiency and user experience, this application also introduces virtual window technology. That is, based on the embodiments that prioritize menu data and display time, including the priority and display time of each dish item within each dish type, the dish display method provided in this application embodiment may further include: In step S710, a virtual window is defined based on the visible window size of the user device logged in by the user information; In step S720, the visual menu data corresponding to the virtual window is determined based on the scrolling operation on the menu page; In step S730, menu data corresponding to dishes whose display time is less than the set time or whose priority is higher than the set priority are filtered from the visual menu data to update the menu page.

[0049] Understandably, in long list scrolling scenarios, a virtual window is first defined based on the visible window of the user's logged-in device. A virtual window is a logical container built during the front-end rendering process, its size matching the visible area of ​​the user's device (such as a smartphone, tablet, or PC monitor), used to define the range of rendering data that needs to be prioritized. The system determines the corresponding visual menu data in real-time based on scrolling actions on the menu page; scrolling actions can be triggered by touchscreen swipe events, mouse wheel events, or keyboard arrow key events. To balance rendering performance and user experience, the system does not render all visual menu data indiscriminately. Instead, it selects menu items whose display time is less than a set time threshold or whose priority is higher than a set priority threshold from the visual menu data to update the menu page.

[0050] The specific implementation of the filtering logic can be as follows: The system obtains the estimated display time of each dish item in real time. This estimated display time can be output by the menu processing model or determined based on the average loading time in historical statistics, and calculated in combination with the performance of the current device and the network conditions. For example, in the historical statistics, multiple device performance ranges and multiple network speed ranges corresponding to each dish item can be recorded. Among them, multiple device performance ranges correspond to different average loading time ranges, and similarly, multiple network speed ranges correspond to different average loading time ranges. Based on this, when filtering dishes whose display time is less than the set time threshold, for each dish item, the target device performance range and target network speed range corresponding to the dish item can be found from the historical statistics according to the performance information and network information of the current user's device. The first average loading time range corresponding to the target device performance range and the second average loading time range corresponding to the target network speed range are obtained respectively. Then, the average of the median of the first average loading time range and the median of the second average loading time range is calculated, and the average value is used as the display time of the dish item.

[0051] If the display time of a dish exceeds the device's current tolerable threshold—for example, if the estimated loading time exceeds 1 second—or if its priority is low, then that dish will be temporarily shelved and will not participate in the rendering of the current frame. This mechanism allows the system to prioritize displaying "lightweight" and "high-value" content, effectively avoiding page lag caused by loading high-resolution images or complex components.

[0052] As an alternative, the virtual window's determination logic can be calculated using "physical pixels" instead of "logical pixels"; the scroll operation listening mechanism can use the native Scroll Event, or it can be implemented using the more performant ResizeObserver or Intersection Observer API.

[0053] In some embodiments, to achieve a smooth scrolling experience without white screens for users in long list scrolling scenarios, this application embodiment also provides a scheme for determining visual menu data. That is, in step S720 above, determining the visual menu data corresponding to the virtual window based on the scrolling operation on the menu page may include: In step S721, the scrolling operation on the menu page is monitored to determine the current scrolling position; In step S722, the range of basic menu data within the current visible area is determined based on the current scroll position and the height information of each dish item; In step S723, according to the preset buffer parameters, the buffer area is expanded in the adjacent area of ​​the basic menu data range to obtain the expanded menu data range to be rendered. In step S724, the expanded range of menu data to be rendered is determined as the visual menu data corresponding to the virtual window.

[0054] Understandably, to efficiently determine the visual menu data corresponding to the virtual window, the system first listens for user scrolling operations on the menu page, such as touch swipes, mouse wheel scrolling, or keyboard arrow key events like the Scroll event, to obtain the current scroll position in real time. Then, combining the height information of each dish item, it quickly locates the basic menu data range covered by the current visible area through index mapping or binary search. To further improve scrolling smoothness, the system, based on preset buffer parameters, expands the virtual window's upper and lower areas by a set number of dishes, creating buffer areas before and after the basic menu data range, forming an expanded menu data range to be rendered. Finally, the range of menu data to be rendered is determined as the visual menu data that the virtual window should currently process.

[0055] Therefore, by loading and maintaining only the menu data within the visible area and its adjacent buffer, the number of DOM nodes and memory usage are significantly reduced, avoiding the risk of stuttering and crashes caused by rendering the entire long list. At the same time, the introduction of the buffer effectively preloads adjacent content, allowing users to still have a continuous and smooth experience without blank screens when scrolling quickly. In addition, the visible menu data can also be directly used as the input source for subsequent priority filtering, such as retaining the input source for high-priority or low-display-time dishes, achieving dual optimization of on-demand loading and intelligent filtering, thereby greatly improving front-end rendering efficiency and system resource utilization while ensuring user experience.

[0056] In some embodiments, to improve the calculation efficiency of the basic menu data range, this application embodiment also provides another scheme for determining the basic menu data range, that is, in the above step S722, determining the basic menu data range within the current visible area based on the current scroll position and the height information of each dish item may include: In step S7221, the starting and ending indices of the dish to be rendered are calculated based on the current scroll position, the height information of each dish item, and the display height of the virtual window, so as to determine the range of basic menu data.

[0057] Understandably, the basic menu data range can be determined using the technical solution described in step S7221: divide the current scroll position by the preset fixed height of the dish item, and round the result down to obtain the starting index of the dish item corresponding to the top of the current visible area; at the same time, the system obtains the visible height of the virtual window component, that is, the actual pixel height of the menu area in the visible window of the user device, and then divides the visible height by the fixed height of the dish item and rounds it down to calculate the maximum number of dish items that the visible window can hold; finally, add the starting index to the maximum number of dish items that the visible window can hold to obtain the ending index, thereby determining the current basic menu data range as [starting index, ending index].

[0058] Therefore, by using a mathematical calculation method based on scroll position and fixed height, the system can quickly locate the data index range corresponding to the current visible area in O(1) time complexity, without traversing the entire menu data list, which greatly improves the calculation efficiency. At the same time, this calculation method makes full use of the fixed height of the dishes, ensuring that the system can accurately identify the set of dishes that the user can actually see, thus ensuring the accuracy and stability of the index calculation and providing a reliable data foundation for subsequent buffer expansion, element reuse and differentiated updates. In addition, this method does not rely on complex index structures or additional storage space, is simple to implement and has low resource consumption, and is particularly suitable for real-time scrolling scenarios of large-scale menu data, effectively supporting the core performance advantages of virtual scrolling technology.

[0059] Based on any embodiment related to virtual windows, to avoid browser memory jitter and interaction stuttering caused by garbage collection due to frequent creation and destruction of DOM nodes, and to further improve rendering efficiency and user experience, this application also constructs a closed loop for underlying DOM reuse and idle storage pool management, and introduces virtual window and DOM (Document Object Model) structure reuse technology. That is, the menu display method provided in this application embodiment may further include: In step S810, it is determined whether the first DOM structure corresponding to the menu data currently displayed in the virtual window is consistent with the second DOM structure corresponding to the menu data to be displayed. In step S820, if the first DOM structure and the second DOM structure are consistent, the menu data to be displayed is updated to the first DOM structure, and the rendering operation is performed according to the updated first DOM structure.

[0060] Understandably, before performing a rendering update, the system first determines whether the first DOM structure corresponding to the menu data currently displayed in the virtual window is consistent with the second DOM structure corresponding to the menu data to be displayed. DOM structure refers to the tree-like data model of a web page document, containing the tag names, attributes, styles, and hierarchical relationships of nodes. Structural consistency comparison can be performed by comparing the HTML tag names and the number of bound style classes, through calculating the hash value of DOM nodes, the fingerprint of key attributes, or using the Diff algorithm of the Virtual DOM.

[0061] When the comparison results show that the first DOM structure is consistent with the second DOM structure, it means that the old and new data only differ in attribute values ​​such as text content or image links, while the underlying HTML tag structure and style rules remain unchanged. At this point, destruction and remounting actions are prohibited. The system does not need to trigger the browser's reflow and repaint processes. Instead, it updates the menu data to be displayed to the first DOM structure through a two-way data binding mechanism, reusing existing nodes and performing rendering operations based on the updated first DOM structure, thus eliminating the browser's reflow and repaint overhead.

[0062] This "structure reuse" strategy greatly reduces the computational overhead of the browser engine and significantly improves the frame rate (FPS) of page updates.

[0063] As an alternative, consistency comparison can be performed at the level of the entire list item, or down to the sub-components within the list item, such as when only the title and price change while the layout container remains the same. Furthermore, the DOM structure definition can be extended to the View hierarchy in a native application or the Widget tree structure in the Flutter framework.

[0064] Based on any embodiment related to virtual windows or DOM structure, this application also proposes a memory management mechanism based on a recycle pool to solve the memory thashing and garbage collection (GC) stuttering problems caused by frequent creation and destruction of DOM nodes during long list scrolling. Based on this, the menu display method provided in this application may further include: In step S910, based on the scrolling operation on the menu page, the DOM structure corresponding to the menu data that scrolls out of the virtual window is moved out of memory to a set idle storage pool. In step S920, upon receiving an update request for the menu data of the updated menu page, it is determined whether there exists a target DOM structure in the idle storage pool that is consistent with the DOM structure corresponding to the menu data of the update request. In step S930, if the target DOM structure exists, the target DOM structure is invoked, and the menu data corresponding to the update request is updated to the target DOM structure; In step S940, a rendering operation is performed based on the updated target DOM structure.

[0065] Understandably, based on the scrolling operation on the menu page, the DOM structure corresponding to the menu data that scrolls out of the virtual window is moved from memory to a set idle storage pool; the idle storage pool is a caching mechanism, such as a queue or stack structure, used to temporarily store the removed DOM nodes or their corresponding rendering component instances.

[0066] When receiving an update request for menu data on the updated menu page, for example, when a user quickly scrolls back to the previous screen, the system first determines whether a target DOM structure exists in the idle storage pool that matches the DOM structure corresponding to the menu data in the update request. If it exists, the system directly calls the target DOM structure, that is, it retrieves it from the pool for reuse, updates the menu data corresponding to the update request into the reused structure, and then performs the rendering operation based on the updated structure.

[0067] This mechanism avoids the expensive overhead of repeatedly creating complex DOM nodes, such as parsing HTML and building a render tree, and directly reduces the memory consumption when scrolling large lists on the page to a constant level, eliminating the risk of browser crashes caused by massive DOMs.

[0068] As an alternative, the idle storage pool can be set with a maximum capacity limit and use the LRU (Least Recently Used) algorithm to automatically clean up nodes that have not been called for a long time; the physical implementation of the storage pool can be an object pool in JavaScript, a WeakMap structure, or the corresponding ViewHolder cache pool in the native application.

[0069] In some embodiments, to improve the stability of the system under long-term operation, this application embodiment also provides an implementation method for moving the DOM structure out of memory to an idle storage pool. That is, in the above step S910, according to the scrolling operation in the menu page, the DOM structure corresponding to the menu data scrolled out of the virtual window is moved from memory to a set idle storage pool, including: In step S911, the boundary range of the virtual window is adjusted based on the direction and speed of the scrolling operation; In step S912, when it is detected that the display position of a dish item exceeds a preset threshold of the boundary range, the DOM structure corresponding to the dish item is moved out of memory to the idle storage pool.

[0070] Understandably, when a user's scrolling action is detected, the system first analyzes the deltaY or wheelDelta attributes of the scrolling event to determine the scrolling direction and calculate the scrolling speed. Scrolling speed represents the rate of change of scrolling distance per unit time. Then, based on the scrolling direction and speed, the system adjusts the boundary range of the virtual window. This includes: if fast scrolling is detected, the system appropriately expands the buffer range, for example, by adding more food items above and below the visible area to meet the preloading requirements of high-speed scrolling; if slow scrolling occurs, a smaller buffer range is maintained to save resources. Simultaneously, the system continuously monitors the position information of each food item within the scrolling container. By calculating the relative distance between the food item's offsetTop and the current scrolling position and the virtual window boundary, it determines whether it exceeds a preset boundary threshold. For example, if a food item completely leaves the visible area and exceeds the buffer range by a certain number of pixels, it can be considered to have exceeded the preset boundary threshold. Once the system detects that the display position of a dish item exceeds the boundary threshold, it immediately removes the DOM structure corresponding to the dish item from the current rendering tree and stores it in a pre-created idle storage pool. At the same time, it removes the reference to the DOM structure from the active list, but retains its basic structure and style information for subsequent reuse.

[0071] Therefore, through an adaptive boundary adjustment mechanism based on scrolling direction and speed, the system can intelligently predict the user's scrolling behavior, ensuring smoothness while avoiding resource waste caused by excessive preloading. Moving DOM structures that scroll out of the viewport into an idle storage pool instead of destroying them directly enables the circular reuse of DOM structures, significantly reducing the performance overhead caused by frequent creation and destruction of DOM structures, such as memory allocation and garbage collection pressure. The introduction of the idle storage pool allows newly entered menu items to directly reuse existing DOM structures in the pool, requiring only content data updates, greatly reducing the complexity of DOM operations and rendering latency. In addition, this mechanism effectively controls peak memory usage, avoiding the risk of memory leaks caused by DOM node accumulation during long list scrolling, ensuring the stability and high performance of the system under long-term operation.

[0072] In some embodiments, virtual windows, DOM structure reuse, and memory management mechanisms can be combined to construct a multi-layered front-end performance optimization system. This system first uses a "virtual window" mechanism to filter out data in non-visible areas at a macro level, retaining only data within the visible area for processing. Second, through "DOM structure consistency comparison," it determines at a meso level whether node reconstruction is necessary, prioritizing an "in-place update" strategy to reduce reflow and repainting. Finally, through an "idle storage pool" mechanism, it achieves the recycling of node objects at a micro level, ensuring that memory usage remains stable even in scenarios with frequent data updates and scrolling.

[0073] In practice, the workflow for these three components is as follows: When a user triggers a scrolling operation, the target menu items within the visible area of ​​the device screen are first calculated according to the aforementioned "virtual window" solution. Then, according to the "DOM structure reuse" solution, it is checked whether the DOM nodes on the current menu page can be directly mapped to the structure of these target menu items. If the structures are consistent, for example, they are all standard list items of "image + title + price", the data is updated directly. If the structures are inconsistent or new nodes need to be added, according to the "idle storage pool" solution, available nodes are first requested from the idle storage pool. If there are no available nodes in the pool, new nodes are created. After processing, the nodes that have been moved out of the visible area of ​​the device screen are returned to the idle storage pool.

[0074] It is evident that this combination of "window filtering + structure reuse + pooling management" can maximize the rendering performance of menu pages, especially in low-end mobile devices or menu scenarios containing a large amount of rich media content, effectively ensuring a smooth 60fps interactive experience.

[0075] Furthermore, the above combination scheme, when combined with steps S100 to S500, can also produce the following significant synergistic technical effects: Firstly, by prioritizing menu data and predicting display time through the menu processing model, the system can achieve predictive memory management. The DOM structure corresponding to high-priority menu data can be marked as "hot data" after scrolling out of the visible area and delayed in being recycled to the idle storage pool, ensuring millisecond-level reuse when users quickly scroll back. Meanwhile, the DOM structure of low-priority menu data is immediately returned to the pool or directly destroyed, effectively releasing memory resources.

[0076] Secondly, the deep coupling between the model prediction algorithm and memory management enables forward-looking rendering scheduling. The system can predict the DOM structure corresponding to high-priority menu data from the idle storage pool in advance based on the scrolling direction, thereby better reducing scrolling latency. For example, the scrolling latency can be reduced to less than 16ms to ensure a smooth 60fps experience.

[0077] Thirdly, based on the predicted time consumption of menu data display, the system can dynamically adjust the capacity and node type distribution of the idle storage pool to avoid memory waste caused by excessive pre-allocation.

[0078] More importantly, this combined solution achieves deep collaboration between software and hardware—the predictive capabilities of the AI ​​model and the front-end memory management mechanism form a closed-loop optimization, which not only solves the inherent defects of "passive recycling and fixed pool capacity" in traditional virtual scrolling, but also achieves a technological leap from "experience-based optimization" to "intelligent predictive optimization" through data-driven methods. It is particularly suitable for low-end mobile devices and rich media menu scenarios, and has strong applicability.

[0079] The various technical features in the above embodiments can be combined arbitrarily, as long as there is no conflict or contradiction between the combinations of features. However, due to space limitations, they are not described one by one. Therefore, the arbitrary combination of various technical features in the above embodiments also falls within the scope of this application.

[0080] Corresponding to the embodiments of the foregoing methods, this application also provides embodiments of the apparatus. For example... Figure 4 As shown, Figure 4 This is a functional block diagram of a menu display device 400 according to an exemplary embodiment of this application. The menu display device 400 includes: The acquisition module 410 is configured to: upon receiving a menu page request, acquire the menu data associated with the menu page request and the currently logged-in user information; the menu data includes multiple dish types and each dish item contained in each dish type; The feature extraction module 420 is configured to: extract features from menu data and user information to obtain menu feature information and user feature information; the menu feature information includes the data size of each dish item and the dish type to which it belongs; the user feature information includes user profile features and user historical preference features; The processing module 430 is configured to: input the menu feature information and the user feature information into a pre-trained menu processing model to obtain the priority and display time of the menu data; wherein, the priority is used to characterize the user's preference for each type of dish and / or each dish item in the menu data; The filtering module 440 is configured to: filter target data from the menu data according to the priority and display time of the menu data; wherein the priority of the target data is higher than that of non-target data in the menu data, and / or the display time of the target data is lower than that of the non-target data; The rendering module 450 is configured to perform rendering operations based on the target data to display the corresponding menu page.

[0081] In some embodiments, the priority and display time of the menu data include the priority and total display time of each dish type; the target data includes the target dish type; the process by which the filtering module 440 filters the target data from the menu data according to the priority and display time of the menu data is configured as follows: The priority and total display time of each dish type are normalized separately, and the normalized priority and total display time of each dish type are weighted and summed to obtain the first display score of each dish type; the first display score is positively correlated with the priority and negatively correlated with the total display time. The dish type with the highest score or above the set score threshold will be selected as the target dish type.

[0082] In some embodiments, the time taken to display menu data includes the time taken to display each dish item contained in each dish type; target data includes the target dish item.

[0083] Accordingly, the process by which the rendering module 450 performs rendering operations based on the target data is configured as follows: Among all the dishes included in the target dish type, the dish with the shortest cooking time or less than the set time threshold is displayed as the target dish. Execute the rendering operation based on the menu data corresponding to the target dish.

[0084] In some embodiments, the priority and display time of menu data include the priority and display time of each dish item contained in each dish type; target data includes target dish type.

[0085] Accordingly, the process by which the rendering module 450 performs rendering operations based on the target data is configured as follows: The priority and display time of each dish item included in the target dish type are normalized respectively. The normalized priority and display time of each dish item are then weighted and summed to obtain the second display score of each dish item. The second display score is positively correlated with the priority and negatively correlated with the total display time. The dish with the highest score in the second display or a score higher than the set threshold will be selected as the target dish. Rendering is performed based on the menu data corresponding to the target dish.

[0086] In some embodiments, the menu processing model is trained from an initial network model based on a pre-built training sample set; the menu display device 400 may further include: The sample building module is configured as follows: Obtain menu sample data within a set historical time period, the actual display time of each sample dish item contained in the menu sample data, and sample user information and their corresponding historical operation records; the historical operation records include the frequency of user operations on each sample dish item; the operation frequency includes the click frequency and / or order frequency; Based on the menu sample data, sample user information, and their corresponding user historical operation records, extract menu sample feature information and user sample feature information. Menu sample feature information includes: the data size of each dish item and the dish type to which it belongs. User sample feature information includes: user sample profile features and the dish types and / or dish items preferred by users. For each sample user in the sample user information, the actual priority of the sample user for each sample dish item is determined based on the frequency of the sample user's operation on each sample dish item; For each sample user, the menu sample feature information and the user sample feature information corresponding to the sample user are used as a set of input samples. The actual priority of the sample user for each sample dish and the actual display time of each sample dish are used as sample labels to construct the training samples corresponding to the sample user, so as to obtain a training sample set including the training samples corresponding to multiple sample users.

[0087] In some embodiments, the user characteristic information further includes at least one of time characteristic information, geographic characteristic information, user equipment characteristic information, and network characteristic information; Historical operation records also include at least one of the following: time characteristics, geographical characteristics, device performance characteristics, and network characteristics when the user operates on each dish item; User sample feature information also includes the types and / or items of dishes preferred by users at different times and / or in different geographical locations, and / or the performance parameters and / or network parameters of the user's device used to browse the types and / or items of dishes.

[0088] In some embodiments, the priority and display time of the menu data include the priority and display time of each dish item. Accordingly, the menu display device 400 may further include: The index building module is configured to: build the menu index relationship corresponding to user information; the menu index relationship includes: the correspondence between each menu type and its contained menu items, and the correspondence between each menu item, its priority, and display time; The query module is configured to: upon receiving a menu page-triggered dish query request associated with user information, determine the type of dish to be queried based on the dish query request; and retrieve from the dish index relationship the list of candidate dishes included in the type of dish to be queried, as well as the priority and display time of each candidate dish. The first determining module is configured to: determine the dishes to be displayed based on the priority and display time of each candidate dish; Based on this, the rendering module 450 is also configured to perform rendering operations according to the dish data corresponding to the dish to be displayed, so as to display the dish to be displayed.

[0089] In some embodiments, the priority and display time of the menu data include the priority and display time of each dish item. Accordingly, the menu display device 400 may further include: The window definition module is configured to define virtual windows based on the visible window size of the user device logged in by the user information. The second determining module is configured to: determine the visual menu data contained in the virtual window based on the scrolling operation on the menu page; Correspondingly, the rendering module 450 is also configured to: filter out the menu data corresponding to dishes whose display time is less than the set time or whose priority is higher than the set priority from the visual menu data, so as to update the menu page.

[0090] In some embodiments, the process by which the second determining module determines the visual menu data contained in the virtual window based on scrolling operations on the menu page is configured to include: Listen for scrolling actions on the menu page to determine the current scroll position; Based on the current scroll position and the height information of each dish, determine the range of basic menu data within the current visible area; Based on the preset buffer parameters, the buffer area is expanded in the adjacent area of ​​the basic menu data range to obtain the expanded menu data range to be rendered. The expanded range of menu data to be rendered is defined as the visible menu data corresponding to the virtual window.

[0091] In some embodiments, the process by which the second determining module determines the range of basic menu data within the current visible area based on the current scroll position and the height information of each dish item is configured to include: Based on the current scroll position, the height information of each dish item, and the display height of the virtual window, calculate the starting and ending indices of the dish item to be rendered to determine the range of the basic menu data.

[0092] In some embodiments, the menu display device 400 may further include: The third determining module is configured to: determine whether the first DOM structure corresponding to the menu data currently displayed in the virtual window is consistent with the second DOM structure corresponding to the menu data to be displayed; Correspondingly, the rendering module 450 is also configured to update the menu data to be displayed to the first DOM structure when the first DOM structure and the second DOM structure are consistent, and to perform rendering operations according to the updated first DOM structure.

[0093] In some embodiments, the menu display device 400 may further include: The remove module is configured to: based on the scrolling operation on the menu page, remove the DOM structure corresponding to the menu data that scrolls out of the virtual window from memory to a set idle storage pool; The fourth determination module is configured to: upon receiving an update request for menu data on the updated menu page, determine whether there exists a target DOM structure in the idle storage pool that matches the DOM structure of the menu data corresponding to the update request; The calling module is configured to: if the target DOM structure exists, call the target DOM structure and update the menu data corresponding to the update request to the target DOM structure; Correspondingly, the rendering module 450 is also configured to perform rendering operations based on the updated target DOM structure.

[0094] In some embodiments, the process by which the removal module removes the DOM structure corresponding to the menu data that scrolls out of the virtual window from memory to a designated idle storage pool based on scrolling operations on the menu page is configured to include: Adjust the boundary range of the virtual window based on the direction and speed of the scrolling operation; When it is detected that the display position of a dish item exceeds a preset threshold of the boundary range, the DOM structure corresponding to the dish item is moved out of memory to an idle storage pool.

[0095] The specific implementation process of the functions and roles of each module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0096] The device implementation can be achieved through software, hardware, or a combination of both. Taking software implementation as an example, as a logical device, it is formed by its processor reading the corresponding computer program instructions from non-volatile memory into memory and executing them.

[0097] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative, and the modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0098] Corresponding to the foregoing method embodiments, this application also provides electronic device embodiments. For example... Figure 5 As shown, Figure 5 This is a schematic structural diagram of an electronic device provided by this application according to an exemplary embodiment. At the hardware level, the electronic device includes a processor 202, an internal bus 204, a network interface 206, memory 208, and non-volatile memory 210, and may also include other hardware required for various services. One or more embodiments of this application can be implemented in software, for example, the processor 202 reads the corresponding computer program from the non-volatile memory 210 into memory 208 and then runs it. Of course, besides software implementation, one or more embodiments of this application do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution entity of the following processing flow is not limited to individual logic units, but can also be hardware or logic devices.

[0099] Furthermore, the embodiments of the menu display device provided in this application can be applied to the aforementioned electronic devices.

[0100] Corresponding to the foregoing method embodiments, this application also provides a computer-readable storage medium storing computer instructions thereon, which, when executed by a processor, implement the steps of the method as described in any of the above embodiments.

[0101] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0102] In a typical configuration, a computer may include one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0103] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0104] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0105] While this application contains numerous specific implementation details, these should not be construed as limiting the scope of any invention or the scope of the claims, but rather are primarily used to describe features of specific embodiments of a particular invention. Certain features described in the multiple embodiments of this application may also be implemented in combination in a single embodiment. Conversely, various features described in a single embodiment may also be implemented separately in multiple embodiments or in any suitable sub-combination. Furthermore, while features may function in certain combinations as described above and even initially claimed in this way, one or more features from a claimed combination may be removed from that combination in some cases, and a claimed combination may refer to a sub-combination or a variation thereof.

[0106] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention filed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not claimed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0107] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

[0108] The above description is only a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A menu display method, characterized in that, include: Upon receiving a menu page request, obtain the menu data associated with the menu page request and the currently logged-in user information; The menu data includes multiple dish types and the various dish items contained in each dish type; Feature extraction is performed on the menu data and the user information to obtain menu feature information and user feature information; the menu feature information includes the data size of each dish item and the dish type to which it belongs; the user feature information includes user profile features and user historical preference features; The menu feature information and the user feature information are input into a pre-trained menu processing model to obtain the priority and display time of the menu data; wherein, the priority is used to characterize the user's preference for each type and / or item of dishes in the menu data; Based on the priority and display time of the menu data, target data is filtered out from the menu data; wherein the priority of the target data is higher than that of the non-target data in the menu data, and / or the display time of the target data is lower than that of the non-target data; Rendering operations are performed based on the target data to display the corresponding menu page.

2. The method according to claim 1, characterized in that, The priority and display time of the menu data include the priority and total display time of each dish type; the target data includes the target dish type; The step of filtering target data from the menu data based on the priority and display time of the menu data includes: The priority and total display time of each dish type are normalized, and the normalized priority and total display time of each dish type are weighted and summed to obtain the first display score of each dish type; wherein, the first display score is positively correlated with the priority and negatively correlated with the total display time. The dish type with the highest score or higher than the set score threshold is selected as the target dish type.

3. The method according to claim 1, characterized in that, The display time of the menu data includes the display time of each dish item contained in each dish type; the target data includes the target dish item; The step of performing the rendering operation based on the target data includes: Among all the dishes included in the target dish type, the dish with the shortest cooking time or less than a set time threshold is displayed as the target dish. Rendering is performed based on the menu data corresponding to the target dish.

4. The method according to claim 1, characterized in that, The priority and display time of the menu data include the priority and display time of each dish item contained in each dish type; the target data includes the target dish type; The step of performing the rendering operation based on the target data includes: The priority and display time of each dish item included in the target dish type are normalized respectively, and the normalized priority and display time of each dish item are weighted and summed to obtain the second display score of each dish item; wherein, the second display score is positively correlated with the priority and negatively correlated with the total display time. The dish with the highest score in the second display or a score higher than the set threshold will be selected as the target dish. Rendering operations are performed based on the menu data corresponding to the target dish.

5. The method according to any one of claims 1 to 4, characterized in that, The menu processing model is trained from an initial network model based on a pre-built training sample set; the process of building the training sample set includes: Obtain menu sample data within a set historical time period, the actual display time of each sample dish item included in the menu sample data, and sample user information and its corresponding historical operation records; the historical operation records include the user's operation frequency for each sample dish item; the operation frequency includes click frequency and / or order frequency; Based on the menu sample data, the sample user information, and the corresponding user historical operation records, menu sample feature information and user sample feature information are extracted; the menu sample feature information includes: the data size of each dish item and the dish type to which it belongs; the user sample feature information includes: user sample profile features and the dish types and / or dish items preferred by the user; For each sample user in the sample user information, the actual priority of the sample user for each sample dish is determined based on the frequency of the sample user's operation on each sample dish. For each sample user, the menu sample feature information and the user sample feature information corresponding to the sample user are used as a set of input samples. The actual priority of the sample user for each sample dish and the actual display time of each sample dish are used as sample labels to construct the training samples corresponding to the sample user, so as to obtain a training sample set including training samples corresponding to multiple sample users.

6. The method according to claim 5, characterized in that, The user characteristic information also includes at least one of time characteristic information, geographical characteristic information, user device characteristic information, and network characteristic information; The historical operation records also include at least one of the following: time characteristic information, geographical characteristic information, device performance characteristic information, and network characteristic information when the user operates on each dish item; The user sample feature information also includes the types and / or items of dishes preferred by the user at different times and / or in different geographical locations, and / or the performance parameters and / or network parameters of the user device used by the user to browse the types and / or items of dishes.

7. The method according to claim 1, characterized in that, The priority and display time of the menu data include the priority and display time of each dish item contained in each dish type; The method further includes: Establish a menu index relationship corresponding to the user information; the menu index relationship includes: the correspondence between each menu type and its included menu items, and the correspondence between each menu item, its priority, and display time; Upon receiving a dish query request that is triggered by the menu page and is associated with the user information, the type of dish to be queried is determined based on the dish query request; Obtain from the dish index relationship the list of candidate dishes included in the dish type to be queried, as well as the priority and display time of each candidate dish; The dishes to be displayed are determined based on their priority and display time. Based on the dish data corresponding to the dish to be displayed, a rendering operation is performed to display the dish to be displayed.

8. The method according to claim 1, characterized in that, The priority and display time of the menu data include the priority and display time of each dish item contained in each dish type; the method also includes: A virtual window is defined based on the visible window size of the user device logged in according to the user information; The visual menu data corresponding to the virtual window is determined based on the scrolling operation on the menu page; The menu data corresponding to dishes whose display time is less than the set time or whose priority is higher than the set priority are filtered from the visual menu data to update the menu page.

9. The method according to claim 8, characterized in that, The step of determining the visual menu data corresponding to the virtual window based on the scrolling operation on the menu page includes: Listen for scrolling operations on the menu page to determine the current scroll position; Based on the current scroll position and the height information of each dish item, determine the range of basic menu data within the current visible area; Based on preset buffer parameters, the buffer area is expanded in the adjacent area of ​​the basic menu data range to obtain the expanded menu data range to be rendered. The expanded range of menu data to be rendered is defined as the visual menu data corresponding to the virtual window.

10. The method according to claim 9, characterized in that, The step of determining the range of basic menu data within the current visible area based on the current scroll position and the height information of each dish item includes: Based on the current scroll position, the height information of each dish item, and the display height of the virtual window, calculate the starting and ending indices of the dish item to be rendered to determine the range of the basic menu data.

11. The method according to claim 8, characterized in that, Also includes: Determine whether the first DOM structure corresponding to the menu data currently displayed in the virtual window is consistent with the second DOM structure corresponding to the menu data to be displayed; If the first DOM structure and the second DOM structure are consistent, the menu data to be displayed is updated to the first DOM structure, and the rendering operation is performed according to the updated first DOM structure.

12. The method according to any one of claims 8 to 11, characterized in that, Also includes: Based on the scrolling operation on the menu page, the DOM structure corresponding to the menu data that scrolls out of the virtual window is moved out of memory to a set idle storage pool; Upon receiving an update request to update the menu data of the menu page, determine whether there exists a target DOM structure in the idle storage pool that is consistent with the DOM structure corresponding to the menu data of the update request; If the target DOM structure exists, the target DOM structure is invoked, and the menu data corresponding to the update request is updated to the target DOM structure; Rendering operations are performed based on the updated target DOM structure.

13. The method according to claim 12, characterized in that, The step of moving the DOM structure corresponding to the menu data that scrolls out of the virtual window from memory to a designated idle storage pool based on the scrolling operation on the menu page includes: Adjust the boundary range of the virtual window based on the direction and speed of the scrolling operation; When it is detected that the display position of the dish item exceeds a preset threshold of the boundary range, the DOM structure corresponding to the dish item is moved out of memory to the idle storage pool.

14. A menu display device, characterized in that, include: The acquisition module is configured to: upon receiving a menu page request, acquire the menu data associated with the menu page request and the currently logged-in user information; The menu data includes multiple dish types and the various dish items contained in each dish type; The feature extraction module is configured to: extract features from the menu data and the user information to obtain menu feature information and user feature information; the menu feature information includes the data size of each dish item and the dish type to which it belongs; the user feature information includes user profile features and user historical preference features; The processing module is configured to: input the menu feature information and the user feature information into a pre-trained menu processing model to obtain the priority and display time of the menu data; wherein, the priority is used to characterize the user's preference for each type of dish and / or each item of dish in the menu data; The filtering module is configured to: filter target data from the menu data based on the priority and display time of the menu data; wherein the priority of the target data is higher than that of non-target data in the menu data, and / or the display time of the target data is lower than that of the non-target data; The rendering module is configured to perform rendering operations based on the target data to display the corresponding menu page.

15. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor implements the method of any one of claims 1 to 13 by executing the executable instructions.

16. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 13.

Images