产品经理：为什么你做的地图比以前丝滑了许多？

import MyComponent from './MyComponent.vue'

// 以普通点标记举例
new Marker({

    content: MyComponent,
// ...other configs

})

// not work

import {createApp} from 'vue'
import MyComponent from './MyComponent.vue'

const app = craeteApp(MyComponent)

const div = document.createElement("div")

app.mount(div)

console.log('div: ', div)

// 以普通点标记举例
const marker = new Marker({

    content: div,
// ...other configs

});

// example
import { createGlobalState } from "@vueuse/core";
import { ref, createApp } from "vue";
import Map from './Map.js' // 地图实例
import MyComponent from "./MyComponent.vue";

export const useCustomPoints = createGlobalState(() => {
const pointData = ref([]);
const removePointsCb = [];

const setPoint = () => {
const data = pointData.value.map(point => {
const div = document.createElement("div");
const app = createApp(MyComponent);

            app.mount(div);


            removePointsCb.push(() => app.unmount()) // 清除图标实例的回调

// 以普通点标记举例
const marker = new Map.Constructors.Marker({

                map: Map,

                content: div,
// ...other config

            });

return marker

        })

Map.add(data); // 将点添加到地图上


        removePointsCb.push(() => Map.remove(data)); // 移除点的回调

    }

const removePoints = () => {
while (removePointsCb.length) {

            removePointsCb.pop()();

        }

    };

return {

        pointData,

        setPoint,

        removePoint

    }

})

好了，言归正传。

看起来似乎三种方法都可以实现需求，但是仔细翻看点聚合方法的文档，发现使用图片自定义点时没有提供旋转的配置，也就是说我们可能需要准备n张图片（取决于你想实现角度渲染的精确度），不，这太不优雅了。而如果使用原生HTML去自定义，要么接受丑炸的效果（纯手工css），要么面临着卡顿的风险（大量的app实例）

没办法，只好被（xin）迫（ran）接受用海量点PointSimplifier的Canvas去做了~毕竟能用Canvas画就约等于能画一切嘛~~

抱着视死如归的心情去翻了一下JS API UI组件库的海量点PointSimplifiercanvas绘制function文档，发现了一句了不得的话：

划重点：通常只是描绘路径、尽量不要fill或者stroke、引擎自己、一次性

翻译：该函数通常只是描绘路径，但是也能描绘形状。尽量不要fill或者stroke，除非你能搞明白我们的描绘机制。所有点的路径描绘完成后，引擎自己会在尾部调用fill以及stroke，一次性绘出所有路径，所以你要注意尾部的这次操作，避免冲突。

三个字总结海量点PointSimplifier的描绘机制就是：连笔画。

不是每个点都创建一个新的Canvas画布，绘制完成后立即渲染；而是所有的点都共用一个Canvas画布，以当次你能绘制的区域坐标作为参数，重复绘制n(点的数量)次，最后一把全渲染出来。

明白了这个，我们在书写function的逻辑的时候，只要注意保证每次绘制开始、结束时笔触的落点和绘制上下文状态即可。绘制一个有旋转角度的、中间有箭头的圆形（圆形的背景色是通过海量点PointSimplifier的lineStyle配置的），示例代码如下：

由于叠加了变换，处理状态时偷懒使用了save()、restore()

renderOptions: {
// 这里使用了样式分组引擎：https://lbs.amap.com/demo/amap-ui/demos/amap-ui-pointsimplifier/group-style-render
// 以点的旋转角作为组id入参，方便操作
// 无需分组时，renderOptions.pointStyle.content = renderOptions.groupStyleOptions.pointStyle.content  逻辑一致

    groupStyleOptions: function (gid) {
return {

        pointStyle: {

          content: function (ctx, x, y, width, height) {
// 存了一个坐标，画箭头的时候用
const startX = x + width / 2;
const startY = y + height / 4;

// 移动到画布的最右侧、中间位置
ctx.moveTo(x + width, y + height / 2);

// 画圆
ctx.arc(
x + width / 2,
y + height / 2,
width / 2,
0,
Math.PI * 2,
true
);

// 变换前保存一下状态
ctx.save();

// 以圆心为旋转的中心点
ctx.translate(x + width / 2, y + height / 2);
// 按照轨迹方向旋转
ctx.rotate((Math.PI / 180) * gid);
// 重置中心点
ctx.translate(-(x + width / 2), -(y + height / 2));

// 画箭头
ctx.moveTo(startX, startY);
ctx.lineTo(x + width / 4, y + height / 2);
ctx.moveTo(startX, startY);
ctx.lineTo(startX, y + (height * 3) / 4);
ctx.moveTo(startX, startY);
ctx.lineTo(x + (width * 3) / 4, y + height / 2);

// 由于箭头需要在旋转的状态下绘制，所以在箭头绘制完成后再恢复状态
ctx.restore();
},
},
};
},
}

来一个无旋转时的笔触顺序动图，我尽力了

画完之后，看一下对比效果：

前

后

前

后

OK，点画出来了。

上边特性中有提到：当我们距离很远时，就不需要再关注某个具体的轨迹点。所以可以再进一步优化，当地图的缩放等级zoom小于某个阈值时，清空point：

import {computed, watch, ref} from 'vue'
import {Map, PointSimplifierIns} from 'Map.js' // 地图实例、海量点实例

const zoom = ref(null);

const showPoint = computed(() => zoom.value > 10);

const pointData = ref([ /* ...赋值逻辑省略 */]);

Map.on("zoomchange", 
debounce(() => {

      zoom.value = Map.getZoom();

    }, 200)

);

watch(showPoint, (show) => {
PointSimplifierIns.setData(show ? pointData.value : []);

})

效果如下：

控制显示隐藏没有用自带的show()和hide()方法，而是选择直接重设数据源，是因为：海量点PointSimplifier在show状态下时对地图进行缩放，会自动重绘适应尺寸；hide状态下则不会。从show变为hide时，会保存当前zoom下点的尺寸，供下次hide到show时用。如果地图缩放的太快，当前的zoom与上次保存尺寸时的zoom跨度太大，可能会导致点位不匹配现象。

选择画轨迹的方法

画线的选择过程就简单了很多，之前需求中是用折线Polyline实现的，画出来的效果总感觉差点意思，所以就去翻了翻高德的文档，共找到常规画线方法3种：

• JS API
  1. 折线Polyline
  2. 贝塞尔曲线BesizerCurve
• JS API UI组件库
  1. 轨迹展示PathSimplifier

基本上毫无疑问了嘛~我们本身就是要画轨迹，还有什么好选的~~ 必须用轨迹展示哇

不过这里还是分享一些对三种方法实际体验之后的感受：

实现过程比较简单，照着文档撸就行，可以对比下折线和轨迹展示两种方式，在拐角细节处的差异：

折线

轨迹展示

小tips: 适当增加线宽lineWidth可以有效的缓解锯齿现象

Loading的区域与时机

当我第一次打开上文提到的老版本地图页面时，除了渲染效果不够理想外，最大的一个感受就是：Loading太长

不是想像中那样常规的：打开页面，给一个满屏Spin等待加载各种数据、等待绘制点、线的动作，所有准备工作完成后，取消Spin允许用户开始操作。

咱就是说，像这样的交互逻辑，其实也没啥问题。毕竟谁还没个业务繁忙的时候，最简单最原始最暴力的满屏Spin虽然在体验上不尽如人意，但我觉得是符合上线标准的。

但您猜我看到了什么？

Form、Map、Action Bar三个区域各自一个小Spin，整体有个大Spin，可以透过大Spin的透明遮罩层看到下面的小spin们反复交替进行，以及大Spin自己也时不时的闪现一下...

Spin为什么会闪现？回到需求当中来：

地图上点、线的绘制依赖了多个数据源

• 轨迹点、轨迹线数据源
• KeyPoint数据源
• SubPoint数据源
  • Type 1
  • Type 2

这些接口一部分是并发请求，但也有个别的接口请求参数依赖于其他接口的返回值

以及，使用高德地图提供的API绘制点、线时，也共用了接口请求时的Spin。

还有诸多类似这样的代码：

setTimeout(() => {

    loading = false

}, 2000)

对渲染流程管理混乱、对数据流向不了解、对自己代码不自信，故意延迟loading的结束时机，防止用户过早操作导致报错

const interval = setInterval(() => {
if(conditon) {
clearInterval(interval);

        loading = false

    }

}, 1000)

依赖第三方的内容加载，或将多个小loading合并为一个大loading

最终的结果就是让人一整个loading住...

而我做了哪些改变

首先，将单个loading覆盖的区域尽可能的缩小

举个例子，上边提到的Action Bar，假设里边既有展示KeyPoint信息的列表，又有展示所有SubPoint信息的列表。在之前的处理方案中，Action Bar区域只有一个整体的Spin，所以整个区域loading的流程大概是：

%%{init: { 'theme': 'base', 'themeVariables': {
'cScale0': '#996666', 'cScaleLabel0': '#ffffff',
'cScale1': '#996633','cScaleLabel1': '#ffffff',
'cScale2': '#999999', 'cScaleLabel2': '#ffffff'

       }}}%%


timeline

      title Loading 状态


      section 阶段一

      show : request for KeyPoint data

      hide : request success


      section 阶段二

      show : request for SubPoint type1 data

      hide : request success


      section 阶段三

      show : request for SubPoint type2 data

      hide : request success

而我则是把每个数据源对应的列表都单独分配了一个loading组件。

聪明的看官老爷可能会问，同时存在多个Spin，不也很奇怪吗？

所以我选择了骨架屏Skeleton作为loading组件：

受gif图的帧率影响，实际效果还是很丝滑的。（但使用骨架屏时也有一个注意的点：骨架屏的占位高度需要配置段落占位图行数来调整，避免loading结束时真实的渲染内容与骨架屏高度相差太大产生视差）

然后，在Map区域用其他形式的提示代替传统的loading

与上边类似，Map区域不仅同时用到了KeyPoint、SubPoint数据源，而且在绘制点、线时也有loading。并且也是一个整体的Spin，你应该能想象出每次数据初始化时，Map上闪来闪去的Spin。。。

而地图本身，是高德提供出来可以开箱即用的组件，我们所添加的点、线只是附加属性，并不应该使用整体的Spin遮罩阻止用户使用地图的其他功能。在某些附加属性成功添加之前，用户只需要知道与之相关的功能是不可用状态即可。

我的方案是：图例化提供一个loading-box，里边展示了每个数据源的加载状态

为了不遮挡地图，loading-box不是始终展示的，基础显示逻辑是：

显示动作是实时的，只要有一个数据源在loading中，就应该立刻让用户感知到。

而隐藏动作如果也是实时的，loading-box的显隐切换会比较频繁，显得很突兀。

• 如果使用setTimeout做延时，期望是发出hide指令n秒后执行，但无法保证n秒后没有新的loading正在进行，导致显隐切换逻辑紊乱。
• 如果使用throttle做延时，导致的问题与setTimeout相同，只是发生概率会小一些。
• 相比之下debounce最适合做这个场景的解决方案。

再结合上边提到的hook写法，把loading状态也放进去，方便loading-box使用：

// example
import { createGlobalState } from "@vueuse/core";
import { ref, createApp } from "vue";

export const useCustomPoints = createGlobalState(() => {
const pointData = ref([]);
const pointLoading = ref(false);
const removePointsCb = [];

const getPoint = async () => {

        pointLoading.value = true;
const data = await requestPointData();

        pointLoading.value = false;


        pointData.value = data;

    }

const setPoint = () => {
// ...

    }

const removePoint = () => {
// ...

    };

return {

        pointData,

        pointLoading,

        getPoint,

        setPoint,

        removePoint

    }

})

// loading-box.vue

<script setup>
import { watch } from 'vue';
import { useCustomPoints } from 'useCustomPoints.js';

const { pointLoading } = useCustomPoints();

watch([pointLoading, /* and other loadings */], () => {
// do loading-box show/hide logic

})
script>

应用了上述loading相关的优化后，虽然跟核心业务逻辑相关的代码改动几乎为0，但用户的体验却有相当大的提升，究其原因：

在老版本的实现中，因为全屏Spin的存在，任何一项页面准备工作完成前，页面都无可交互区域；拆分loading后，把一大部分无可交互区域的时间变成了局部可交互区域的时间，甚至在Map模块替换了loading的形式，完全避免了Spin遮罩层这种阻隔用户的效果。加上Spin动画本身的耗时、显示/隐藏Spin的耗时，积少成多，产生质变。

可以看到，在局部loading耗时完全一样的情况下，老版本中：

无可交互区域时间 = 全屏Spin时间 = 局部loading的最大时间

而在新版本中：

无可交互区域时间 = 几个all loading片段的时间之和

而这，也是一些复杂应用做体验优化的思路之一。

结语

okok，先写到这，毕竟马上就要下班了。

没什么高大上理论也没什么八股文，只是一个从业多年一事无成小前端在重构需求时的一些感想~~

还是那句话，欢迎真诚交流，但如果你来抬杠？阿，对对对~ 你说的都对~

彩蛋

文章标题来自需求上线后，产品经理的真实评价