HookIdentityWarmUp

Executes the hook-identity code path once at startup so that Meta's production ART profile learns it.

The problem

FB4A and IG4A do not ship an AGP baseline profile. Their ART profile is harvested from real production sessions, and a method is AOT-compiled only if it ran in at least threshold% of harvested sessions for some interaction; the lowest threshold either app uses is 20%.

Hook identity is behind an experiment, so the methods that only run when it is on were observed in ~4.5% (IG4A) and ~3.4% (FB4A) of sessions and are therefore absent from the profile, while their index-path counterparts are present. KStateKt.getUpdatedStateByIndex ships; getUpdatedStateByHookKey does not, despite the two doing the same amount of work per render. Every hook-identity experiment arm consequently pays an AOT handicap the control arm does not, which biases the arm contrast independently of the change under test.

What this does about it

Touching the methods once per process pushes their observed session share to ~100%, above every interaction threshold, so the next harvest generates a profile that AOT-compiles them for everybody. It deliberately runs in all arms including control: the goal is a profile that is identical for both arms, not one that matches the treatment.

What it does not do

• It does not take effect in the build that contains it. The profile is a snapshot patched into deep_data/BUCK by an automated job. This code has to land, ship in a release, be harvested from that release's production sessions, and then be autoshipped, before any build sees the benefit.

• It cannot reach the hook methods that need a live render. KStateKt.getUpdatedStateByHookKey, ComponentScope.requireCurrentHookKey and KStateKt.transientMutate all need a real ComponentScope with a resolve context and tree state, which is far too much to construct on the startup path. Those three stay uncovered.

See also