**TypeScript 针对 iOS 不支持 JIT 的优化策略总结**
由于 iOS 的 **JavaScriptCore (JSC)** 引擎 **禁用 JIT（Just-In-Time 编译）**，JavaScript 在 iOS 上的执行性能较差，尤其是涉及动态代码时。
**TypeScript（TS）** 通过 **静态类型检查** 和 **编译时优化**，可以显著减少动态行为，提升 iOS 上的运行效率。
以下是 **推荐写法 vs 避免写法** 的对比分析，以及各自的 **性能影响** 和 **优化原理**。
**1. 静态属性访问 vs 动态属性访问**
✅ **推荐写法：静态属性访问**
```typescript
interface User {
name: string;
}
const user: User = { name: "Alice" };
console.log(user.name); // 静态访问
```
**好处**：
-
**引擎优化友好**：iOS 的 JavaScriptCore（JSC）引擎可以 **提前计算属性偏移**，直接访问内存位置，减少哈希查找开销。
-
**AOT 友好**：静态结构更容易被 **提前编译（AOT）** 优化，减少解释执行时的性能损耗。
❌ **避免写法：动态键访问**
```typescript
const user: Record<string, string> = { name: "Alice" };
const key = "name";
console.log(user[key]); // 动态访问
```
**问题**：
-
**哈希查找开销**：引擎无法预知 `key` 的值，必须进行 **运行时哈希计算**，性能较差。
-
**无法内联优化**：动态访问阻止 JSC 进行 **内联缓存（Inline Caching）**，导致每次访问都要重新查找。
**2. 使用 `Map` 代替 `Object` 存储动态键**
✅ **推荐写法：`Map` 结构**
```typescript
const map = new Map<string, number>();
map.set("score", 100);
console.log(map.get("score")); // 比 `obj[key]` 更快
```
**好处**：
-
**优化哈希表**：`Map` 专为动态键设计，查找速度比 `Object` 更快（尤其在频繁增删键时）。
-
**内存更紧凑**：`Map` 存储方式比 `Object` 更高效，减少内存碎片。
❌ **避免写法：`Object` 动态键**
```typescript
const scores: Record<string, number> = {};
scores["math"] = 90;
console.log(scores["math"]); // 动态键性能较差
```
**问题**：
-
**隐藏类（Hidden Class）变更**：动态增删属性会导致引擎重建隐藏类，增加开销。
-
**哈希冲突风险**：`Object` 的哈希表实现不如 `Map` 高效，可能影响性能。
**3. 避免 `any`，使用显式类型**
✅ **推荐写法：显式类型**
```typescript
function add(a: number, b: number): number {
return a + b; // 引擎可推断类型，优化计算
}
```
**好处**：
-
**减少类型检查**：引擎无需在运行时动态推断类型，直接使用 **固定类型优化**。
-
**更快的函数调用**：参数类型明确，iOS JSC 可生成更高效的调用路径。
❌ **避免写法：隐式 `any`**
```typescript
function add(a, b) { // 编译后变成 `function add(a: any, b: any)`
return a + b; // 运行时需检查类型
}
```
**问题**：
-
**额外类型检查**：引擎必须在运行时检查 `a` 和 `b` 的类型，降低执行速度。
-
**无法内联优化**：动态类型阻止 JSC 进行 **函数内联（Inlining）** 优化。
**4. 使用 `const` 和 `readonly` 固定引用**
✅ **推荐写法：不可变引用**
```typescript
const arr: readonly number[] = [1, 2, 3]; // 不可变数组
console.log(arr[0]); // 引擎可优化访问
```
**好处**：
-
**内存优化**：引擎知道数组不会被修改，可以 **预分配内存** 或 **静态优化访问**。
-
**减少隐藏类变更**：避免动态修改导致引擎重建内部结构。
❌ **避免写法：动态修改**
```typescript
const arr = [1, 2, 3]; // 可变数组
arr.push(4); // 修改数组结构
```
**问题**：
-
**隐藏类重建**：每次修改数组/对象结构，引擎可能 **重新计算内存布局**，降低性能。
-
**解释执行更慢**：动态修改的代码在 iOS 上解释执行时更慢。
**5. 减少运行时类型检查**
✅ **推荐写法：编译时类型约束**
```typescript
function parse(input: string) { // 编译时确保类型正确
return input.trim();
}
```
**好处**：
- **无运行时开销**：引擎直接处理 `string` 类型，无需额外检查。
❌ **避免写法：运行时类型检查**
```typescript
function parse(input: unknown) {
if (typeof input === "string") return input.trim(); // 运行时检查
}
```
**问题**：
-
**额外分支判断**：`typeof` 检查增加 CPU 开销，影响性能。
-
**阻止优化**：动态类型检查让引擎难以优化代码路径。
**6. 启用 TS 严格模式**
✅ **推荐写法：`strict: true`**
```json
// tsconfig.json
{
"compilerOptions": {
"strict": true,
"noImplicitAny": true
}
}
```
**好处**：
-
**强制显式类型**，避免意外动态行为。
-
**更早发现潜在性能问题**，如隐式 `any` 或未定义类型。
❌ **避免写法：宽松模式**
```json
{
"compilerOptions": {
"strict": false // 允许隐式 any
}
}
```
**问题**：
- **隐藏性能问题**：代码可能包含大量动态类型，降低 iOS 运行效率。
**7. 使用 WebAssembly（WASM）优化计算密集型任务**
✅ **推荐写法：WASM + TS 类型安全**
```typescript
import wasmModule from "./compute.wasm";
const result = wasmModule.exports.heavyCalculation();
```
**好处**：
-
**绕过 JS 引擎限制**：WASM 是 AOT 编译的，不依赖 JIT，在 iOS 上性能稳定。
-
**适用于游戏/加密/图像处理** 等计算密集型场景。
❌ **避免写法：纯 JS 计算**
```typescript
function heavyCalculation() {
// 纯 JS 计算，iOS 上可能很慢
let sum = 0;
for (let i = 0; i < 1e6; i++) sum += i;
return sum;
}
```
**问题**：
- **解释执行慢**：iOS 无 JIT，循环和计算性能较差。
**总结：TS 在 iOS 上的优化核心思路**
| **优化方向** | **推荐写法** | **避免写法** | **iOS 性能影响** |
|----------------------|------------|------------|----------------|
| **属性访问** | `obj.prop` | `obj[key]` | ⚡ 快 2-5x |
| **数据结构** | `Map` | `Object` | ⚡ 快 1.5-3x |
| **类型定义** | 显式类型 | `any` | ⚡ 快 2x |
| **不可变性** | `readonly` | 动态修改 | ⚡ 快 1.5x |
| **类型检查** | 编译时检查 | `typeof` | ⚡ 快 2x |
| **计算密集型任务** | WASM | 纯 JS | ⚡ 快 10-100x |
**关键结论**
-
**静态 > 动态**：尽量让代码结构在编译时确定，减少运行时决策。
-
**AOT 优化友好**：iOS 无 JIT，静态代码更容易被 AOT 或解释器优化。
-
**WASM 突破瓶颈**：对计算密集型任务，用 WASM 替代 JS。
通过以上优化，即使 iOS 不支持 JIT，也能让 TypeScript 代码运行得更快！ 🚀