Native Application Load Signal Generation for Crawling

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing search systems face inefficiencies in determining when native applications are sufficiently instantiated for crawling and indexing operations, leading to resource wastage and potential omission of information due to reliance on fixed timeouts and incomplete loads.

Innovation Solution

Monitoring activity lifecycle events and memory footprint changes to generate a load signal indicating when a native application is sufficiently instantiated for crawling, eliminating the need for fixed timeouts and allowing for more efficient resource utilization and reduced system maintenance.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If fixed timeout is used to determine application instantiation completion, then system operation is simplified, but resource efficiency decreases and information omission increases

Engineering Contradiction:
Improvesystem operation simplicityVSAvoidresource efficiency
Core Design Contradiction:
Ease of operationVSProductivity

Solution Approach 1:

The system implements feedback mechanisms by monitoring activity lifecycle events and memory footprint changes to dynamically determine when application instantiation is complete. This replaces fixed timeout with adaptive monitoring that provides feedback about actual application state, improving resource efficiency while maintaining operational simplicity through automated detection.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The application instance effectively self-announces its readiness by generating observable events (lifecycle events and memory footprint changes) that the monitoring system detects. This self-service approach eliminates the need for external timeout management and allows the system to automatically determine instantiation completion based on the application's own behavior.

Inventive Principle:
Principle #25Self-service

2Device complexity

If fixed timeout is used to determine application instantiation completion, then implementation is simpler, but crawling accuracy decreases

Engineering Contradiction:
Improveimplementation complexityVSAvoidcrawling accuracy
Core Design Contradiction:
Device complexityVSReliability

Solution Approach 1:

The monitoring system uses feedback from activity lifecycle events and memory footprint changes to accurately determine when crawling should begin. This feedback mechanism ensures that crawling only starts when the application is truly ready, improving crawling accuracy without significantly increasing implementation complexity since the events are naturally generated by the application.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The system performs preliminary monitoring of application behavior before initiating crawling operations. By watching for specific events and memory patterns beforehand, the system ensures the application is fully instantiated and ready for accurate crawling, preventing information omission while maintaining reasonable implementation complexity.

Inventive Principle:
Principle #10Preliminary action

3Reliability

If monitoring of requests, lifecycle events, and memory footprint is performed, then crawling accuracy improves, but system complexity increases

Engineering Contradiction:
Improvecrawling accuracyVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The monitoring system is segmented into distinct components: one monitoring activity lifecycle events and another monitoring memory footprint changes. This segmentation allows each component to focus on specific indicators, improving crawling accuracy through comprehensive monitoring while managing system complexity by dividing the monitoring function into manageable, independent modules.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The monitoring system serves multiple functions simultaneously: it tracks application state for crawling timing, generates load signals when ready, and provides information for resource management decisions. This multi-functionality improves crawling accuracy while justifying the increased system complexity through the value of consolidated monitoring capabilities.

Inventive Principle:
Principle #6Universality (Multi-functionality)

4Device complexity

If fixed timeout is used for application instantiation, then resource allocation is simpler, but time efficiency decreases

Engineering Contradiction:
Improveresource allocation simplicityVSAvoidtime efficiency
Core Design Contradiction:
Device complexityVSLoss of time

Solution Approach 1:

The system uses feedback from real-time monitoring of application events and memory usage to dynamically allocate crawling resources. This eliminates wasted time from premature or delayed crawling by ensuring resources are allocated exactly when the application is ready, improving time efficiency while maintaining reasonable resource allocation complexity through event-driven triggering.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The resource allocation system transitions from static fixed timeout to dynamic event-driven allocation. Resources are allocated based on real-time application state changes rather than predetermined time intervals, improving time efficiency by matching resource availability with actual application readiness while managing complexity through automated state detection.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentEP3251013B1Monitoring application loading
Publication Date: 2018.12.05 GOOGLE LLC
  • EP3251013B1 patent drawingFigure 1
  • EP3251013B1 patent drawingFigure 2
  • EP3251013B1 patent drawingFigure 3

AI summary

Methods, systems, and apparatus, for determining when an application is sufficiently instantiated to be subject to a crawling operation. In an aspect, a method includes instantiating a native application instance that generates environment instances for display on a user device within the native application instance; in response to the instantiation of the native application instance: monitoring for occurrences of activity lifecycle events of the native application instance, monitoring for changes in a memory footprint of the native application instance, and generating, in response to the monitoring of the lifecycle events and monitoring of the changes in the memory footprint indicating the native application instance is sufficiently instantiated to be subject to a crawling operation, a load signal indicating the native application instance is sufficiently instantiated to be subject to the crawling operation.