3、表现层（UI层）设计：UI组件的跨屏复用、响应式布局策略、主题与皮肤管理、事件分发机制

表现层，说白了就是用户直接看到、摸到的那一层。很多团队把UI层想得太简单，觉得不就是画几个按钮、排几个框吗？其实不然。在多屏系统里，UI层是最容易出幺蛾子的地方。我见过太多项目，手机端跑得好好的，一上大屏就崩了——按钮飞了、字体糊了、事件点不动了。

今天我们就来聊聊UI层的四个核心问题。嗯，都是我在实战中踩过的坑。

3.1 UI组件的跨屏复用

跨屏复用，不是简单的复制粘贴。你想想看，手机上的按钮和电视上的按钮，能一样吗？尺寸不同、交互方式不同、视觉密度也不同。

我个人习惯的做法是：组件分层。把UI组件拆成三层：

• 基础组件：按钮、输入框、列表项。这些是原子级的，跨屏复用度最高。
• 复合组件：搜索栏、卡片、弹窗。由基础组件拼装而成，需要做屏幕适配。
• 业务组件：用户信息面板、商品详情块。跟具体业务绑定，复用度最低。

我在项目中遇到过一个问题：团队把业务组件直接拿来跨屏用，结果电视端加载了手机端的触摸事件，遥控器根本没法操作。后来我们定了个规矩——基础组件全平台共用，复合组件按平台适配，业务组件各自实现。

举个例子，一个按钮组件：

// 基础按钮 - 跨屏复用
class BaseButton {
  constructor({ label, onClick, size }) {
    this.label = label;
    this.onClick = onClick;
    this.size = size; // 'small' | 'medium' | 'large'
  }

  // 各平台自己实现渲染
  render(platform) {
    switch(platform) {
      case 'mobile': return this.renderMobile();
      case 'tv': return this.renderTV();
      case 'watch': return this.renderWatch();
    }
  }
}

你看，逻辑是共用的，渲染是分离的。这样既保证了行为一致，又给了各平台足够的自由度。

3.2 响应式布局策略

响应式布局，很多人第一反应就是媒体查询。但多屏系统里，光靠媒体查询远远不够。为什么？因为屏幕尺寸跨度太大了——从1.5寸的智能手表到85寸的电视，中间差了将近60倍。

我建议采用混合策略：

策略	适用场景	实现方式
弹性布局	同类型设备（手机/平板）	Flexbox、Grid、百分比
断点切换	不同类型设备（手机→电视）	媒体查询 + 组件切换
容器查询	组件级自适应	@container、ResizeObserver
缩放适配	固定尺寸设备（广告屏、收银机）	viewport缩放、rem/em

这里有个坑，我曾经踩过：不要只用百分比。百分比是相对于父容器的，嵌套多了就失控了。我见过一个页面，三层嵌套下来，一个按钮变成了屏幕的1/3宽，丑得没法看。

还有一个容易被忽略的点：内容优先。不要为了适配而牺牲内容。我在做车载系统时，客户要求所有屏幕显示同样的信息量。结果小屏上字挤成一团，根本看不清。后来我们改成：小屏显示核心信息，大屏显示完整信息。用户反而更满意。

3.3 主题与皮肤管理

主题管理，说白了就是换皮肤。但多屏系统里，主题不是换个颜色那么简单。不同屏幕的显示特性差异很大——OLED屏黑色更黑，LCD屏亮度更高，投影仪对比度低。

我建议采用分层主题系统：

• 基础主题：定义颜色、字体、间距等设计令牌（Design Tokens）
• 平台主题：针对不同屏幕特性做微调（比如电视端提高对比度）
• 用户主题：用户自定义的偏好（比如夜间模式、大字模式）

代码实现上，我习惯用CSS变量配合JavaScript：

// 设计令牌定义
const designTokens = {
  colors: {
    primary: '#007AFF',
    background: '#FFFFFF',
    text: '#333333'
  },
  spacing: {
    xs: '4px',
    sm: '8px',
    md: '16px',
    lg: '24px'
  }
};

// 平台覆盖
const platformOverrides = {
  tv: {
    colors: {
      primary: '#FF9500', // 电视端用暖色，更醒目
      background: '#1A1A1A',
      text: '#FFFFFF'
    }
  },
  watch: {
    colors: {
      primary: '#34C759', // 手表端用绿色，省电
    }
  }
};

// 应用主题
function applyTheme(platform, userPreferences) {
  const base = designTokens;
  const platformTheme = deepMerge(base, platformOverrides[platform]);
  const finalTheme = deepMerge(platformTheme, userPreferences);
  
  // 设置CSS变量
  Object.entries(finalTheme.colors).forEach(([key, value]) => {
    document.documentElement.style.setProperty(`--color-${key}`, value);
  });
}

还有一个细节：主题继承。比如用户选择了「大字模式」，那么所有屏幕都应该响应。但电视端本身字体就大，再放大可能就溢出了。所以平台主题的优先级应该高于用户主题。嗯，这里要注意优先级顺序：用户主题 < 平台主题 < 基础主题。

3.4 事件分发机制

事件分发，是多屏系统里最容易被低估的环节。不同屏幕的输入方式完全不同：手机靠触摸，电视靠遥控器，电脑靠鼠标键盘，车载靠语音和旋钮。

我建议设计一个统一的事件抽象层：

// 统一事件接口
class UIEvent {
  constructor(type, payload) {
    this.type = type;       // 'click' | 'select' | 'focus' | 'scroll'
    this.source = payload.source; // 'touch' | 'remote' | 'mouse' | 'voice'
    this.target = payload.target;
    this.position = payload.position;
    this.timestamp = Date.now();
  }
}

// 各平台适配器
class TouchAdapter {
  toUIEvent(nativeEvent) {
    return new UIEvent('click', {
      source: 'touch',
      target: nativeEvent.target,
      position: { x: nativeEvent.clientX, y: nativeEvent.clientY }
    });
  }
}

class RemoteAdapter {
  toUIEvent(nativeEvent) {
    // 遥控器方向键映射
    const keyMap = {
      'ArrowUp': 'focusUp',
      'ArrowDown': 'focusDown',
      'Enter': 'click'
    };
    return new UIEvent(keyMap[nativeEvent.key] || 'unknown', {
      source: 'remote',
      target: document.activeElement
    });
  }
}

为什么要这样做？因为业务逻辑不应该关心用户是用手指点的还是用遥控器选的。统一事件层之后，业务代码只需要处理 UIEvent 就行了。

我曾经在做一个智能家居项目时，遇到了一个诡异的问题：电视上的焦点移动总是慢半拍。排查了半天，发现是事件处理里做了防抖（debounce）。遥控器按一下，要等300ms才响应。用户都按了两下了，第一个事件还没处理完。后来我们把防抖去掉，改用节流（throttle），问题就解决了。

这里分享一个避坑指南：不要在小屏设备上做复杂的事件冒泡。手表屏幕那么小，元素叠在一起，冒泡很容易误触。我建议小屏设备用捕获阶段处理事件，大屏设备用冒泡阶段。嗯，这个经验是从一次手表应用翻车中得来的。

小结

UI层设计，说白了就是让用户在不同屏幕上都能获得一致的体验。组件复用解决的是「长得像」，响应式布局解决的是「摆得下」，主题管理解决的是「看得清」，事件分发解决的是「点得准」。这四个点缺一不可。

最后说一句：不要为了技术而技术。我见过有人把响应式布局做得极其复杂，结果加载速度慢了一倍。用户不会关心你用了什么技术，他们只关心好不好用。所以，保持简单，保持实用。