Performance, Reliability, and Resource Optimization

Introduction

A mobile application competes for finite CPU time, memory, network capacity, storage, thermal headroom, and battery energy. Unlike a desktop application, it must also tolerate intermittent connectivity, operating-system suspension, diverse hardware, and rapid changes in screen refresh rate. Performance engineering therefore concerns more than making code execute quickly. It seeks predictable responsiveness, efficient resource use, resilience, and evidence that these properties persist in production.

React Native and Flutter use different runtime architectures, but the engineering method is similar: define user-centred objectives, measure realistic workloads, locate the dominant bottleneck, make one controlled change, and verify the result. Unmeasured “optimizations” can increase complexity without improving user experience.

Learning Objectives

After studying this chapter, students should be able to:

• establish measurable performance and reliability objectives;
• profile startup, rendering, CPU, memory, network, storage, battery, and application size;
• diagnose dropped frames, excessive allocation, memory leaks, and main-thread blocking;
• apply concurrency without introducing races or excessive communication overhead;
• implement lazy loading, caching, batching, pagination, and image optimization;
• design retries, timeouts, idempotency, circuit breakers, and offline behaviour;
• use Flutter DevTools, React Native profiling facilities, Perfetto, Android Studio Profiler, Xcode Instruments, and size analyzers;
• instrument production applications while protecting user privacy; and
• evaluate optimization work through controlled experiments and percentile metrics.

1. Performance as a System Property

Performance emerges from interactions among application code, frameworks, native platform services, networks, back-end systems, and devices. A slow screen may result from an inefficient widget tree, an oversized image, synchronous storage, server latency, garbage collection, or thermal throttling. Consequently, profiling should begin with a complete transaction rather than a preferred layer.

A useful performance cycle is:

Figure: Evidence-driven mobile performance optimization cycle.

1.1 Service-level indicators and budgets

A service-level indicator (SLI) is a measured property, such as warm-start latency, crash-free sessions, or frame render time. A service-level objective (SLO) states a target, such as “95% of warm starts reach an interactive home screen within 1.2 seconds on supported mid-range devices.”

Averages hide tail behaviour. If most requests take 100 ms but a few take 5 seconds, the mean may appear acceptable while users experience stalls. Report the median and upper percentiles—commonly p90, p95, and p99—together with sample size and device/network segments.

Useful mobile indicators include:

Measurements must state conditions: build mode, device, operating system, refresh rate, battery state, network profile, data set, and whether caches were warm. Debug builds are unsuitable for final performance conclusions because assertions, tooling, and disabled optimizations distort results.

2. Startup Performance

Startup can be classified as:

• Cold start: the application process does not exist and must be created.
• Warm start: the process remains, but the activity, view hierarchy, or application state requires reconstruction.
• Hot start or resume: the application returns from a paused or background state with much state retained.

The exact lifecycle differs between Android and iOS, so test each category using platform-appropriate procedures. Time to initial display measures visible output; time to interactive measures when the intended input can be handled. A splash screen may improve perceived continuity but does not reduce actual startup latency.

The startup critical path commonly includes runtime initialization, dynamic library loading, framework initialization, synchronous storage, dependency construction, initial layout, image decoding, and network-gated navigation. Optimization principles include:

1. Initialize only what the first screen requires.
2. Defer analytics, secondary databases, and optional SDKs until after initial interaction.
3. Avoid synchronous disk or network work on the main/UI thread.
4. Keep the initial widget or component tree small.
5. Persist a safe local snapshot when immediate display is preferable to waiting for remote data.
6. Precompute or generate expensive assets during build time where possible.

Concrete startup workflow

Flutter: build and run a profile or release variant on physical hardware. Use Flutter DevTools’ Performance view to record startup-related timeline events and CPU samples. Add controlled timeline markers around application initialization when necessary. Compare cold and warm runs separately. Do not infer release performance from hot reload.

React Native: use a release-like build, preferably with the production JavaScript engine configuration. Record application and native startup markers, inspect JavaScript execution with the supported React Native profiler, and use the React DevTools Profiler for initial component commits. Native startup work should be traced using Perfetto on Android or Instruments on iOS.

Android: use Android Studio CPU Profiler or Perfetto/System Trace to identify main-thread slices, process creation, class loading, binder calls, disk I/O, and frame events. Android Macrobenchmark can automate repeated startup measurements and reduce manual bias.

iOS: use Xcode Instruments—particularly Time Profiler, App Launch, and Points of Interest—to inspect launch phases and call stacks. Test without debugger attachment when collecting representative timing.

3. Rendering and Dropped Frames

Displays refresh at frequency f hertz. The nominal duration available for one frame is:

Here, T_frame is measured in milliseconds and f in frames per second, equivalent to hertz. At 60 Hz, the nominal interval is 1000 ÷ 60 ≈ 16.67 ms; at 120 Hz it is approximately 8.33 ms. This is an upper scheduling interval, not guaranteed application CPU time, because the operating system, compositor, and framework also consume resources.

A frame may be missed when work required before the display deadline finishes late. Causes include excessive rebuilds, expensive layout, synchronous parsing, large image decoding, shader or pipeline compilation, garbage-collection pauses, and contention with background work.

3.1 Flutter rendering diagnosis

Flutter DevTools’ Performance view distinguishes UI-thread and raster-thread activity and displays frame timelines. A long UI phase suggests expensive Dart computation, build, layout, or paint preparation. A long raster phase suggests costly painting, image processing, overdraw, or GPU pressure. The CPU Profiler can then identify hot call stacks; the Inspector can help locate unexpectedly large or frequently rebuilding subtrees.

Useful practices include making immutable widgets const where applicable, narrowing state updates, virtualizing long lists with builder-based APIs, constraining image dimensions, and avoiding unnecessary intrinsic layout passes. RepaintBoundary can isolate frequently repainted regions, but excessive boundaries create layers and memory overhead; verify its effect rather than applying it universally.

3.2 React Native rendering diagnosis

React Native work spans JavaScript execution, native/UI work, and rendering. Modern architectures can reduce serialization overhead, but heavy JavaScript or native main-thread work still causes delayed interaction or frames.

Use the React DevTools Profiler to record component commits and identify expensive or repeated renders. Confirm findings in a production-like build because development warnings and debugging alter timing. Memoization (memo, useMemo, or useCallback) is beneficial only when avoided work exceeds comparison and retention costs. Stable list keys, virtualized lists, appropriately tuned render windows, and avoiding unnecessary parent state changes often provide larger gains.

Perfetto, Android Studio System Trace, and Xcode Instruments reveal native scheduling, main-thread blockage, image decoding, and cross-layer interactions that a JavaScript-only profiler cannot show.

Worked example: frame deadline

Suppose a 60 Hz application performs 5.2 ms of JavaScript/Dart work, 4.4 ms of layout and paint preparation, and 8.1 ms of raster/compositor-related work on a dependency chain that must complete serially for the frame. The total is:

Since 17.7 ms > 16.67 ms, the work exceeds one nominal 60 Hz interval by approximately 1.03 ms. In real systems some stages may pipeline or overlap, so a trace—not simple addition alone—must determine whether the deadline was actually missed. The calculation is a critical-path screening test, not a universal rendering model.

4. CPU, Concurrency, and Scheduling

Concurrency improves responsiveness when it removes non-UI work from a latency-sensitive thread. It does not make every task faster. Creating workers, copying data, synchronization, and context switching have costs.

Good off-main-thread candidates include large JSON parsing, compression, cryptography, search indexing, image transformation, and CPU-intensive business rules. Tiny computations should normally remain local.

In Flutter, isolates have separate memory and communicate through messages. Functions such as compute can simplify one-off work, while long-lived isolates may suit repeated workloads. Transferable representations can reduce copying for large binary data where supported. UI APIs generally remain confined to the main isolate.

In React Native, application JavaScript normally executes on a JavaScript runtime thread, while platform UI operations occur through native mechanisms. CPU-heavy work may move to native code, dedicated workers, platform background facilities, or specialized libraries. The exact solution must match the React Native version and architecture; moving work across a boundary can be counterproductive if large payloads are repeatedly copied or converted.

Concurrency hazards include races, stale responses, out-of-order state updates, deadlocks in native code, and orphaned tasks. Use immutable messages, cancellation tokens or lifecycle checks, bounded worker pools, and explicit ownership. When multiple searches are issued, a request identifier can ensure that an older response does not overwrite a newer result.

5. Memory Management and Leak Diagnosis

A memory leak is memory that remains reachable despite no longer being useful. High memory use is not automatically a leak: an intentional cache may be large yet reclaimable. Conversely, a small retained object may indirectly preserve an entire graph.

Common leak sources include subscriptions not cancelled, timers, global collections, event listeners, closures capturing screen state, native resources not disposed, image caches, and references from long-lived service objects. Symptoms include steadily rising memory across repeated navigation cycles, more frequent garbage collection, degraded responsiveness, and operating-system termination.

5.1 Repeatable leak workflow

1. Choose a reproducible cycle, such as opening and closing a detail screen 20 times.
2. Establish a baseline after startup and allow transient work to settle.
3. Record heap and process memory after several cycles.
4. Trigger garbage collection only as a diagnostic aid where the tool permits; forced collection does not represent ordinary runtime behaviour.
5. Compare snapshots and inspect retaining paths.
6. Fix lifecycle ownership, repeat the identical experiment, and verify stabilization.

Flutter DevTools’ Memory view supports heap monitoring, allocation profiling, snapshots, and retaining-path investigation. Android Studio Profiler can inspect Java/Kotlin/native allocations and process memory. Xcode Instruments provides Allocations, Leaks, and memory graph tools. For React Native, combine JavaScript heap/profiling facilities with native platform tools because a leak may exist in JavaScript, native objects, images, or a module boundary.

Allocation rate matters as well as retained size. Rapid creation of short-lived objects can trigger frequent collection pauses. Reuse should be considered for genuinely expensive resources, but arbitrary object pooling may increase complexity and retention.

6. Network and Storage Optimization

Mobile networks have variable latency, loss, metering, and radio energy costs. Optimization should reduce unnecessary round trips and bytes while preserving correctness.

6.1 Network techniques

• request only required fields and paginate large collections;
• compress suitable text payloads, while avoiding redundant compression of already compressed media;
• cancel obsolete requests when screens disappear or queries change;
• batch compatible operations where this reduces round trips;
• use HTTP caching validators such as ETag or Last-Modified;
• resize images for display density and negotiate modern formats where platform support permits;
• deduplicate concurrent requests for the same resource;
• prefetch only when probability of use justifies data and energy costs.

The cache hit ratio is:

Here, N_hit and N_miss are counts over the same observation period, and H is dimensionless between 0 and 1. A high ratio does not prove correctness: stale or unauthorized data is unacceptable even if fast.

Caches need policies for keys, freshness, capacity, eviction, invalidation, ownership, and encryption. A cache key must include every request dimension that changes the representation, such as user identity, locale, query, or authorization scope. Stale-while-revalidate can display cached data immediately and refresh it asynchronously, provided the interface communicates material staleness.

6.2 Storage techniques

Local storage ranges from key-value preferences to relational databases and secure credential stores. Select storage according to consistency, query, volume, and confidentiality requirements.

Index fields used frequently in filtering, joining, or ordering, but remember that indexes consume space and increase write cost. Group related writes into transactions, avoid rewriting whole documents for small changes when the technology supports partial updates, and move large migrations away from latency-sensitive UI operations. Query only required columns or fields.

Credentials and cryptographic secrets belong in platform-protected secure storage, not an ordinary cache. Sensitive cached records require encryption, deletion policies, and protection against accidental logging.

7. Battery and Thermal Efficiency

Energy consumption is influenced by CPU/GPU work, display activity, radio transfers, location, sensors, wakeups, and background execution. Continuous polling is often worse than push notification, event-driven refresh, or adaptive scheduling. Combining network operations may reduce repeated radio activation, although very large batches can increase latency and memory.

Energy measurement requires explicit counter semantics. If a tool reports a cumulative consumed-energy counter C in joules or watt-hours, estimated task energy is:

If a tool instead reports remaining battery energy R, then:

Both formulas assume no charging during the interval and comparable background conditions. They are not interchangeable. Battery percentage is a coarse state-of-charge estimate and is usually inadequate for short microbenchmarks.

For example, if a cumulative energy counter rises from 124.6 J to 132.1 J during a controlled operation, estimated consumption is 132.1 − 124.6 = 7.5 J. Repeated control and treatment runs are needed because operating-system activity introduces noise.

Use Android Studio Energy Profiler where available, Perfetto power and scheduling traces, platform battery statistics, and Xcode Instruments’ Energy Log. Test on physical devices and monitor thermal state. Thermal throttling can make later benchmark runs slower, so randomize experiment order and allow cooling periods.

8. Application Size and Lazy Loading

Application size affects download completion, installation, update adoption, storage use, and startup I/O. Distinguish store download size, installed size, per-architecture size, and update size; they are not equivalent.

In Flutter, use release builds with size analysis, such as flutter build ... --analyze-size, and inspect the generated breakdown in DevTools. Compare snapshots to identify growth in Dart code, native libraries, fonts, and assets. In React Native, inspect Android App Bundles/APKs with Android Studio APK Analyzer and iOS archives with Xcode’s archive and size reports. Source-map and bundle analysis tools can identify unexpectedly included JavaScript dependencies.

Common reductions include removing unused assets and locales, compressing images appropriately, subsetting fonts, avoiding duplicate libraries, enabling platform-supported shrinking, and delivering architecture-specific binaries through store mechanisms. Never remove code solely because a shrinker appears to mark it unused without testing reflection, dynamic registration, and native integration paths.

Lazy loading defers code, modules, routes, data, or assets until needed. It reduces initial work but can shift latency to first use. Effective designs prefetch probable next resources under suitable network and battery conditions and provide loading/error states. Lazy loading is an allocation of cost across time, not elimination of cost.

9. Reliability and Resilience

Fast software that frequently fails is not high-quality software. Mobile applications must handle timeouts, transient server failures, process death, duplicate submissions, and offline intervals.

9.1 Timeouts, retries, and full jitter

Every remote operation should have a finite timeout appropriate to its user and network context. Retrying immediately can amplify an outage. Exponential backoff increases delay after each failure. With full jitter, the delay for zero-based retry number n is sampled as:

Here, b is the base delay, D is the maximum delay cap, and all time quantities use the same unit. The expected delay is half the upper bound:

This applies to a continuous uniform sample; implementations using integer milliseconds have a nearly identical discrete expectation depending on endpoint conventions.

Worked example: with b = 0.5 s, D = 8 s, and n = 3, the upper bound is min(8, 0.5 × 2³) = 4 s. Full jitter samples uniformly from 0 to 4 s, so the expected delay is 2 s.

Retry only failures likely to be transient, respect server Retry-After instructions, impose a retry limit, and cancel retries when no longer useful. Non-idempotent operations require an idempotency key or equivalent server design; otherwise a lost response can lead to duplicate payment or duplicate creation.

9.2 Circuit breakers and offline operation

A circuit breaker stops repeatedly calling a failing dependency. In the closed state, calls proceed. After a failure threshold, it opens and fails fast. Following a cooldown it becomes half-open and admits limited probes. Thresholds must be tuned carefully because aggressive breakers can reject recoverable traffic.

Offline-first systems treat local data as an operational source and synchronize later. They need durable queues, operation identifiers, conflict rules, schema migration, and visible synchronization status. “Last write wins” is simple but may discard valid edits; domain-specific merge rules are often safer.

Reliability also includes crash handling and recoverability. Persist essential drafts, make migrations restartable, validate data at trust boundaries, and ensure partially completed operations can resume or roll back safely.

10. Observability and Production Diagnosis

Observability is the ability to infer internal behaviour from emitted evidence. Three common evidence types are:

• Metrics: aggregated numerical series, such as p95 startup latency.
• Logs: structured events containing relevant context.
• Traces: causally related spans across application and services.

Instrument user journeys rather than isolated functions. A checkout trace might connect tap handling, local validation, request dispatch, server processing, response parsing, and UI confirmation. Correlation identifiers link these stages without storing sensitive payloads.

Release monitoring should segment by application version, device class, operating system, network type, and feature flag. Compare new releases with a baseline or controlled rollout cohort. Crash-free users and crash-free sessions answer different questions; always name the denominator.

Observability has costs. Excessive logging consumes CPU, storage, network, and battery and can expose personal information. Apply sampling, retention limits, redaction, access controls, and consent or lawful-basis requirements. Never place credentials, authentication tokens, raw payment data, or unnecessary personal data in telemetry.

11. Practical Cross-Platform Profiling Workflow

A disciplined investigation can use the following sequence:

A practical jank investigation should first record a system trace, identify the missed frame interval, determine which thread or process occupied the critical path, and then use a language-level profiler to resolve that interval to functions or component/widget work. Starting with a function profiler alone can optimize code that was not responsible for the missed deadline.

Automation should complement interactive tools. Store benchmark scenarios in continuous integration, run them on representative physical devices where feasible, and fail builds only with statistically defensible thresholds. Mobile measurements are noisy; compare multiple repetitions and inspect distributions rather than one run.

12. Illustrative Case Study: MetroMart Grocery Application

Background

MetroMart is a fictional cross-platform grocery application with Flutter and React Native implementations maintained by separate product teams. Users reported delayed launch, scrolling pauses, failed cart submissions, and heavy battery use.

Problem

On a representative Android device, cold-start p95 was 3.4 s, product-list jank was 11%, and memory increased after repeated product-detail navigation. The application polled inventory every 15 seconds and retried failed cart submissions immediately. Its download size had also grown substantially.

Analysis

Perfetto showed synchronous preference loading and analytics initialization on the startup critical path. Flutter DevTools and the React Profiler found that visible product rows rebuilt when unrelated cart metadata changed. System traces showed full-resolution image decoding near missed frames. Repeated memory snapshots revealed retained screen subscriptions. Network inspection showed identical inventory responses despite frequent polling. Size analyzers found unused promotional videos, duplicate icon sets, and an unnecessary native library.

Approach

The teams:

1. deferred analytics and nonessential service initialization;
2. displayed a validated local catalogue snapshot before asynchronous refresh;
3. narrowed state subscriptions and virtualized product lists;
4. requested server-generated thumbnail dimensions;
5. cancelled detail-screen subscriptions on disposal or unmount;
6. replaced fixed polling with push-triggered invalidation plus bounded refresh;
7. made cart submission idempotent and applied capped exponential backoff with full jitter;
8. added a durable offline cart queue with visible synchronization status; and
9. removed unused assets and compared release-size reports in continuous integration.

Outcome

In controlled tests on the same device class, cold-start p95 fell from 3.4 s to 1.8 s, jank from 11% to 2.7%, and memory stabilized after repeated navigation. Inventory requests per 30-minute session declined substantially. These results were validated with a staged rollout segmented by version and device class; no claim was based solely on laboratory averages.

Learning Points

The largest improvements came from architecture and workload reduction rather than micro-optimizations. Cross-layer tracing connected symptoms to causes. Reliability mechanisms also required server cooperation: client retries became safe only after idempotency support was introduced.

13. Challenges, Governance, and Contemporary Practice

Performance varies across devices, operating-system versions, network conditions, accessibility settings, and user data volumes. Optimizing only flagship hardware creates an equity problem because users of lower-cost devices may receive the poorest experience. Performance test matrices should therefore include supported low- and mid-range devices.

Background execution is increasingly constrained by Android and iOS to protect energy and privacy. Developers should use sanctioned scheduling APIs rather than attempting to keep processes alive. Adaptive refresh rates, heterogeneous CPU cores, new rendering engines, and evolving React Native and Flutter architectures make historical assumptions unreliable; benchmark the actual supported stack.

Automated and AI-assisted tools can summarize traces or suggest hotspots, but they may confuse correlation with causation. Recommendations must be validated through controlled measurement. Governance should require reproducible benchmarks, telemetry review, privacy assessment, rollback capability, and ownership of performance budgets.

Chapter Summary

Mobile performance is a multidimensional system property encompassing startup, rendering, memory, network, storage, energy, reliability, and application size. Effective optimization begins with user-centred SLIs, realistic release builds, controlled conditions, and percentile-based evidence. Flutter DevTools and React Native profiling identify framework-level work, while Perfetto, Android Studio Profiler, Xcode Instruments, and size analyzers expose platform-wide causes.

Dropped frames arise when critical work misses display deadlines; leaks arise when unnecessary objects remain reachable. Concurrency, lazy loading, caching, and batching can improve responsiveness but introduce overhead and correctness risks. Reliable applications combine finite timeouts, safe retries with correctly implemented full jitter, idempotency, circuit breakers, and explicit offline synchronization. Production observability closes the feedback loop, provided telemetry is proportionate, secure, and privacy-preserving.

Key Terms

Service-Level Indicator (SLI): A quantitative measure of application behaviour.

Service-Level Objective (SLO): A target value or range for an SLI.

Cold Start: Application launch when no process is already running.

Time to Interactive: Time until the intended user interaction can be handled.

Frame Budget: Nominal time interval available before the next display refresh deadline.

Jank: Perceptible visual discontinuity caused by irregular or missed frames.

Critical Path: The dependent sequence of work that determines completion time.

Memory Leak: Memory retained after it has ceased to be useful.

Retaining Path: Reference chain that keeps an object reachable.

Allocation Rate: Amount of memory allocated per unit time.

Cache Hit Ratio: Fraction of cache lookups satisfied without accessing the origin.

Lazy Loading: Deferral of resource acquisition or initialization until needed.

Idempotency: Property by which repeated equivalent operations have the same intended effect as one operation.

Exponential Backoff: Retry strategy that increases the maximum waiting interval exponentially.

Full Jitter: Uniform random selection between zero and the capped exponential delay.

Circuit Breaker: Mechanism that temporarily blocks calls to a repeatedly failing dependency.

Observability: Ability to infer system behaviour from metrics, logs, and traces.

Thermal Throttling: Hardware reduction of operating speed to control temperature.

Review Questions

Short Answer Questions

1. Distinguish cold, warm, and hot application starts.
2. Why should release-like builds be used for performance conclusions?
3. What does a retaining path reveal during leak diagnosis?
4. Why can a high cache hit ratio still accompany incorrect behaviour?
5. How does full jitter reduce synchronized retry traffic?

Long Answer Questions

1. Explain an evidence-driven workflow for diagnosing dropped frames in Flutter or React Native.
2. Discuss the benefits, overheads, and correctness risks of moving computation off the main thread.
3. Compare caching, lazy loading, batching, and prefetching as resource-optimization strategies.
4. Explain how timeouts, idempotency, retries, circuit breakers, and offline queues contribute to reliability.
5. Design an observability strategy that supports production diagnosis while protecting privacy.

Analytical / Application Questions

1. A 120 Hz screen allows a nominal 8.33 ms frame interval. A traced critical path contains 2.1 ms of state computation, 3.0 ms of layout, and 4.4 ms of required raster work with no overlap. Determine whether it fits one interval and recommend an investigation.
2. Design a controlled experiment to determine whether repeated navigation causes a memory leak rather than temporary cache growth.
3. An application retries with b = 0.25 s, D = 10 s, and zero-based retry n = 4. Determine the full-jitter interval and expected delay, then explain when the operation should not be retried.

Multiple Choice Questions with Answers

Question 1

At a 120 Hz display refresh rate, what is the nominal frame interval?

A. 4.17 ms

B. 8.33 ms

C. 16.67 ms

D. 120 ms

Correct Answer: B. 8.33 ms

Question 2

Which formula correctly defines standard full jitter for zero-based retry number n, base delay b, and cap D?

A. W_n = min(D,b×2ⁿ)

B. W_n ~ Uniform(0,min(D,b×2ⁿ))

C. W_n ~ Uniform(b,D)+2ⁿ

D. W_n = D+b+n

Correct Answer: B. W_n ~ Uniform(0,min(D,b×2ⁿ))

Question 3

A cumulative consumed-energy counter rises from 210 J to 218 J during a task. Assuming no charging and comparable background activity, what is the estimated task energy?

A. −8 J

B. 8 J

C. 210 J

D. 428 J

Correct Answer: B. 8 J

Question 4

Which tool is most appropriate for examining UI-thread and raster-thread frame activity in Flutter?

A. Flutter DevTools Performance view

B. Android APK Analyzer

C. Xcode archive size report

D. A source-code formatter

Correct Answer: A. Flutter DevTools Performance view

Question 5

A screen's memory continues to be retained after repeated navigation because an event subscription was not cancelled. This is best classified as:

A. A cache hit

B. A memory leak

C. Thermal throttling

D. Code shrinking

Correct Answer: B. A memory leak

Question 6

Why should a system trace usually precede function-level optimization during a jank investigation?

A. It identifies which thread and interval lie on the missed frame's critical path

B. It automatically removes all unnecessary renders

C. It guarantees identical performance on all devices

D. It converts a debug build into a release build

Correct Answer: A. It identifies which thread and interval lie on the missed frame's critical path

Question 7

Which practice makes retrying a cart submission safest after a response is lost?

A. Removing the request timeout

B. Using an idempotency key recognized by the server

C. Retrying continuously without delay

D. Storing the authentication token in logs

Correct Answer: B. Using an idempotency key recognized by the server

Question 8

With b=0.5 s, D=8 s, and n=3, what is the full-jitter sampling interval?

A. 0 to 2 s

B. 2 to 4 s

C. 0 to 4 s

D. 4 to 8 s

Correct Answer: C. 0 to 4 s

Question 9

Which statement about lazy loading is correct?

A. It eliminates the cost of loading a resource permanently

B. It shifts some cost from startup to later first use

C. It always reduces total network transfer

D. It removes the need for loading and error states

Correct Answer: B. It shifts some cost from startup to later first use

Question 10

Which metric best reveals slow experiences hidden by an acceptable average?

A. An upper latency percentile such as p95

B. The source-code line count

C. The number of development dependencies

D. The application version string

Correct Answer: A. An upper latency percentile such as p95