Why ArkTS Bans any/unknown Types and What It Means for Performance

Q1: Why does ArkTS restrict the any and unknown types?

Core answer: To enable Ahead‑Of‑Time (AOT) compilation optimization. In TypeScript, any allows runtime type changes, forcing the JIT compiler to perform extensive type checks and lookups. ArkTS enforces static typing so the compiler can determine object layouts and emit efficient machine code, dramatically improving startup speed and runtime performance.

Q2: How does ArkTS handle unknown‑type objects from JavaScript libraries?

Core answer: Use the ESObject type. Because any is disabled, any interaction with traditional JS/TS libraries (e.g., receiving objects from third‑party libraries) should declare the object as ESObject. This signals the compiler that the object is dynamic and needs special handling, while minimizing ESObject usage across language boundaries to avoid performance penalties.

Q3: What special restrictions does ArkTS impose on Interfaces and Classes?

Object literal restriction: ArkTS does not allow direct assignment of an object literal to an interface type unless the interface fully matches a structural type with no methods. It is recommended to instantiate objects via a class instead.

Runtime modification restriction: ArkTS forbids adding or deleting object properties at runtime (e.g., delete obj.prop is prohibited). This guarantees a stable memory layout, which is essential for performance optimization.

Q4: Briefly describe decorators in ArkTS and their purpose.

Core answer: Decorators enable declarative UI and state management.

Class decorators: @Component (define component), @Entry (define page entry), @CustomDialog (define dialog).

Property decorators: @State (component state), @Link (two‑way binding), @Prop (one‑way binding), @BuilderParam (UI slot).

Method decorators: @Builder (lightweight UI reuse).

Principle: Decorators are compiler metadata tags; during compilation the compiler generates corresponding glue code such as state listeners and UI update logic.

Q5: What limitations exist for closures (Closure) in ArkTS?

Core answer: Captured variables must have an explicit type.

Only Arrow Function (arrow functions) can capture local variables.

If a closure is passed to a different execution context (e.g., asynchronous callback), developers must guard against potential memory leaks.

In UI description functions ( build), closures commonly capture this, which the runtime automatically binds to the current component instance.

Q6: How do Record and Map differ in ArkTS?

Record<K, V>: A TypeScript utility type representing a plain object {}. In ArkTS it defines pure data objects with fixed key/value types, suitable for simple DTOs.

HashMap / Map: High‑performance container classes provided by ArkTS ( @kit.ArkTS).

Selection advice:

For simple data transfer objects, use Record or a Class.

For frequent CRUD, size queries, or iteration, use HashMap or Map, because ArkTS imposes restrictions on dynamic operations of native objects.

Q7: How does ArkTS's memory model differ from traditional Java/Kotlin?

Core answer: ArkTS adopts an Actor concurrency model with memory isolation between threads.

No shared memory: Different threads (e.g., UI main thread and worker thread) do not share objects.

Communication mechanism: Data is exchanged via Serialization or Transferable ownership transfer.

Advantages: Eliminates race conditions, removes the need for locks, and completely resolves deadlock issues.

Q8: What is a Sendable object?

Core answer: Sendable is a special object type introduced in ArkTS to address the efficiency challenges of cross‑thread communication under the Actor model.

Classes decorated with @Sendable can have their instances passed by reference ( Shared Reference ) across threads instead of being copied.

Restrictions: A Sendable object must be frozen (immutable properties) or use a specific lock mechanism such as AsyncLock to guarantee thread safety.

Use cases: Large object transfer, shared configuration across threads.