在心理测评平台中，报告展示往往涉及到多维度的数据可视化。典型的元素包括用于呈现不同症状指标的雷达图，记录心理状态纵向变化的趋势折线图，以及常模比对的散点图。
为了实现这些功能，前端项目通常会引入 Apache ECharts 这样成熟的图表库。然而，在针对移动端网页或小程序进行开发时，如果不加控制地引入全量库，会对页面的性能和交互体验造成负面影响。本文将记录在移动端环境中应用 ECharts 时遇到的一些具体问题及处理方法。
全量引入带来的包体积问题
在一些项目的初期阶段，开发者可能习惯于采用最简单的全量注册方式：
“`javascript
import * as echarts from ‘echarts’;
“`
ECharts 的完整包包含了地图、3D 渲染组件以及许多项目中可能并不会用到的复杂图表类型。如果在移动端保留这些不必要的依赖，会导致最终构建产物体积过大。在受限于代码包大小规范（如小程序的限制）的环境中，这不仅增加下载耗时，也会延长 JavaScript 引擎的解析时间。
按需引入（Tree-Shaking）实践
为了优化加载效率，橙星云前端团队在报告模块的构建中制定了按需引入的规范。结合现代构建工具的 Tree-Shaking 机制，可以仅打包实际使用到的核心组件与图表类型。
具体的实现方式如下：
“`javascript
// 引入 echarts 核心模块
import * as echarts from ‘echarts/core’;
// 仅引入报告实际需要的图表类型，如雷达图和折线图
import { RadarChart, LineChart } from ‘echarts/charts’;
// 仅引入必要的组件
import { TitleComponent, TooltipComponent, GridComponent } from ‘echarts/components’;
// 引入渲染器，大部分场景下 CanvasRenderer 足够，轻量级场景亦可评估 SVGRenderer
import { CanvasRenderer } from ‘echarts/renderers’;
// 注册所需组件
echarts.use([TitleComponent, TooltipComponent, GridComponent, RadarChart, LineChart, CanvasRenderer]);
export default echarts;
“`
经过这种精细化的依赖管理，图表相关代码的体积可以得到有效控制，显著缩短了页面的首次渲染等待时间。
移动端的渲染与交互适配
在解决了包体积之后，移动设备上的实际呈现还会面临清晰度与交互冲突的问题。
1. 高密度屏幕下的 Canvas 模糊
当前大多数智能手机配备了高分辨率屏幕。如果图表在 Canvas 上直接按照 1:1 的逻辑像素进行绘制，会出现明显的边缘模糊或锯齿现象。
为了适配高清视网膜屏幕，在实例化 ECharts 时，需要显式传递设备的像素比，以实现高分辨率采样渲染：echarts.init(dom, null, { devicePixelRatio: window.devicePixelRatio })
2. 移动端滑动冲突
当图表渲染完成后，如果用户尝试在图表区域滑动以浏览下方长报告，往往会发现页面无法正常滚动。这是因为 ECharts 内部默认接管了 touch 相关事件以触发 Tooltip（提示框），并调用了 e.preventDefault() 阻断了浏览器的原生滚动。
要解决这个问题，可以通过调整图表的交互配置来释放滑动控制权。例如，在 options 中将提示框的触发方式改为点击：tooltip: { triggerOn: 'click' }
另外，对于一些纯展示性质、不需要复杂悬浮交互的静态图表，可以直接在图表容器的外层通过 CSS 属性 pointer-events: none 来禁用鼠标或触摸事件，从而将滑动行为完整地交还给原生的移动端环境。通过这些具体的适配，可以确保图表既能清晰呈现，又不影响长页面的基础阅读体验。