Data delay loading method, system and related equipment oriented to iOS mobile terminal and based on GraphQL protocol

Abstract

The invention provides an iOS mobile terminal-oriented data delay loading method and system based on a GraphQL protocol, and related equipment. The method comprises the following steps: receiving a stream segment load transmitted by a server based on a GraphQL protocol, and analyzing a causal fence identifier in the stream segment load; based on the causal fence identifier, establishing and maintaining a causal fence state for a key value corresponding to the stream segment in a standardized cache of a client; inputting the causal fence state into a user interface hydration engine of a client, and performing causal fence verification on fragments in a waiting queue in the user interface hydration engine; and when the causal fence verification meets a dependent closure, submitting a user interface update transaction of a corresponding segment by utilizing the user interface hydration engine.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the field of computer information technology, and in particular, to a data lazy loading method based on a GraphQL protocol for an iOS mobile terminal, a data lazy loading system based on a GraphQL protocol for an iOS mobile terminal, an electronic device, and a storage medium. BACKGROUND

[0002] In mobile terminal applications, the data acquisition method based on the GraphQL protocol is widely used to realize efficient interaction between the front-end interface and the back-end service. The existing lazy loading mechanism usually relies on the step-by-step return capability provided by the GraphQL protocol, such as transmitting different fragments of data by the server in stages to meet the needs of the client for quick display of the interface and subsequent content supplement. However, in the specific implementation of the iOS mobile terminal, this mechanism still faces several problems that have not been effectively solved.

[0003] On the one hand, the existing step-by-step return mechanism lacks strict constraints on the order of fragment transmission, and often returns sub-object data before parent object data. When the client receives such out-of-order fragments, directly updating the interface can easily cause problems such as inconsistent interface levels and disordered component relationships. In order to avoid this situation, blocking waiting or delay strategies based on time thresholds are usually used, but these methods either cause excessive data submission delay or have unstable experience parameters, making it difficult to ensure the continuity of interface display.

[0004] On the other hand, the existing cache and interface update mechanism often lacks targeted data management strategies when facing step-by-step returned fragments. The cache layer usually simply stores key-value pair records of each fragment, and the interface update relies on the immediate trigger of the fragment arrival. This processing method is difficult to maintain the overall consistency of interface data in the scenario of multiple fragment transmission, and once the fragment arrival order does not match the interface dependency relationship, it is easy to cause temporary display flicker or rendering of error state, thereby affecting user experience.

[0005] Therefore, although the existing GraphQL lazy loading technology improves transmission efficiency to some extent, there are still significant deficiencies in fragment out-of-order and cache management, especially in the iOS mobile terminal application environment, these deficiencies will be more prominent and directly affect the stability of the interface and the coherence of the interaction.

[0006] It should be noted that the statements in the above background section are only used to provide background information related to the present application, and do not necessarily constitute the prior art. SUMMARY

[0007] To at least partially overcome the problems existing in the related art, the embodiments of the present disclosure provide a data lazy loading method based on a GraphQL protocol for an iOS mobile terminal, a data lazy loading system based on a GraphQL protocol for an iOS mobile terminal, an electronic device, and a storage medium.

[0008] According to one aspect of the present disclosure, a data lazy loading method based on a GraphQL protocol for an iOS mobile terminal is provided, comprising:

[0009] receiving a stream fragment payload transmitted by a server based on a GraphQL protocol, and parsing a causal fence identifier in the stream fragment payload;

[0010] based on the causal fence identifier, establishing and maintaining a causal fence state for a key value corresponding to the stream fragment in a canonical cache of a client;

[0011] inputting the causal fence state to a user interface hydration engine of the client, and performing causal fence checking on fragments in a waiting queue in the user interface hydration engine;

[0012] when the causal fence checking satisfies a dependency closure, submitting a user interface update transaction of a corresponding fragment by using the user interface hydration engine.

[0013] In an exemplary embodiment of the present disclosure, the parsing of the causal fence identifier in the stream fragment payload comprises:

[0014] extracting schema path information from the stream fragment payload, and generating a dependency closure description related to parent-child dependencies based on the schema path information;

[0015] constructing a logical clock component containing a parent key version vector based on the dependency closure description, and calculating a digest value of the parent key version vector;

[0016] combining the logical clock component and the digest value into an intermediate identifier, and serializing the intermediate identifier to obtain the causal fence identifier.

[0017] In an exemplary embodiment of the present disclosure, the establishing and maintaining of the causal fence state for the key value corresponding to the stream fragment in the canonical cache of the client comprises:

[0018] reading an object type name from the stream fragment payload, reading an object identifier from the stream fragment payload, and reading a schema path from the stream fragment payload;

[0019] splicing the object type name, the object identifier, and the schema path by a predetermined delimiter to form the key value;

[0020] creating a record corresponding to the key in the canonical cache;

[0021] writing the causal fence identifier into a fence status field of the record and persisting the fence status field to local storage.

[0022] In an example embodiment of the present disclosure, the inputting the causal fence status into the user interface hydration engine, the causal fence checking of the segments in the waiting queue in the user interface hydration engine comprises:

[0023] reading a segment to be checked from the waiting queue and retrieving a parent key set related to the segment to be checked based on the causal fence status;

[0024] constructing a dependency set to be compared based on the parent key set;

[0025] generating a checking result based on the dependency set and the causal fence identifier.

[0026] In an example embodiment of the present disclosure, the causal fence checking of the segments in the waiting queue in the user interface hydration engine further comprises:

[0027] setting an upper limit of capacity for the waiting queue;

[0028] adding a new segment to the waiting queue when the new segment is received;

[0029] when the waiting queue reaches the upper limit of capacity, generating a sorting key based on a causal dependency depth and a time of arrival and sorting the waiting queue according to the sorting key;

[0030] selecting a segment at the tail of the sorting as a removal object and deleting the removal object from the waiting queue and writing a key value of the removed segment into a removal record.

[0031] In an example embodiment of the present disclosure, the submitting a user interface update transaction of the corresponding segment by using the user interface hydration engine comprises:

[0032] determining a set of affected key values based on the segment and generating an interface change set based on the set of key values;

[0033] binding the interface change set as a user interface update transaction;

[0034] adding the user interface update transaction to a tail position of a transaction queue and registering an execution callback of the transaction queue on a main thread scheduler;

[0035] The user interface update transaction is taken out from the transaction queue when the trigger condition is met, and an interface layer is called to execute the user interface update transaction.

[0036] In an example embodiment of the present disclosure, the interface change set is generated based on the key-value set; and the method comprises:

[0037] The data fields corresponding to each key-value are read from the normalized cache by traversing the key-value set;

[0038] A difference patch is generated based on the data fields, and the difference patch is added to the interface change set.

[0039] According to an aspect of the present disclosure, a data lazy loading system based on a GraphQL protocol for an iOS mobile terminal is provided, comprising:

[0040] A causal fence parsing module is configured to receive a stream fragment payload transmitted by a server based on a GraphQL protocol, and parse a causal fence identifier in the stream fragment payload;

[0041] A state maintaining module is configured to establish and maintain a causal fence state for a key-value corresponding to the stream fragment in a normalized cache of a client based on the causal fence identifier;

[0042] A verification module is configured to input the causal fence state to a user interface hydration engine of the client, and perform causal fence verification on a fragment in a waiting queue in the user interface hydration engine;

[0043] A user interface update module is configured to submit a user interface update transaction of a corresponding fragment by using the user interface hydration engine when the causal fence verification satisfies a dependency closure.

[0044] According to an aspect of the present disclosure, an electronic device is provided, comprising:

[0045] A processor; and

[0046] A memory for storing executable instructions of the processor;

[0047] The processor is configured to execute the method according to any one of the preceding embodiments by executing the executable instructions.

[0048] According to an aspect of the present disclosure, a computer readable storage medium is provided, which stores a computer object program, and the computer object program is executed by a processor to implement the method according to any one of the preceding embodiments.

[0049] The technical solutions provided by the embodiments of the present disclosure can have the following beneficial effects:

[0050] In the data lazy loading method based on the GraphQL protocol for the iOS mobile terminal in the exemplary embodiments of the present application, the causal fence identifier obtained by parsing the stream fragment payload transmitted by the server is received, and the causal fence state corresponding to the fragment key value is established and maintained in the normalized cache of the client, so that the client has a verifiable condition for the inter-fragment dependency relationship when processing the fragments subsequently. When the causal fence state is input into the user interface hydration engine and the fragments in the waiting queue are checked in the user interface hydration engine, the trigger of the interface update is no longer dependent on the fixed time delay or blocking waiting, but is determined based on the established dependency state in the cache. Therefore, in the case of out-of-order arrival of fragments, only the fragments that meet the predetermined dependency closure will be submitted to the interface update transaction, thereby avoiding the interface rendering in the case of mispositioning of the parent-child hierarchy. At the same time, through the above checking and submitting process, the client can maintain consistent dependency chains between the cache and the interface update for the fragments returned gradually, so that the data submission across multiple fragments has a certain order. This submission method based on dependency checking can effectively avoid the temporary flicker and error state rendering of the interface when dealing with interleaved fragment transmission, thereby ensuring the stability and continuity of the interface display while meeting the gradual loading requirement.

[0051] It should be understood that the foregoing general description and the following detailed description are only exemplary and explanatory, and are not limiting to the present disclosure. BRIEF DESCRIPTION OF DRAWINGS

[0052] The accompanying drawings, which are incorporated into and form part of the specification, illustrate embodiments consistent with the present disclosure and, together with the specification, serve to explain the principles of the present disclosure. Obviously, the drawings in the following description are only some embodiments of the present disclosure, and other drawings can be obtained by those skilled in the art without creative labor on the basis of these drawings.

[0053] Figure 1 A system architecture diagram of the data lazy loading method based on the GraphQL protocol for the iOS mobile terminal to which the embodiments of the present disclosure can be applied is shown.

[0054] Figure 2 A flowchart of the data lazy loading method based on the GraphQL protocol for the iOS mobile terminal in the embodiments of the present disclosure is shown.

[0055] Figure 3 A schematic diagram of a data lazy loading system based on the GraphQL protocol for the iOS mobile terminal in the embodiments of the present disclosure is shown.

[0056] Figure 4A structural diagram of an electronic device suitable for implementing embodiments of the present disclosure is shown.

[0057] In the drawings, like or corresponding elements are denoted by like or corresponding reference numerals. DETAILED DESCRIPTION

[0058] The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of this specification. As used in this specification, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and / or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0059] It will be understood that, although the terms first, second, third, etc. can be used herein to describe various information, the information should not be limited to these terms. These terms are used only to distinguish one piece of information from another. For example, a first information can also be termed a second information, and, similarly, a second information can also be termed a first information, without departing from the scope of the present specification. The word "if' as used herein means "when" or "upon" or "in response to the determination" depending on the context.

[0060] Figure 1 A system architecture diagram of an iOS mobile terminal-oriented data lazy loading method based on a GraphQL protocol is shown.

[0061] As Figure 1 shown, the system architecture 100 can include one or more of terminal devices, such as a smartphone 101, a portable computer 102, a desktop computer 103, a network 104, and a server 105. The network 104 is a medium for providing a communication link between the terminal devices and the server 105. The network 104 can include various connection types, such as wired, wireless communication links, or fiber optic cables, etc.

[0062] It should be understood that Figure 1 the number of terminal devices, networks, and servers in the system architecture 100 is only illustrative. Any number of terminal devices, networks, and servers can be provided as needed. For example, the server 105 can be a server cluster composed of multiple servers, etc.

[0063] The data lazy loading method based on the GraphQL protocol for iOS mobile devices provided in this embodiment can be executed by a terminal device, and correspondingly, the data lazy loading system based on the GraphQL protocol for iOS mobile devices can be set in the terminal device. However, those skilled in the art will readily understand that the data lazy loading method based on the GraphQL protocol for iOS mobile devices provided in this embodiment can also be executed by the server 105, and correspondingly, the data lazy loading system based on the GraphQL protocol for iOS mobile devices can also be set in the server 105. This exemplary embodiment does not impose any special limitations on this.

[0064] This disclosure first provides a data lazy loading method based on the GraphQL protocol for iOS mobile devices. The method is then described below using server execution as an example.

[0065] Figure 2 The flowchart illustrating an embodiment of the present disclosure provides a data lazy loading method based on the GraphQL protocol for iOS mobile devices. (Reference) Figure 2 As shown, the method may include steps S210 to S240:

[0066] In step S210, the server receives the stream segment payload transmitted based on the GraphQL protocol and parses the causal fence identifier from the stream segment payload.

[0067] In step S220, based on the causal barrier identifier, a causal barrier state is established and maintained in the client's normalized cache for the key value corresponding to the stream segment;

[0068] In step S230, the causal barrier state is input to the user interface hydration engine of the client, and the causal barrier is verified on the segments in the waiting queue in the user interface hydration engine.

[0069] In step S240, when the causal barrier check satisfies the dependency closure, the corresponding user interface update transaction is submitted using the user interface hydration engine.

[0070] The following will provide a detailed description of the data lazy loading method based on the GraphQL protocol for iOS mobile devices in this example embodiment.

[0071] In step S210, a stream segment payload transmitted by the server based on the GraphQL protocol is received, and a causal fence identifier is parsed from the stream segment payload.

[0072] In this example implementation, a streaming fragment payload refers to a unit of data transmitted by the server during lazy loading or streaming responses, according to GraphQL semantics. This unit typically includes field paths, object identifiers, field values, and additional metadata. Because GraphQL's execution semantics allow for segmented returns of results within a tree-like object graph, this streaming fragment payload is often a subtree of the overall object graph. To ensure proper sequencing of fragments on the client side, causal barrier identifiers representing dependencies need to be introduced into this payload.

[0073] During the parsing process, this example implementation first extracts pattern path information from the stream fragment payload. Pattern path information refers to the hierarchical path corresponding to the fragment in the GraphQL schema, typically represented as a sequence of field accesses starting from the root type, such as "Query.user.friends.edges.node". This path information can be obtained through pre-defined path fields in the payload or derived by recursively traversing the payload structure. In a specific implementation, the client can use a recursive descent parser to parse the field names in the JSON structure level by level and generate a complete path string using delimiters; alternatively, a hash table mapping method can be used to number each level of the path, thereby obtaining a compact path representation; this exemplary embodiment does not impose any special limitations on this approach.

[0074] After obtaining the pattern path information, a dependency closure description related to parent-child dependencies can be generated based on this information. The principle of dependency closure description is that the renderability of each fragment depends not only on its own data fields but also on the existence of upper-level object nodes. Therefore, it is necessary to include the key values ​​of all parent nodes in the object graph of the fragment into the dependency set. In this example implementation, it can be formally represented as follows: for a path P = {n0, n1, ..., n_k}, where n0 is the root node and n_k is the fragment node, then the dependency closure C(P) = {Key(n0), Key(n1), ..., Key(n_{k-1})}. In a specific implementation, the client can construct the dependency set while parsing the path and generate a unique key value for each parent node. The unique key value can be formed by concatenating the object type name and the object identifier, such as "User:1234". Furthermore, to improve retrieval efficiency, in this example implementation, the dependency closure can be stored as an ordered array or a hash-based collection structure.

[0075] After obtaining the dependency closure description, a logical clock component containing parent key version vectors can be constructed based on the dependency closure description. The introduction of logical clocks ensures that the causal order of different segments can still be compared even when multiple segments arrive interleaved. Specifically, a version number is assigned to each parent key in the dependency closure, and this version number can be incremented and maintained by the server when generating segments. For example, for the dependency closure C(P) = {k1, k2, k3}, a version vector V = (v1, v2, v3) can be defined, where v i Key k i The version value. This logical clock component operates on the same principle as vector clocks in distributed systems, used to identify partial order relationships between events. In its implementation, when a client receives a fragment payload, it can directly read the attached version field or map it to an integer version number based on the update timestamp attached by the server.

[0076] In this example implementation, while constructing the version vector, it is also necessary to calculate the digest value of the parent key version vector. The digest value serves to compress the entire vector and perform fast verification. For example, a lightweight hash function, such as FNV-1a or MurmurHash, can be used to hash the version vector. For instance, if the version vector is serialized into a byte array b[], then the digest value H = Hash(b[]). In scenarios with high performance requirements, a bitwise XOR combination can be used: It should be noted that although such summaries may generate conflicts, their computational overhead is extremely low, sufficient for rapid consistency comparison on the client side.

[0077] Subsequently, the logical clock component and the digest value are combined to form an intermediate identifier. Specifically, the version vector V and the digest value H can be concatenated into a structure, such as {vector:V, hash:H}. This intermediate identifier has a fixed field format on the client side, facilitating subsequent serialization and transmission. Furthermore, to reduce bandwidth overhead, the intermediate identifier can also employ compression encoding, for example, storing the difference values ​​of the version vector as variable-length integers, while only transmitting newly added or changed parent key indices.

[0078] Finally, the intermediate identifier is serialized to obtain the causal barrier identifier. In this example implementation, compact binary encoding methods such as JSON serialization, Protocol Buffers, or CBOR can be used for specific implementation. Taking JSON as an example, the causal barrier identifier can be represented as:

[0079]

[0080] In Protocol Buffers encoding, the key index can be mapped to an integer, the version value to a variable-length integer, and the digest value to a fixed-length byte array, thereby reducing the amount of data transmitted. Different serialization methods can achieve the same logic and are interchangeable implementations; therefore, this exemplary embodiment does not impose any special limitations on them.

[0081] Step S220: Based on the causal barrier identifier, establish and maintain the causal barrier state for the key value corresponding to the stream segment in the normalized cache of the client.

[0082] In this example implementation, when establishing and maintaining causal barrier states for the key-value pairs corresponding to the stream fragments in the client's normalized cache, the uniqueness of the objects needs to be determined first. For this, the object type name, object identifier, and schema path need to be read from the stream fragment payload. The object type name typically corresponds to the type definition in the GraphQL schema, such as "User," "Post," or "Comment," and its purpose is to identify the data category to which the fragment belongs. The object identifier is the specific instance number under that category, often assigned by the backend service when generating data, such as a database primary key or a globally unique ID. In the JSON representation of the stream fragment payload, the type name and identifier can be stored as nested fields or returned as extended meta fields. The schema path is used to characterize the object's hierarchical position in the request results, such as "Query.user.posts.edges.node," which the client can obtain by traversing the preset path fields in the fragment structure.

[0083] After obtaining the above three elements, the object type name, object identifier, and pattern path can be concatenated using a predetermined separator to form the key value. In this example implementation, the core of the key value design lies in uniquely indexing each object fragment in the normalized cache to avoid duplicate storage and conflicts. The concatenation method can be direct string concatenation, for example, Key = type name + ":" + identifier + "@" + pattern path. For example, for the User type, identifier 1234, and path "Query.user.friends", the resulting key value is "User:1234@Query.user.friends". In actual implementation, a string constructor can be used, such as:

[0084] let key="\(typeName):\(identifier)@\(path)"

[0085] In some exemplary embodiments, to improve performance, the aforementioned key-value pairs can also be converted into hash representations, such as using SHA-1, MurmurHash, or CityHash, to compress long strings into fixed-length byte arrays. Hash values ​​not only reduce storage space but also speed up lookup operations. In many other implementations, a dual-index structure of plaintext and hash keys can be retained to allow the use of readable strings during debugging and efficient hashing at runtime.

[0086] Once the key-value pair is generated, a record corresponding to that key-value pair can be created in the normalized cache. In this example implementation, the normalized cache refers to breaking down the GraphQL response data into a flat storage structure with key-value pairs as the primary keys, allowing each object or fragment to be directly located using its key-value pair. To achieve this functionality, the cache in this example implementation can use a dictionary structure, such as a Dictionary in Swift.<String,CacheRecord> The key is the concatenated string mentioned above, and the value is the corresponding cached record object. When creating a record, it is first necessary to check whether the key-value pair already exists. If it does not exist, a new record instance is created and inserted into the cache; if it already exists, it needs to be updated based on the existing record. At the data structure level, it can be designed as follows:

[0087] struct CacheRecord{

[0088] var fields:[String:Any]

[0089] var causalFence:FenceState

[0090] var timestamp:Int64

[0091] }

[0092] The fields are used to store the field data in the fragment, causalFence is the causal fence status field, and timestamp records the write time for version comparison.

[0093] After a record is created, a causal barrier identifier can be written to the barrier state field of that record. In this example implementation, the causal barrier identifier may contain a logical clock component and a dependency digest, which the client needs to parse into a cacheable structure. For example, define:

[0094] struct FenceState{

[0095] var vectorClock:[String:Int]

[0096] var hashValue:UInt64

[0097] }

[0098] Here, `vectorClock` maps parent keys to version numbers, and `hashValue` is the digest value. Write operations can be implemented through simple assignment:

[0099] record.causalFence=parsedFenceState

[0100] This fence status field is used later to verify the submission order of fragments, so it must correspond one-to-one with each fragment.

[0101] Finally, the fence state field can be persisted to local storage to ensure that the dependency information between fragments is maintained even after application restart or memory release. In this example implementation, the persistence method can be implemented in various ways, such as using an SQLite database to store the key value, logical clock component, and digest value as columns of a table; or using a key-value storage system such as LevelDB, Realm, or CoreData to store the key value as the primary key, etc. For example, in a specific implementation, SQL statements can be used:

[0102] INSERT OR REPLACE INTO FenceTable(cacheKey,vectorClock,hashValue,timestamp)

[0103] VALUES(?,?,?,?);

[0104] The vectorClock can be serialized into a JSON string or a binary blob. In some embodiments, the cached dictionary can also be directly serialized into a binary file and written to disk, for example, using PropertyListEncoder or JSONEncoder. Furthermore, to ensure the atomicity of the write operation, a temporary file can be written and then overwritten to avoid file corruption due to crashes during the write process.

[0105] It's important to note that persistence methods can be flexibly replaced in different implementation environments. For example, in performance-critical scenarios, a memory-mapped file approach can be chosen, such as mapping the entire cache to a disk file, allowing persistence through memory write operations. In compatibility-critical scenarios, the Core Data framework can be used to manage FenceState objects in an object-oriented manner. Regardless of the method used, the key is to ensure that the fence state fields can be accurately restored to support subsequent causal verification.

[0106] Step S230: Input the causal barrier state into the user interface hydration engine of the client, and perform causal barrier verification on the segments in the waiting queue in the user interface hydration engine.

[0107] In this example implementation, when performing causal barrier verification on fragments in the waiting queue within the user interface hydration engine, a computationally calculable and reproducible verification context can first be established on the hydration engine side. The user interface hydration engine refers to the client-side processing module used to submit fragment data from the normalized cache to the interface layer. The verification context refers to the complete set of states related to fragment dependencies read from the normalized cache, consisting of a parent key set P, a corresponding version vector V, and a digest H generated for that vector. The verification context can be represented as a triple.<P,V,H> Where P = {k1, k2, ..., k□}, V = {v1, v2, ..., v□}, and H = Hash(V). In client-side implementations, to ensure consistency in concurrent environments, context verification typically relies on a read-only snapshot mechanism to avoid interference from write operations by other threads during construction. Furthermore, on the iOS platform, this can be achieved through a serial scheduling queue or Multi-Version Concurrency Control (MVCC), making context generation logically atomic.

[0108] When inputting a causal barrier state, the Hydration Engine can match externally provided barrier information with existing states in the cache. Specifically, the client locates the cache record using the key-value pair attached to the fragment, and reads the list of parent keys and the corresponding version number. Based on this, the Hydration Engine generates an internal object for comparison using the vector information and digest value in the causal barrier identifier. For example, in this sample implementation, it can be defined using the following Swift struct:

[0109]

[0110]

[0111] In this example implementation, when constructing vclock, each parent key needs to retrieve the latest version number from the cache. If a parent key has not yet appeared in the cache, it is assigned a value of 0 to maintain consistent vector length. The digest value can be generated using CRC32C or SipHash64, corresponding to two different focuses: fast computation and collision resistance, respectively. For example, when V = {5, 3, 7}, it is serialized into a byte array b = [0x05, 0x03, 0x07], and then SipHash is used to obtain H = 0x1A2B3C4D5E6F7788. In this example implementation, the digest value can be used not only for fast comparison but also to detect inconsistencies in advance during the verification process.

[0112] After generating the verification context, the Hybrid Engine reads the segments to be verified from the waiting queue. The purpose of the waiting queue is to store segments that have not yet passed causality verification and cannot be submitted to the UI. Its implementation can be a circular buffer, a linked list, or a heap structure. For example, in performance-sensitive mobile environments, a common practice is to use a fixed-capacity circular buffer to avoid the overhead of frequent memory allocation. Assuming the queue capacity is N, the head and tail can be indicated by two pointers, head and tail, respectively, and the time complexity of enqueue and dequeue operations is O(1). When multiple threads may access the database simultaneously, a lock-free queue or a circular array based on atomic CAS operations can be used to ensure concurrency safety, but this exemplary embodiment is not limited to these.

[0113] In this example implementation, when reading the fragment to be verified, the Hydration Engine first locates the head element of the queue and extracts the fragment reference and the causal barrier identifier carried by the fragment. This fragment structure may include key-value pairs, fragment field data, and an arrival timestamp. For example:

[0114]

[0115] After extracting the segment to be verified, the set of parent keys associated with the segment can be retrieved based on the causal barrier state. The generation of the parent key set can prioritize sorting by path depth from shallow to deep to ensure that dependencies are expressed in a topologically ordered form. For example, for the path Query.user.posts.edges.node.comment, the parent key set should be {Query, user:ID, posts:ID, edges:ID, node:ID}. Furthermore, during the retrieval process, each parent key needs to correspond to the version number in the cached record to form the basis for subsequent dependency sets.

[0116] After the parent key set retrieval is completed, a dependency set to be compared can be constructed based on the parent key set. The essence of the dependency set is to pair the parent key with its corresponding version number, forming a data structure that can be used for partial order comparison. In this example implementation, let the parent key set be P = {k1, k2, ..., k□}, then the dependency set D can be represented as D = { <k i ,v i >|k i ∈P}, where v i For the parent key k in the cache i The latest version number. In actual implementations, dependency collections are usually represented as dictionaries or arrays. For example, in Swift, the following code can be constructed:

[0117] let dependencySet=parents.map{(k)in(k,cache.version(for:k)??0)}

[0118] The `cache.version(for:)` method described above returns the version number of key `k`. If the version number does not exist, it returns the default value 0. This implementation ensures that each parent key in the dependency set corresponds to an integer version number, thus ensuring the integrity of the set. Furthermore, to ensure determinism in the comparison process, this example implementation can first deduplicate and sort the parent key set. The sorting rule is based on the path depth from smallest to largest; if the depths are the same, the keys are arranged in lexicographical order.

[0119] After constructing the dependency set, a verification result can be generated based on the dependency set and the causal barrier identifier carried by the fragment. In this example implementation, the core of the verification lies in determining whether the version vector V1 in the local dependency set covers and strictly precedes the version vector V in the fragment causal barrier identifier. f The formal expression is:

[0120] Condition one:

[0121] Condition two:

[0122] When both of the above conditions are met, the local dependency set can be considered to causally contain a fragment dependency, thus allowing that fragment to enter the subsequent transaction commit process. Furthermore, to improve efficiency, a quick comparison can be performed based on the digest value. Specifically, the digest H of the local dependency set is calculated. 1 =Hash(V) 1 [S]), where S is the set of parent key indices involved in the fragment causal fence identifier. If H 1 ≠H f If H fails, the verification can be immediately determined to have failed, without the need to perform a component-by-component comparison; 1 =H f If so, then a strict comparison at the component level will continue to be performed to avoid misjudgments caused by hash collisions.

[0123] For example, this example implementation can be represented using the following pseudocode:

[0124]

[0125]

[0126] The verification function guarantees that the vector alignment is completed in O(n) time, and the digest function can terminate early in most mismatch scenarios.

[0127] Furthermore, in other exemplary embodiments of this disclosure, exceptions can be handled during the verification process. For example, when a fragment is missing a partial parent key, a lenient matching strategy can be adopted, that is, only strict comparisons are performed on the keys carried by the fragment, while ignoring the missing parent keys; when the key contained in the fragment identifier does not exist in the local cache, the default version number is 0, but a potential missing event needs to be recorded for subsequent synchronization.

[0128] In a further example implementation, after the verification logic is completed, the capacity limit of the waiting queue can also be maintained in the user interface hydration engine. The purpose of setting the queue capacity limit is to prevent infinite fragment accumulation, which could lead to memory bloat or latency backlog. The capacity limit M can be a static constant or dynamically calculated. Dynamic calculation can be expressed as:

[0129]

[0130] in Where α is the absolute upper limit, F is the number of available free memory pages in the system, Q is the average dequeue rate of the queue over a recent period, and α and β are adjustment coefficients. This formula can adaptively adjust the queue capacity according to the system resource situation, thus balancing performance and resource consumption.

[0131] When the queue size exceeds its capacity limit, the hydration engine needs to trigger an eviction policy to remove some fragments. For example, the eviction policy could construct a sorting key `score = ...` based on causal dependency depth and arrival time.<depth,ts> Where depth represents the dependency depth of a fragment, which can be calculated by path hierarchy or the size of the dependency set; ts represents the arrival time of the fragment. Sorting is done first by depth in ascending order, then by ts in ascending order, thus placing fragments with deeper dependencies and earlier arrival times at the back of the queue as priority for elimination. For single-value sorting, a linear combination function can be used:

[0132] R = γ·depth + δ·Δt

[0133] Where Δt = now() - ts, and γ and δ are trade-off parameters.

[0134] At the implementation level, a min-heap can be used to maintain the sorting scores of fragments, and the top element of the heap is retrieved each time a fragment is evicted. Evicted fragments need to be recorded in a removal log table. Log entries can include a key, depth, arrival time, and summary value for subsequent diagnostics and statistics. The SQL representation is as follows:

[0135] INSERT OR REPLACE INTO DropLog(key,depth,arrival,digest)

[0136] VALUES(?,?,?,?);

[0137] Step S240: When the causal fence check satisfies the dependency closure, use the user interface hydration engine to submit a user interface update transaction for the corresponding fragment.

[0138] In this exemplary embodiment, first, determine the set of affected key values based on the fragment, and generate an interface change set with this set as the input. The set of affected key values has the fragment key value as the root, and combines the explicitly referenced fields in the fragment and the derived mappings in the normalized cache to obtain a closure set. For example, assume the fragment key is k0, then the affected set A satisfies A = {k0} ∪ Ref(k0) ∪ Dep(k0), where Ref(k) is the set of cache keys directly referenced within the fragment, and Dep(k) is the interface-level dependencies registered in the cache index (for example, a counted view depends on the set key of its child items). In a specific implementation, two types of mapping tables can be maintained: refIndex: CacheKey → [CacheKey] and depIndex: CacheKey → [CacheKey], construct A with a breadth-first strategy, and use an access bitmap to avoid duplicate access. For example, it can be implemented through the following code:

[0139]

[0140] In this exemplary embodiment, the order of the above set A can be further sorted according to the interface topology constraints to ensure the determinism of patch application. For example, define ord: as the topological order of the interface layer, satisfying that if view v_i depends on v_j, then ord(k_j) < ord(k_i). Furthermore, apply a stable sort to A, A' = sort(A, by: ord), to ensure that subsequent patch applications are performed from top to bottom.

[0141] When generating the interface change set based on the set of key values, for each k ∈ A', two versions of the field image can be read from the normalized cache: o_k is the snapshot field image at the time of transaction generation, and n_k is the current field image after fragment merging. To obtain the minimized difference, in this exemplary embodiment, define a field difference operator δ: (Map, Map) → Patch and dispatch by type: for a scalar field f, if o_k[f] ≠ n_k[f], then δ_k includes an assignment entry <f ← n_k[f]>; for an ordered list field L, perform list difference using a stable identifier id and output an insert / delete / move triple; for a nested object field, recursively call δ and merge the entries with a path prefix p. Let the interface change set

[0142] δ(o_k, n_k), where represents the union after path deduplication. For example, it can be implemented through the following code:

[0143]

[0144]

[0145] Furthermore, to enhance verifiability, this example implementation introduces a normalization function N(Δ) for the difference generation: it merges overlapping entries of the same path for set-type entries, retaining only the last write; and it arranges insert / delete / move entries according to lexicographical order and sequence stability, avoiding non-deterministic sorting. The difference product can be serialized into a compact representation:

[0146]

[0147] Where "k" represents the operation type, "p" represents the path, "v" represents the value or target bit, and "a" represents the auxiliary identifier.

[0148] In this example implementation, when binding the interface change set to a user interface update transaction, to ensure the correspondence between the transaction and the cache snapshot, a Compare-and-Swap (CAS) version mapping ver:CacheKey→Int can be used, which records the cache version of each key when generating the difference. For example, the transaction structure can be defined as follows:

[0149]

[0150] The transaction ID can be a combination of a timestamp and a random salt. The data is generated to ensure uniqueness. After a transaction is generated, its content is read-only and not modified to ensure transparent referencing. For move / insert operations related to lists, the position baseIndex(k) is appended within the transaction to avoid ambiguity in target bit calculation during concurrent reordering.

[0151] In this example implementation, when adding the user interface update transaction to the tail position of the transaction queue, the transaction queue is implemented as a lock-free circular buffer with constant enqueue and dequeue times or a main thread-private FIFO container. If a main thread-private container is used, enqueueing can be done by submitting a closure using `DispatchQueue.main.async` to append the transaction; if a lock-free circular buffer is used, entries can be written to the atomically incremented pointer `tail` and dequeued using `head`. To ensure coordination with the rendering timing, execution callbacks are registered on the main thread scheduler, which can be bound to the default mode of `RunLoop` or used to perform frame boundary callbacks using `CADisplayLink`. For example, this can be implemented using the following code:

[0152] final class TxnQueue{

[0153] private var q: [UIUpdateTxn] = []; private let lock = OSAllocatedUnfairLock()

[0154] func enqueue(_ t: UIUpdateTxn) { lock.withLock { q.append(t)}}

[0155] func dequeue() -> UIUpdateTxn? { lock.withLock { q.isEmpty? nil : q.removeFirst()}}

[0156] }

[0157] DispatchQueue.main.async {

[0158] RunLoop.current.perform { drain()} / / Next loop execution

[0159] }

[0160] To control the batch size and time slice, in this example implementation, an execution budget B_frame is defined, which can take the current frame rendering budget minus the reserve: B_frame = T_vsync - T_renderReserve. Before dequeueing and applying a transaction each time, estimate the transaction cost cost(txn). If Σcost(txn_i) ≤ B_frame, then continue with this frame; otherwise, postpone the remaining transactions to the next frame. The cost estimation can be weighted based on the number of patch items and control types: cost(txn) = α·|set| + β·|insert| + γ·|delete| + δ·|move|.

[0161] When the trigger condition is met, the user interface update transaction can be taken out from the transaction queue and the interface layer can be called to execute the user interface update transaction. To ensure the consistency of the application, a quick check of the CAS version of the transaction can be performed before execution: for k ∈ txn.affected, if currentVersion(k) < txn.ver[k], then postpone the transaction to wait for the progress of the dependent key; if currentVersion(k) > txn.ver[k], then trigger a rebase to resolve the snapshot drift. The rebase recalculates the difference δ*(o'_k, n_k) with the current cache image o'_k and the transaction target image n_k, and only replaces the relevant patch entries involving key k in the transaction, without touching other key patches. For example, it can be implemented through the following code:

[0162] func rebase(_txn:UIUpdateTxn,cache:Cache)->UIUpdateTxn{

[0163]

[0164] Furthermore, when performing patching at the interface layer, an adaptation layer can be provided for different UI technology stacks. For UIKit, batch transaction boundaries are used to reduce intermediate interruptions.

[0165] CATransaction.begin()

[0166] CATransaction.setDisableActions(true) / / Avoid implicit animation interference

[0167] applyPatchSet(txn.patch) / / Apply to each PatchOp individually

[0168] CATransaction.commit()

[0169] The `applyPatchSet` classifies the path `path = ["list", "3"]` as a view tree index, uses `ViewResolver` to map the `CacheKey` to a view instance, and performs specific assignments, insertions, deletions, and reorderings through type dispatch. List-type controls (such as `UICollectionView`) use native batching.

[0170]

[0171]

[0172] In this example implementation, for SwiftUI, patching can be done by binding to a model layer object and triggering property writes using `@State` or `@ObservedObject`. To maintain consistency with the path semantics of the patch, the model layer provides a `subscript(path:)` accessor:

[0173] model[path:op.path]=op.value

[0174] After writing, the SwiftUI framework completes the view recalculation and redraw, and the caller does not directly manipulate the view nodes.

[0175] Furthermore, in this example implementation, a view layer "commit barrier" can be configured to control the atomicity of patch application. The commit barrier increments a counter `commitDepth += 1` at the start of each transaction and decrements it afterward. Any derived UI updates are only allowed to be postponed to the end of the current transaction if `commitDepth > 0`, to avoid listener callbacks caused by intermediate patch states. In implementation, a "deferred event table" can be maintained in the adaptation layer, and events are dispatched uniformly when the counter reaches zero. For assignments requiring animation, they are uniformly encapsulated using `UIViewPropertyAnimator`.

[0176]

[0177] It should be noted that when the time budget is insufficient, animations can be disabled and replaced with direct assignment to meet the execution budget constraints.

[0178] Furthermore, in cases where application failure occurs (e.g., view has been released, index out of bounds), this example implementation can perform a rollback to undo some of the modifications already applied by the current transaction. Rollback can be implemented based on a "pre-image snapshot": before applying each PatchOp, the old value `preImage[path] = valueBefore` is recorded at the modified location; when an exception occurs, `preImage` is traversed in reverse order to write back the old value, restoring the state before the transaction began.

[0179]

[0180]

[0181] For list-type operations, rollback corresponds to the reverse insertion / deletion / movement (e.g., rollback of insert is delete with the same index; rollback of move(i→j) is move(j→i)). In addition, to ensure consistency, the adaptation layer prohibits new transactions from entering and executing after entering rollback mode until the rollback is complete.

[0182] Furthermore, in situations where multiple transactions arrive concurrently, the execution layer can employ key conflict merging.

[0183] For example, it can be defined If there are no conflicts, applications can be applied in parallel within the same frame (in UIKit, this is limited by the main thread, specifically manifested as sequential and fast execution); if conflicts exist, they are executed in the order of min(txn.ts), and the transaction after the conflict is aligned with the current state through the aforementioned CAS or rebase mechanism. Furthermore, to reduce redundant work, multiple set operations on the same path within a short time window can be aggregated using a hash table coalesce[key] during enqueueing, retaining only the last written value. The merging rule does not merge insert / delete / move operations across transactions to maintain order.

[0184] In this example implementation, a ternary trigger (N, Δt, Idle) can be established to determine the triggering condition for transaction execution. Here, N is the threshold for the number of transactions to be executed, Δt is the time interval since the last execution, and Idle is the main thread's idle flag. The determination function is Trigger = (QueueSize≥N)∨(now()-lastExec≥Δt)∨Idle, which prioritizes execution when the main thread is idle to reduce competition with rendering; when there is a backlog of transactions, the constraints of N and Δt ensure throughput. To implement Idle detection, RunLoopObserver can be used to listen for the beforeWaiting event, or the DispatchSourceUserDataAdd signal can be used to simulate an idle callback.

[0185] Furthermore, regarding transaction sharding under resource constraints, this example implementation can also define a "transaction slicer" to decompose a large patch into [patch1, patch2, ...], where the estimated cost of each slice, cost(patch_i), is ≤ B_slice, and slices are committed sequentially within consecutive frames. Slice boundaries follow path prefix consistency: operations on the same list node remain within the same slice, avoiding cross-frame misalignment. The sharding algorithm approximates a greedy approach using operation counting.

[0186]

[0187]

[0188] To ensure idempotency and reentrancy, in this example implementation, each chip can be appended with txn.id and its intra-chip index i before application. The adaptation layer maintains the last successfully applied chip.<txn.id,i> The cursor skips completed segments when called repeatedly.

[0189] Regarding interface adaptation details, this example implementation uses safe writing of text and image update path configuration types: text uses `UILabel.text = String`, and localization and layout preprocessing (e.g., NSAttributedString style composition) are performed before writing; images use a placeholder to target image switching method, and size and color gamut adaptation are performed before writing. List reordering is achieved through snapshot application of `UICollectionViewDiffableDataSource`.

[0190] var snapshot=NSDiffableDataSourceSnapshot<Section,Item> ()

[0191] snapshot.appendSections([.main])

[0192] snapshot.appendItems(items) / / The items are rearranged according to the patch sequence.

[0193] dataSource.apply(snapshot,animatingDifferences:false)

[0194] For views requiring a jitter-free layout, lock layout metrics (such as cell height) before applying the patch and unlock them afterward. Locking is achieved by returning a fixed size in the relevant cell's preferredLayoutAttributesFitting or temporarily disabling adaptive constraint solving.

[0195] Regarding the observation and diagnosis of the execution path, this example implementation establishes a tracking point for each transaction to record the latency from generation to application L = t_apply - t_ts, the patch length |Δ|, and the number of retries r.

[0196] os_signpost(.begin,log:log,name:"UIUpdateTxn",signpostID:sid(txn.id),"len=%d",txn.patch.count)

[0197] / / ...apply...

[0198] os_signpost(.end,log:log,name:"UIUpdateTxn",signpostID:sid(txn.id))

[0199] The above records are used to analyze the relationship between transaction size and execution time without changing the execution semantics, so as to provide a quantitative reference when adjusting queue and budget parameters (such as α, β, γ, δ, B_frame).

[0200] It should be noted that in other exemplary embodiments of this disclosure, the generation of the interface change set may not use per-field differencing, but instead employ a "snapshot replacement" strategy. For example, a single operation of set(path, blob) may replace complex nested path differencing, where blob is structured serialized data. This approach is simple to implement, with the adaptation layer performing only one overall write, but it increases the rendering workload for lists and deep objects. Another example is the use of virtual tree recalculation, where minimal rendering instructions are generated by comparing the key and props of the virtual node (VNode). In this case, the patch does not directly affect cached fields but rather virtual tree attributes, ultimately being mapped by the renderer to the specific view API. This is equivalent to changing the path field of the aforementioned PatchOp from the cached path to the virtual tree path, and these also fall within the scope of this disclosure.

[0201] In the exemplary embodiment of this application, the data lazy loading method based on the GraphQL protocol for iOS mobile devices, by parsing the causal barrier identifier obtained after receiving the streaming segment payload transmitted by the server, and establishing and maintaining the causal barrier state corresponding to the segment key-value in the client's normalized cache, the client has verifiable conditions for the dependencies between segments when processing segments subsequently. When the causal barrier state is input to the user interface hydration engine and the segments in the waiting queue are verified therein, the triggering of the interface update no longer depends on a fixed delay or blocking wait, but is determined based on the dependency state already established in the cache. Thus, in the case of out-of-order arrival of segments, only segments that satisfy the predetermined dependency closure will be submitted to the interface update transaction, thereby avoiding interface rendering in the case of parent-child hierarchy misalignment. At the same time, through the above verification and submission process, the client can maintain a consistent dependency chain between the cache and the interface update for the progressively returned segments, so that the data submission across multiple segments has a definite order. This dependency-based submission method can effectively avoid brief screen flickering and error rendering when dealing with interleaved fragment transmission, thus ensuring the stability and continuity of the interface display while meeting the needs of gradual loading.

[0202] This example implementation also provides a data lazy loading system based on the GraphQL protocol for iOS mobile devices. (See reference) Figure 3 As shown, the order processing and logistics tracking system 300 may include a causal barrier parsing module 310, a status maintenance module 320, a verification module 330, and a user interface update module 340. Wherein:

[0203] According to one aspect of this disclosure, a data lazy loading system based on the GraphQL protocol for iOS mobile devices is provided, comprising:

[0204] The causal barrier resolution module 310 is configured to receive a stream segment payload transmitted by the server based on the GraphQL protocol, and to parse out the causal barrier identifier from the stream segment payload;

[0205] The state maintenance module 320 is configured to establish and maintain the causal barrier state for the key-value pair corresponding to the stream segment in the client's normalized cache based on the causal barrier identifier.

[0206] The verification module 330 is configured to input the causal barrier state to the user interface hydration engine of the client, and to perform causal barrier verification on the segments in the waiting queue in the user interface hydration engine.

[0207] The user interface update module 340 is configured to submit a user interface update transaction for the corresponding fragment using the user interface hydration engine when the causal barrier check satisfies the dependency closure.

[0208] The specific details of each module of the data lazy loading system based on the GraphQL protocol for iOS mobile devices have been described in detail in the corresponding data lazy loading method based on the GraphQL protocol for iOS mobile devices, so they will not be repeated here.

[0209] Exemplary embodiments of this disclosure also provide a computer-readable storage medium having a program product stored thereon capable of implementing the methods described above in this specification. In some possible embodiments, various aspects of this disclosure may also be implemented as a program product including program code that, when the program product is run on an electronic device, causes the electronic device to perform the steps described in the "Exemplary Methods" section of this specification according to the various exemplary embodiments of this disclosure.

[0210] The program product may be a portable compact disc read-only memory (CD-ROM) and include program code, and may run on an electronic device, such as a personal computer. However, the program product disclosed herein is not limited thereto. In this document, the readable storage medium may be any tangible medium that contains or stores a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0211] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0212] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0213] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0214] Program code for performing the operations of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C#, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0215] Furthermore, exemplary embodiments of this disclosure also provide an electronic device capable of implementing the above-described data lazy loading method based on the GraphQL protocol for iOS mobile devices.

[0216] The following reference Figure 4 To describe an electronic device 400 according to such an embodiment of the present disclosure. Figure 4The electronic device 400 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0217] like Figure 4 Figure 4 As shown, the electronic device 400 is manifested in the form of a general-purpose computing device. The components of the electronic device 400 may include, but are not limited to: at least one processing unit 410, at least one storage unit 420, a bus 430 connecting different system components (including storage unit 420 and processing unit 410), and a display unit 440.

[0218] Storage unit 420 stores program code that can be executed by processing unit 410, causing processing unit 410 to perform the steps described in the "Exemplary Methods" section above according to various exemplary embodiments of this disclosure. For example, processing unit 410 can perform method steps in exemplary embodiments of this disclosure.

[0219] Storage unit 420 may include readable media in the form of volatile storage units, such as random access memory (RAM) 421 and / or cache memory (Cache) 422, and may further include read-only memory (ROM) 423.

[0220] Storage unit 420 may also include a program / utility 424 having a set (at least one) of program modules 425, such program modules 425 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0221] Bus 430 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0222] Electronic device 400 can also communicate with one or more external devices 700 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 400, and / or with any device that enables electronic device 400 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 450. Furthermore, electronic device 400 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 460. As shown, network adapter 460 communicates with other modules of electronic device 400 via bus 430. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 400, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0223] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0224] Furthermore, the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of this disclosure and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0225] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

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

[0227] It should be understood that this disclosure is not limited to the precise structures 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 disclosure is limited only by the appended claims.

Claims

1. A data lazy loading method based on the GraphQL protocol for iOS mobile devices, characterized in that, include: Receive the stream segment payload transmitted by the server based on the GraphQL protocol, and parse the causal barrier identifier from the stream segment payload; Based on the causal barrier identifier, a causal barrier state is established and maintained in the client's normalized cache for the key-value pair corresponding to the stream segment; The causal barrier state is input to the user interface hydration engine of the client, where causal barrier verification is performed on the segments in the waiting queue. When the causal barrier check satisfies the dependency closure, the corresponding user interface update transaction is submitted using the user interface hydration engine.

2. The method according to claim 1, characterized in that, The process of resolving the causal fence identifier from the stream segment load includes: Extract pattern path information from the stream segment payload, and generate a dependency closure description related to parent-child dependency based on the pattern path information; Based on the dependency closure description, a logical clock component containing the parent key version vector is constructed, and a summary value of the parent key version vector is calculated. The logical clock component and the digest value are combined into an intermediate identifier, and the intermediate identifier is serialized to obtain the causal fence identifier.

3. The method according to claim 1, characterized in that, The step of establishing and maintaining a causal barrier state for the key-value pair corresponding to the stream segment in the client's normalized cache includes: Read the object type name from the stream segment payload, read the object identifier from the stream segment payload, and read the mode path from the stream segment payload; The object type name, the object identifier, and the pattern path are concatenated using a predetermined separator to form the key value; Create a record corresponding to the key-value pair in the normalized cache; Write the causal fence identifier into the fence status field of the record, and persist the fence status field to local storage.

4. The method according to claim 1, characterized in that, The step of inputting the causal barrier state to the client's user interface hydration engine, and performing causal barrier verification on segments in the waiting queue in the user interface hydration engine, includes: Read the segment to be verified from the waiting queue, and retrieve the set of parent keys associated with the segment to be verified based on the causal barrier state; Construct a dependency set to be compared based on the parent key set; A verification result is generated based on the dependency set and the causal barrier identifier.

5. The method according to claim 1, characterized in that, The causal barrier check performed on segments in the waiting queue in the user interface hydration engine also includes: Set a capacity limit for the waiting queue; When a new fragment is received, the fragment is added to the waiting queue; When the waiting queue reaches the capacity limit, a sorting key is generated based on the causal dependency depth and arrival time, and the waiting queue is sorted according to the sorting key; Select the segment at the tail of the sort as the removal object, delete the removal object from the waiting queue, and write the key-value pair of the segment to be removed into the removal record.

6. The method according to claim 1, characterized in that, Submitting a user interface update transaction for the corresponding segment using the user interface hydration engine includes: Based on the fragment, determine the set of affected key values ​​and generate a set of interface changes based on the set of key values; Bind the interface change set into a single user interface update transaction; The user interface update transaction is added to the tail of the transaction queue, and the execution callback of the transaction queue is registered on the main thread scheduler. When the triggering condition is met, the user interface update transaction is retrieved from the transaction queue and the interface layer is invoked to execute the user interface update transaction.

7. The method according to claim 6, characterized in that, The generation of the interface change set based on the key-value set includes: Traverse the set of key-value pairs and read the data fields corresponding to each key-value pair from the normalized cache; A difference patch is generated based on the data fields, and the difference patch is added to the interface change set.

8. A data lazy loading system based on the GraphQL protocol for iOS mobile devices, characterized in that, include: The causal barrier resolution module is configured to receive a stream segment payload transmitted by the server based on the GraphQL protocol, and to parse out the causal barrier identifier from the stream segment payload; The state maintenance module is configured to establish and maintain the causal barrier state for the key-value pair corresponding to the stream segment in the client's normalized cache based on the causal barrier identifier. The verification module is configured to input the causal barrier state to the user interface hydration engine of the client, and to perform causal barrier verification on the segments in the waiting queue in the user interface hydration engine. The user interface update module is configured to submit a user interface update transaction for the corresponding fragment using the user interface hydration engine when the causal barrier check satisfies the dependency closure.

9. An electronic device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to execute the method of any one of claims 1-7 by executing the executable instructions.

10. A computer-readable storage medium having a computer object program stored thereon, characterized in that, When the computer target program is executed by the processor, it implements the method described in any one of claims 1-7.

Images