default title

A context that looks the same

Both getContext (this) and getContext() in a single container often seem to be correct. (Actually, it's quite similar to using it, especially for someone like me who is a habitual user of single Ability and single Window.)

In multi container/sub window/plugin/dynamic components, getContext() depends on the "currently active container" and is prone to errors; GetContext (this) depends on the instanceId of this for greater stability.

The new paradigm uses this. getUIContext(). getHostContext() to first "lock the UI instance scope" and then retrieve the host context to eliminate drift.

Three paths getContext

How does getContext (this) obtain an instance?

We can find the file jsi_context_module.cpp and see how it handles getContext (this) calls.

1.Firstly, check if any parameters have been passed in. If not, it indicates that there is an issue with the calling method

2.Then check if the incoming object is truly an object and has a getInstanceId method

3.If the conditions are met, call this method to obtain the instance ID

Where did this getInstanceId method come from? Why does a component object have this method?

Let's continue to look at the code and see how it is used after obtaining the instance ID

Even if this is passed in, if it is not bound to an instance, the system will revert back to the currently active instance. What does this mean?

What happens when getContext() takes no parameters?

Let's take a look at the implementation of getContext():

Comparative analysis:

GetContext (this): First attempt to retrieve the instance ID from this, and if unsuccessful, fallback to the current instance

GetContext(): directly obtain the current active instance ID

What is' currently active instance '? How is the 'currently active' determined in a multi container scenario?

Let's take a look at the implementation of Container:: CurrentIdSafely():

Thread local storage? Does this mean that each thread may have a different 'current instance'? This explains why problems may occur in multi-threaded environments.

How does getHostContext() ensure stability?

Now let's take a look at the implementation of UIContext. getHostContext():

• First, call JSScopeUtil.syncInstanceId (this. instanceId) to synchronize the instance ID
• Then call getContext() to get the Context
• Finally, restore the original instance scope in the finally block

Key question: What are JSScopeUtil.syncInstanceId and restoreInstanceId? How do they ensure the correctness of instance scope?

Let's take a look at the implementation in js_stcope_util.cpp:

So the stability of getHostContext() comes from first "locking" the instance ID of UIContext, then obtaining the Context within the locked scope, and finally restoring the original state. This is like operating in a 'temporary work environment' without affecting the instance state elsewhere.

Comparison and summary of three paths

Now we can clearly see the difference between the three paths:

GetContext (this): depends on the instance binding of the incoming object, with a fallback mechanism

GetContext(): directly dependent on the current active instance, may be unstable in multiple containers

GetHostContext(): Lock the instance scope of UIContext first, then retrieve the Context, and finally restore the original state

Why is the third method more stable? Because it does not rely on the potentially changing state of the 'currently active instance', but actively switches to the instance bound to UIContext, and immediately recovers after the operation is completed without leaving any side effects.