目录

1. 引言


2. 网约车系统


3. 
   
   
   
   1. 需求设计
   
   
   2. 概要设计
   
   
   3. 详细设计
   
   
   4. 体验优化
   
   
   
   


4. 小结

1.引言

1.1 台风来袭

深圳上周受台风“苏拉”影响，从 9 月 1 日 12 时起在全市启动防台风和防汛一级应急响应。

对深圳打工人的具体影响为，当日从下午 4 点起全市实行 “五停”：停工、停业、停市，当日已经停课、晚上 7 点后停运。

由于下午 4 点停市，于是大部分公司都早早下班。其中有赶点下班的，像这样：

有提前下班的，像这样：

还有像我们这样要居家远程办公的：

1.2 崩溃打车

下午 4 点左右，公交和地铁都人满为患。

于是快下班（居家办公）的时候就想着打个车回家，然而打开滴滴之后：

排队人数 142 位，这个排队人数和时长，让我的心一下就拔凉拔凉的。

根据历史经验，在雨天打上车的应答时间得往后推半个小时左右。更何况，这还是台风天气！

滴滴啊滴滴，你就不能提前准备一下嘛，这个等待时长，会让你损失很多订单分成的。

但反过来想，这种紧急预警，也不能完全怪打车平台，毕竟，车辆调度也是需要一定时间的。在这种大家争相逃命（bushi 的时候，周围的车辆估计也不太够用。

卷起来

等着也是等着，于是就回到公司继续看技术文章。这时我突然想到，经过这次车辆紧急调度之后，如果我是滴滴的开发工程师，需要怎么处理这种情况呢？

如果滴滴的面试官在我眼前，他又会怎么考量候选人的技术深度和产品思维呢？

2. 设计一个“网约车系统”

面试官：“滴滴打车用过是吧！看你简历里写道会架构设计是吧，如果让你设计一个网约车系统，你会从哪些方面考虑呢？”

2.1 需求分析

网约车系统（比如滴滴）的核心功能是把乘客的打车订单发送给附件的网约车司机，司机接单后，到上车点接送乘客，乘客下车后完成订单。

其中，司机通过平台约定的比例抽取分成（70%-80%不等），乘客可以根据第三方平台的信用值（比如支付宝）来开通免密支付，在下车后自动支付订单。用例图如下：

乘客和司机都有注册登录功能，分属于乘客用户模块和司机用户模块。网约车系统的另外核心功能是乘客打车，订单分配，以及司机送单。

2.2 概要设计

网约车系统是互联网+共享资源的一种模式，目的是要把车辆和乘客结合起来，节约已有资源的一种方式，通常是一辆网约车对多个用户。

所以对于乘客和司机来说，他们和系统的交互关系是不同的。比如一个人一天可能只打一次车，而一个司机一天得拉好几趟活。

故我们需要开发两个 APP 应用，分别给乘客和司机打车和接单，架构图如下：

1）乘客视角

如上所示：乘客在手机 App 注册成为用户后，可以选择出发地和目的地，进行打车。

打车请求通过负载均衡服务器，经过请求转发等一系列筛选，然后到达 HTTP 网关集群，再由网关集群进行业务校验，调用相应的微服务。

例如，乘客在手机上获取个人用户信息，收藏的地址信息等，可以将请求转发到用户系统。需要叫车时，将出发地、目的地、个人位置等信息发送至打车系统。

2）司机视角

如上图所示：司机在手机 App 注册成为用户并开始接单后，打开手机的位置信息，通过 TCP 长连接定时将自己的位置信息发送给平台，同时也接收平台发布的订单消息。

司机 App 采用 TCP 长连接是因为要定时发送和接收系统消息，若采用 HTTP 推送：

一方面对实时性有影响，另一方面每次通信都得重新建立一次连接会有失体面（耗费资源）。​

司机 App：每 3~5 秒向平台发送一次当前的位置信息，包括车辆经纬度，车头朝向等。TCP 服务器集群相当于网关，只是以 TCP 长连接的方式向 App 提供接入服务，地理位置服务负责管理司机的位置信息。

3）订单接收

网关集群充当业务系统的注册中心，负责安全过滤，业务限流，请求转发等工作。

业务由一个个独立部署的网关服务器组成，当请求过多时，可以通过负载均衡服务器将流量压力分散到不同的网关服务器上。

当用户打车时，通过负载均衡服务器将请求打到某一个网关服务器上，网关首先会调用订单系统，为用户创建一个打车订单（订单状态为 “已创建”），并存库。

然后网关服务器调用打车系统，打车系统将用户信息、用户位置、出发地、目的地等数据封装到一个消息包中，发送到消息队列（比如 RabbitMQ），等待系统为用户订单分配司机。

4）订单分配

订单分配系统作为消息队列的消费者，会实时监听队列中的订单。当获取到新的订单消息时，订单分配系统会将订单状态修改为 “订单分配中”，并存库。

然后，订单分配系统将用户信息、用户位置、出发地、目的地等信息发送给订单推送 SDK。

接着，订单推送 SDK 调用地理位置系统，获取司机的实时位置，再结合用户的上车点，选择最合适的司机进行派单，然后把订单消息发送到消息告警系统。这时，订单分配系统将订单状态修改为 “司机已接单” 状态。

订单消息通过专门的消息告警系统进行推送，通过 TCP 长连接将订单推送到匹配上的司机手机 App。

5）拒单和抢单

订单推送 SDK 在分配司机时，会考虑司机当前的订单是否完成。当分配到最合适的司机时，司机也可以根据自身情况选择 “拒单”，但是平台会记录下来评估司机的接单效率。

打车平台里，司机如果拒单太多，就可能在后续的一段时间里将分配订单的权重分数降低，影响自身的业绩。

订单分派逻辑也可以修改为允许附加的司机抢单，具体实现为：

当订单创建后，由订单推送 SDK 将订单消息推送到一定的地理位置范围内的司机 App，在范围内的司机接收到订单消息后可以抢单，抢单完成后，订单状态变为“已派单”。

2.3 详细设计

打车平台的详细设计，我们会关注网约车系统的一些核心功能，如：长连接管理、地址算法、体验优化等。

1）长连接的优势

除了网页上常用的 HTTP 短连接请求，比如：百度搜索一下，输入关键词就发起一个 HTTP 请求，这就是最常用的短连接。

但是大型 APP，尤其是涉及到消息推送的应用（如 QQ、微信、美团等应用），几乎都会搭建一套完整的 TCP 长连接通道。

一张图看懂长连接的优势：

图片来源：《美团点评移动网络优化实践》

通过上图，我们得出结论。相比短连接，长连接优势有三：

0. 
   

   连接成功率高

   
   


1. 
   

   网络延时低

   
   


2. 
   

   收发消息稳定，不易丢失

   
   

2）长连接管理

前面说到了长连接的优势是实时性高，收发消息稳定，而打车系统里司机需要定期发送自身的位置信息，并实时接收订单数据，所以司机 App 采用 TCP 长连接的方式来接入系统。

和 HTTP 无状态连接不同的是，TCP 长连接是有状态的连接。所谓无状态，是指每次用户请求可以随意发送到某一台服务器上，且每台服务器的返回相同，用户不关心是哪台服务器处理的请求。

当然，现在 HTTP2.0 也可以是有状态的长连接，我们此处默认是 HTTP1.x 的情况。

而 TCP 长连接为了保证传输效率和实时性，服务器和用户的手机 App 需要保持长连接的状态，即有状态的连接。

所以司机 App 每次信息上报或消息推送时，都会通过一个特定的连接通道，司机 App 接收消息和发送消息的连接通道是固定不变的。

因此，司机端的 TCP 长连接需要进行专门管理，处理司机 App 和服务器的连接信息，架构图如下：

为了保证每次消息的接收和推送都能找到对应通道，我们需要维护一个司机 App 到 TCP 服务器的映射关系，可以用 Redis 进行保存。

当司机 App 第一次登录，或者和服务器断开连接（比如服务器宕机、用户切换网络、后台关闭手机 App 等），需要重连时，司机 App 会通过用户长连接管理系统重新申请一个服务器连接（可用地址存储在 Zookeeper 中），TCP 连接服务器后再刷新 Redis 的缓存。

3）地址算法

当乘客打车后，订单推送 SDK 会结合司机所在地理位置，结合一个地址算法，计算出最适合的司机进行派单。

目前，手机收集地理位置一般是收集经纬度信息。经度范围是东经 180 到西经 180，纬度范围是南纬 90 到北纬 90。

我们设定西经为负，南纬为负，所以地球上的经度范围就是[-180， 180]，纬度范围就是[-90，90]。如果以本初子午线、赤道为界，地球可以分成4个部分。

根据这个原理，我们可以先将二维的空间经纬度编码成一个字符串，来唯一标识司机和乘客的位置信息。再通过 Redis 的 GeoHash 算法，来获取乘客附加的所有司机信息。

GeoHash 算法的原理是将乘客的经纬度换算成地址编码字符串，表示在某个矩形区域，通过这个算法可以快速找到同一个区域的所有司机。

它的实现用到了跳表数据结构，具体实现为：

将某个市区的一块范围作为 GeoHash 的 key，这个市区范围内所有的司机存储到一个跳表中，当乘客的地理位置出现在这个市区范围时，获取该范围内所有的司机信息。然后进一步筛选出最近的司机信息，进行派单。

4）体验优化

1. 距离算法

作为线上派单，通过距离运算来分配订单效果一定会比较差，因为 Redis 计算的是两点之间的空间距离，但司机必须沿道路行驶过来，在复杂的城市路况下，也许几十米的空间距离行驶十几分钟也未可知。

所以，后续需综合行驶距离（而非空间距离）、司机车头朝向以及上车点进行路径规划，来计算区域内每个司机到达乘客的距离和时间。

更进一步，如果区域内有多个乘客和司机，就要考虑所有人的等待时间，以此来优化用户体验，节省派单时间，提升盈利额。

2. 订单优先级

如果打车订单频繁取消，可根据司机或乘客行为进行判责。判责后给乘客和司机计算信誉分，并告知用户信誉分会影响乘客和司机的使用体验，且关联到派单的优先级。

司机接单优先级

综合考虑司机的信誉分，投诉次数，司机的接单数等等，来给不同信誉分的司机分配不同的订单优先级。

乘客派单优先级

根据乘客的打车时间段，打车距离，上车点等信息，做成用户画像，以合理安排司机，或者适当杀熟（bushi。

PS：目前有些不良打车平台就是这么做的 🐶  甚至之前爆出某打车平台，会根据不同的手机系统，进行差异收费。

4. 小结

4.1 网约车平台发展

目前，全球网约车市场已经达到了数千亿美元的规模，主要竞争者包括滴滴、Uber、Grab 等公司。在中国，滴滴作为最大的网约车平台已经占据了绝大部分市场份额。

网约车的核心商业逻辑比较简单，利益关联方主要为平台、司机、车辆、消费者。

平台分别对接司机、车辆【非必选项，有很多司机是带车上岗】和乘客，通过有效供需匹配赚取整个共享经济链省下的钱。

具体表现为：乘客和司机分别通过网约平台打车和接单，平台提供技术支持。乘客为打车服务付费，平台从交易金额中抽成（10%-30%不等）。

据全国网约车监管信息交互平台统计，截至 2023 年 2 月底，全国共有 303 家网约车平台公司取得网约车平台经营许可。

这些平台一部分是依靠高德打车、百度地图、美团打车为代表的网约车聚合平台；另一部分则是以滴滴出行、花小猪、T3 为代表的出行平台。

4.2 网约车平台现状

随着出行的解封，网约车平台重现生机。

但由于部分网约车聚合平台的准入门槛太低，所以在过去一段时间里暴露出愈来愈多的问题。如车辆、司机合规率低，遇到安全事故，产生责任纠纷，乘客维权困难等等。

由于其特殊的模式，导致其与网约车运营商存在责任边界问题，一直游离在法律边缘。

但随着网约车聚合平台的监管不断落地，全国各地都出行了一定的监管条例。

比如某打车平台要求车辆将司机和乘客的沟通记录留档，除了司机与乘客的在线沟通记录必须保存以外，还需要一个语音电话或车载录音转换，留存一段时间备查。

有了这些人性化的监管条例和技术的不断创新，网约车平台或许会在未来的一段时间内，继续蓬勃发展。

后话

面试官：嗯，又专又红，全面发展！这小伙子不错，关注了~

webp的几个问题

1. 什么是webp?

最直接的就是一个图片的后缀是.webp而不是.png/.jpeg等,官方的说法就是由Google开发的一种用于图像压缩的现代格式，目的就是减小图片的大小从而提高网页加载速；

2. 是不是所有浏览器都支持webp图片？如何判断浏览器是否支持webp格式的图片

不是所有的浏览器都支持 WebP 图片格式，但大多数主流的现代浏览器都已经支持了。以下是一些常见的浏览器对 WebP 格式的支持情况：

• Google Chrome：支持 WebP 格式。


• Mozilla Firefox：支持 WebP 格式。


• Microsoft Edge：支持 WebP 格式。


• Safari：从 Safari 14 开始，支持 WebP 格式
  要判断浏览器是否支持 WebP 格式的图片，可以使用 JavaScript 进行检测。以下是一种常用的方法：

function isWebPSupported() {

  var elem = document.createElement('canvas');

  if (!!(elem.getContext && elem.getContext('2d'))) {

    // canvas 支持

    return elem.toDataURL('image/webp').indexOf('data:image/webp') === 0;

  }

  // canvas 不支持

  return false;

}



if (isWebPSupported()) {

  console.log('浏览器支持 WebP 格式');

} else {

  console.log('浏览器不支持 WebP 格式');

}

上述代码通过创建一个 canvas 元素，并尝试将其转换为 WebP 格式的图片。如果浏览器支持 WebP 格式，则会返回一个以 "data:image/webp" 开头的数据 URL。

通过这种方式，你可以在网页中使用 JavaScript 检测浏览器是否支持 WebP 格式，并根据需要提供适当的替代图片

3. 图片转换成webp之后一定会比之前的图片更小吗？

答案是否定的。一般来说，具有大量细节、颜色变化和复杂结构的图像可能会在转换为 WebP 格式后获得更好的压缩效果，反之有些转换后可能会比之前更大；所以最好是图片转换为 WebP 格式之前，建议进行测试和比较不同压缩参数和质量级别的结果，以找到最佳的压缩设置，对最终转换后变成更大的建议不做转换

4. 如何将图片转换成webp

• 图像编辑软件 如 Adobe Photoshop、GIMP 或在线工具，如 Google 的 WebP 编码器。这些工具可以让你将现有的图像转换为 WebP 格式，并选择压缩质量和压缩类型（有损或无损）


• 插件转换webp插件文档链接接入

5. 项目中如何接入？？

思路：

• 第一步肯定是转化将项目中的存储的图片文件通过插件转换出webp格式的图片


• 判断网页运行的浏览器是否支持webp格式的图片，如果支持，将项目中所有使用png/jpeg的图片的全部替换成webp

6. 转换出项目中图片的webp格式的图片

const imagemin = require("imagemin");

const imageminWebp = require("imagemin-webp");



function transformToWebp(destination, filePaths) {

    await imagemin([filePath || `${destination}/*.{jpg,png}`], {

        destination: `${destination}/webp/`, // 转换出的webp图片放置在什么目录

        plugins: [imageminWebp({quality: 75})] // 使用imageminWebp转换转换质量级别设置多少

    })

}

具体到项目中，我们只希望转换我们当前正在开发的文件夹中的图片，而且已经转化的未作修改的就不要再重复转化； 如何知道哪些是新增的或者修改的呢？ 想一想🤔️，是不是“git status”可以看到
所以开始做如下调整

// 获取git仓库中发生变更的文件列表

function getGitStatusChangedImgFiles() {

  return String(execSync('git status -s'))

      .split('\n')

      .map(item => item.split(' ').pop()

      .filter(path => path.match(/\.(jpg)|(png)/))

      );

};

返回一个包含变更图片文件路径的数组['src/example/image/a.png','src/example/image/b.png', '……']

const imgPaths = getGitStatusChangedImgFiles()

async function transformAllChangedImgToWebp() {

    const resData = await promise.all(

        imgPaths.map(path => {

            const imgDir = path.replace(/([^\\/]+)\.([^\\/]+)/i, "") // src/banners/guardian_8/img/95_copy.png => src/banners/guardian_8/img/

            return transformToWebp(imgDir, path)

        })

    ) 

    const allDestinationPaths = resData.map((subArr) => subArr[0].destinationPath)

    // 如果这里我们想将生成的webp图片自动的add上去，那么就这样：

    execSync(`git add ${allDestinationPaths.join(" ")}`);

}

什么时候转换成webp最好？

我们在commit的时候进行转换图片，以及自动将转换的图片进行提交
这样我们就可以运用git的钩子函数处理了；

npm install husky --save-dev



// .husky/pre-commit中

#!/usr/bin/env sh

. "$(dirname -- "$0")/_/husky.sh"



current_branch=`git rev-parse --abbrev-ref HEAD`



if [[ $current_branch === 'main']]; then

    # 生成 webp 图片

    npm run webp -- commit

fi

这样在我们commit时就会自动触发pre-commit钩子函数，在package.json中配置webp执行的脚步，执行上述transformAllChangedImgToWebp函数，然后在里面转换出webp图片并将新生成的webp自动git add上去，最后一并commit;

知识点

1. execSync是什么？

execSync 是一个 Node.js 内置模块 child_process 中的方法，用于同步执行外部命令。在 Node.js 中，child_process 模块提供了一组用于创建子进程的函数，其中包括 execSync 方法。execSync 方法用于执行指定的命令，并等待命令执行完成后返回结果。

const { execSync } = require('child_process'); const output = execSync(command, options);

2. git status -s 会显示每个文件的状态信息

• A：新增文件


• M：修改文件


• D：删除文件


• R：文件名修改


• C：文件的拷贝


• U：未知状态

3. execSync('git status -s')返回值是什么？

通过String后就可以变成可见的字符串了，然后通过分割等就能拿到具体的修改的文件路径

4. Husky是什么？

Husky 是一个用于在 Git 提交过程中执行脚本的工具。它可以帮助开发人员在代码提交前或提交后执行一些自定义的脚本，例如代码格式化、代码质量检查、单元测试等。Husky 可以确保团队成员在提交代码之前遵循一致的规范和约定。

Husky 的工作原理是通过在 Git 钩子（Git hooks）中注册脚本来实现的。Git 钩子是在特定的 Git 事件发生时执行的脚本，例如在提交代码前执行 pre-commit 钩子，或在提交代码后执行 post-commit 钩子。push代码前执行pre-push的钩子、编写提交信息时执行commit-msg的钩子可用于提交什么规范

小结

1. 通过execSync('git status -s')从中获取筛选当前新增/修改过的图片；


2. 调用imagemin和imagemin-webp将图片转换出webp格式的图片


3. 在husky的pre-commit中触发上述调用执行，并在里面顺道将新生成的webp一并add上去


4. 至于后续生成的webp图片怎么使用，这将在下一篇文章中学习

公众号：赵侠客 

侠客说：优秀人才的四个特征：格局、思路、实干、写作

一、前言

1.1 述职答辩的重要性

公司都会有晋升通道，述职答辩是你想升职加薪除了跳槽以外的必由之路，其重要性对个人发展来说不言而喻，对公司来说也是选拔人才的重要通道。本人不才就职的也不是什么大厂，职级之前也比较低，都没有资格参加述职答辩，这次是人生第一次，所以格外的重视，这也导致了一些本来不该发生的事，对述职答辩产生了很大的影响，后面我会详细的说明。

1.2 述职答辩的流程

答辩的流程主要有四个环节：答辩人候选、准备PPT、现场答辩、公布结果。

• 
  

  答辩人候选：这是门槛，比如你的工作年限、工作能力、岗位职级、薪资范围，都达到这个门槛才有资格去答辩，这次答辩候选人让我有两点感触较深，一个是有些工作很多年的老同事没有资格答辩，另外一个是外包转正基本上也没有资格答辩；

  
  


• 
  

  准备PPT：PPT在述职答辩中的重要性绝对是最重要的没有之一，PPT本身有两个非常重要的点，美观和内容，好看的PPT会给领导非常好的第一印象，自己没有能力做好PPT这时就不要在乎几十块钱了，直接网上买个好看的模板。内容就要靠你自己了，后面我会详细说内容的注意事项。

  
  


• 
  

  答辩当天：答辩当天按事先排好的顺序依次进入会议室，等待过程是极其痛苦的，进入会议室后先让你陈述你的PPT，一般是你单独坐一排，对面坐了一排领导，公司高层领导、技术专家、外面请过来的专家，进入会议室面对一排大佬瞬间压迫感就上来了。陈述PPT的时间一般也就十分钟左右，陈述结束后就是专家、领导提问环节，一般也是十分钟左右。

  
  


• 
  

  公布结果：就像科举放榜是喜是优，也就尘埃落定了。

  
  

二、关于PPT

2.1 美观

谁都喜欢好看的东西，我当时第一版PPT做好后，拿给了我的前领导帮看看，他直接说你这PPT做的太差了，给我提了几个很多好的建议，他是我工作以来对我帮助最大的领导，我刚到他下面他就给我涨薪，要不是他我感觉我坚持不到现在，疫情三年太难了，疫情后各种裁员根本没有涨薪机会，要不是他给我涨薪我肯坚持不到现在，在这里要深深的谢谢他。关于美观的PPT我有以下三个建议：

• 
  

  做的PPT一定要让别人看：每个人审美不一样，你觉得好看的，别人不一定觉得好看，做好的PPT一定多找几个人看看，特别是你的领导或者搞设计的妹子们，领导看的PPT多，一眼就知道问题出在哪里，搞设计的妹子们往往审美还是好的，不像我们这种搞技术的汉子。

  
  


• 
  

  一定要和别人对比：没有对比就没有伤害，我的第一版PPT让领导看后，他说你去看看谁谁的PPT做的很好，于是我去要了对比一下自己做的确实太差了。

  
  

2.2 内容

如果说美观是锦上添花那么内容才展示你真正实力的地方，答辩PPT内容都是有一定模板的，比如从个人履历、能力技能、工作成果、不足之外、未来规划等方面陈述，关于每一点我详细说一下：

• 
  

  个人履历:学历和以前的所有工作经历都要写，可以简写但一定要有，否则你就是在掩饰。我们这次答辩很多人学历和专业没有写，后面HR要求所有人必须给写上，答辩时学校不是清华、北大、985这种耳熟能详的好学校，你可以不说学校名称，PPT上让领导看到就好，如果你的专业和你的工作相关的，一定要说一下你在读这个专业时做了和你现在工作相关的事，让领导觉得你是专业科班出生身的。有些工作很多年的老员工把很早以前的经历不写了，这点也是不好的，领导不知道你以前是干什么的，这让人有点不放心，是不是干过什么见不得光的事。

  
  


• 
  

  能力技能:这个要对标你们的评定职级标准，公司评定职级都有评定标准，这个职级标准很有可能就是答辩委员制定的，所以在写这部分内容时，你就要对着这个职级标准来表明自己在各方面已经达到职级标准，就应该是这个级别的。在说技能的时候也可以说一些不是职级标准上的但是也能反映你的能力事，比如这次答辩我说了自己写文章超200+，阅读量超120W+，还有阅读量超10万+的文章，在最后大领导总结这次答辩优秀人的四个特征中最后一个是写作，我感觉效果还是不错的。

  
  


• 
  

  工作成果:这部分可以说是整个PPT中最重要的没有之一，领导高高在上，你做的再多，他们也不知道是你做的，这部分就要让领导知道，原来我们公司这么重要的产品后面是你做出来的，这里有两点注意，一是所有成果都要展示，我当时觉得做的东西太多了，没有写，被我们领导说了，成果是你对公司的贡献，越多越好，让领导觉得你是个实干的人，这也是领导总结的优秀人才的第三个关键特征。二是在多的同时要有重点，不能只有数量没有质量，一定要重点说一到两个项目，从专业的角度分析，说说你在里面做了什么，给公司带来了哪些好处，一定要从上帝视角描述给领导听，不能说太多细节，因为领导也不懂细节技术，比如我们做开发的，就从整个项目的架构上来说。这次我知道有一个前端给领导印象就不好，他说优化前端Tab页加载，切换就花了3分钟的时间，领导会觉得一个tab页切换会对公司有多重要吗？领导要看到的是你给公司层面带来了什么价值，在优秀人才特征总结中，领导第一说的就是 格局，你是一颗螺丝钉你也要知道整个工厂是怎么运转的，如果你只做你的螺丝钉那么你也就是个工具人，容易被别人替代，未来也会被AI替代。

  
  


• 
  

  不足之处:这部分一定要能自圆其说，并给出以后如何改进

  
  


• 
  

  未来规划：这点是展示你是不是一支潜力股，规划一定要符合公司的大方向，视野要高，不过也不能假大空，根本实现不了的就不要写了，让领导觉得你是个实干的人。当时我准备写利用大模型解决我们多年以来未能解决的问题，然后想了想，万一领导真把这任务交给我了，搞不定怎么办？

  
  

三、关于陈述

3.1 陈述时间

陈述时间有严格要求的，领导一天要答辩那么多人，也想早点结束，所以要控制好你的时间，关于时间我有两个建议：

• 
  

  答辩前多练习:最好把答辩10分钟所有内容都记下来，在答辩前做到无稿胜有稿，心中有稿，内容都记下来，多练习几次，用的时间也就固定下来的，我练习了不少于10次，早上睡不着，我起的很早，去楼下小公园散散步，缓解一下压力，就在公园里拿起手机练习一下，晚上睡觉时，脑中展示PPT，然后脑中播放每一张内容，心中练习一遍。

  
  


• 
  

  答辩时放个手机计时: 有了手机计时，每一部分花了多少时间，自己心中有数，比如我这次最后一部分时间大概要花2分钟，在最后第二部分的时候我会看一下时间，如果离2分钟还多，我会把前面的内容再找一个展开说一下，如果时间不多了，就可以跳过几点，简单过一下，保证到最后一部分时候大概还剩2分钟，这样后面时间就好控制了。

  
  

3.2 语速

答辩语速一般都是相对较快的，太慢了会让领导听着急，不过也不能太快，有些老领导思路可能跟不上人的语速。好的办法是在答辩前，给你的直属领导演练一下，让他们给你听听效果怎么样，提提建议。这时你的直属领导是你最大的靠山，他们也会尽心尽力帮助你的。因为你表现非常好，他在大领导面前也是有脸面，表现太差了也会让大领导觉得他下面人不咋地。

3.3 工具

这次答辩我就吃了工具这个亏，关于工具我有以下几次建议：

• 
  

  答辩用的什么格式你就用什么格式: 我一直都用MAC电脑的KeyNote，最后导出的成PPT，导出后发现一些字体没了，有些样式坏了，在上交PPT最后一分钟我还在改样式。

  
  


• 
  

  答辩用的电脑是什么软件你就用什么软件：当我坐下时不知道提供是的什么软件播放PPT，HR说：请开始你的演讲，我居然找不到播放PPT按钮在哪里，最后还是HR提示我在最左上角有一个小按钮才让我播放起了PPT。

  
  


• 
  

  最好提前去会议室演示一下：我们这次答辩会议室提供的投影仪无法显示PPT演讲者注释，有些没有背下来的人就吃了亏。

  
  

四、关于提问

4.1 评委

最中间的肯定是最大的领导，这次是公司最大的领导，两边往往是从外面请过来的专家，还有一些像公司的人力资源老大，最后一般还有你的分管大领导，这个人是非常重要的，如果你真的场面控制不住，他一般会帮你说话的，他的帮助对你也是非常重要的。如果你是老员工这里的大领导有可能还会认识几个，新员工肯定是不认识这些领导的，对面坐一排不认识的大佬压迫感还是很强的。如果有认识的领导那自然是轻松的，他是做什么的你都了解，那他提问的方向大致也就知道了。

4.2 提问

大领导的问题，一般不会考察你的技术，最大领导在最后述职总结中说到优秀人才的第二个特征是思路，他们是想考察你解决问题的思路。毕竟这些专家早已脱离一线工作多年，在架构、源码、算法方面我们这些干活的高P才是公司最强的，他们的优势的丰富的行业经验和管理经验、解决问题的方案论、整合资源的能力，所以他们的问题一般会从这些角度来问。不过如果是低P答辩，委员是一些一线实战的开发人员，那这个提问环节基本上就是技术面试环节了，八股文该准备还是要准备。专家问我的问题基本上就是一些能显示他确实是这方面的专家的问题，也就一些常规行业问题的解决方案，真正做过这块业务的都能答上来，关键是你要整理思路，让其它领导们也能听起来确实是这么回事，有一种不明觉厉的感觉，这就算是成功了。还有一些无非是工作、团队协作、管理方面有没有遇到问题，你是怎么解决之类的通用问题。回答这类问题有一个非常重要的点，当你说到有问题时，一定要给出解决方案，没有解决方案的问题就是抱怨，在领导面前抱怨这是大忌。在提问环节主要展现的是你的精神面貌、交流沟通能力、解决问题的思路，都不是什么难问题，最大的问题是有人会给你挖坑。

4.3 坑

注意坑才是提问环节最需要的。比如这次我就被掉到坑里了，这也是我这次述职中最失败的地方。有些人问的问题会有前后关联关系，而且和你前面同事问的问题还会相关。

​

我们先看这个坑是怎么掉进去的，问题一是"你们代码复用性如何？"，我觉得这个问题不需要思考，肯定是高啊，然后举了多个项目复用同一个功能的例子来说明代码复用性确实高。问题二是"你和前面同事平时沟通交流怎么样？"，这个问题我当时也是没有思考，肯定是非常好，还说了一些合作的项目，最后他说“那他怎么说你们代码复用性不高”，最后在大领导面前得出的结论就是你们团队管理有问题，回去要加强沟通。当时我感觉整个人瞬间石化了，没有思考这个问题，现在想想他就是在转移我的注意力，如果换个问法，”你们代码中有没有不可复用的地方吗？为什么？“我相信这个每个人都可以回答上来，把责任推给客户就好了，客户花钱提的个性化需要，不合理也要做，代码肯定不能复用。他这个问题是将你当时的注意力转移到你和同事之间沟通有问题，而不是让你去思考代码有没有不可复用的地方。后面我问了我的同事，问他的问题，也是将他带入到客户定制化需求比较多，代码不能复用，所以开发工期比较长的路子上，他如果回答代码复用性高，那他肯定会问为什么开发用了那么长的工期？这个领导太厉害了，每个问题都是环环相扣，还和其他人相关，防不胜防。现在想想还是当时被带进去了，直接回答代码整体上复用性高，有些客户提的个性化需求无法拒绝，导致部分局部代码不可复用不就好了？不过有一两个问题回答不上来也无所谓，最后是最大领导提问，他们问题就好回答了，“你的优化、改进是领导安排的还是自己主动去钻研的？”，这个就说重大业务相关的是领导安排的，有些技术上改进是自己钻研的，大领导最后和旁边领导说：”他是攻坚型的，以后有些攻坚任务也可以交给他，你要继续保持“。听到“继续保持”这四个字，我终于彻底释放了，没有什么比领导口中这四个字更重要了，最后感谢领导就结束答辩。

五、关于紧张

5.1 紧张

向我们这种整天和代码打交道，从来没有向大领导汇报过工作，突然来这么一次重要的答辩不紧张那都是万里挑一，我是尤其的紧张，从答辩前两天就开始紧张了，紧张到精神影响到身体，导致胃痛。

研究显示，长期的高压工作可能会引起胃肠道功能紊乱。平日我们也会注意到，有些人一紧张就会肚子不舒服知识分子，公众号：知识分子工作压力怎样伤害了你的肠胃？|一周科技

我是答辩前两个晚上基本上没怎么睡，而且整个人的神经特别敏感，晚上有一点小的动静，就可以明显的感觉到身体神经信号从耳朵传到胃部导致胃癌疼痛，医学上应该叫作“神经衰弱”，还好我之前就是这种问题，所以买了防噪音耳塞。

最大的问题是紧张会让你喉咙里有异物，想要呕吐，这对要答辩的人来说是致命的，然而越是担心这个问题，就会导致问题越严重。

当我们感到有压力时，整个神经系统会加速运转，帮助我们应对面临的任何挑战。大脑分泌肾上腺素和皮质醇（主要的应激激素），并通知自主神经系统加速呼吸、心率、血压和肌肉收缩。这意味着喉咙、胃和肠道可能会产生紧绷感甚至痉挛，导致我们感到喉咙里有异物，肠道或胃里绷得很紧，想要呕吐，或增加肠道痉挛，以至于接二连三想去上厕所。Melissa G. Hunt，公众号：加州健康研究院科学解释：为什么压力大会导致胃疼？

我真怕自己在答辩时呕吐。根本吃不下去东西，我只能买点馒头放工位，饿了吃一点。精神类的药物一般起作用都是非常慢的，这两天肯定是不能吃的，只能先治标，买了点缓解胃酸分泌过多的胃药，我也没时间去医院看，说实话，像我这种状况去医院还不先让你来个大套餐，什么胃镜、抽血化验统统按排上，而且我觉得看病的医生不一定有我懂的多，他们也就是按系统开发好的步骤来，现在大部分门诊医生都是医疗系统操作员，现在医院什么症状做什么检查，然后什么检查结果吃什么药，都在系统里。还不如自己给自己开药，直接去药店买好了。

​

我老婆和家人都不相信这是紧张导致的胃痛，我判断只要答辩结束所有症状都没了，那就是紧张导致的。当我在门外等着进去的时候，真的感觉自己要站不住了，这时我给自己肩膀按按摩放松肌肉，闭上双眼，深呼吸，放空思想转移一下注意力，感觉好了点，当我进去坐下来时，居然找不到PPT播放按钮时，就更紧张了，不过等到讲PPT时反而好点了，当提问环节和领导对话几次所有症状就全部消失了，因为这时你的注意力在别人身上，已经不再注意你的身体问题了，自然也就好了。答辩结束后我的直属领导看到我时就说，侃大山的赵侠客又回来了。昨天还吃不下去饭，结束后大鱼大肉立马吃了起来，补补这两天的损失。

六、总结

打工人真不容易，这次答辩让我有以下几点总结：

1.有一个好领导很重要，我工作这么多年遇到的几个领导对我都很好，特别是上个领导，在这里要再次真诚的感谢 他， 如果他能读到本文，真诚的谢谢您！

2.在公司尽量和每个领导都保持好关系，说不定他就是你的答辩委员 

3.打铁还需自身硬，不断提升自己才能让你有更多机会 

4.锻炼好身体，身体是一切的前提，没有好的身体一切都没有意义 

5.工作久了能不跳槽还是不要跳，新环境没人能帮你

6.除了工作技能之外，自己一定还要有点其它的长处，比如写作、写专利、写论文 

7.不要接受外包，除非你工作是为了生存或者为了体验生活

🙋🏻‍♀️ 编者按：本文作者是蚂蚁集团前端工程师芒僧，今年 8 月份开始到 9 月底，「支付宝 - 基金」里面的指数专区进行了一波大改版升级，这次借助 F2 4.0 强大的移动端手势交互能力，我们尝试了一种多维度探索式选基决策工具，本文具体介绍了它是如何实现的。

这次在 「支付宝 - 基金」里的【指数专区改版】需求，我们玩了一种很新的东西 🌝

8月份开始到9月底，「支付宝 - 基金」里面的指数专区进行了一波大改版升级，这次借助 F2 4.0 强大的移动端手势交互能力，我们尝试了一种多维度探索式选基决策工具（如上动图所示）。

简单来说，用户可以在一个散点图上根据 「收益」和「波动」 这两个维度全览对比整个市场里的指数基金，并选出适合自己的指数基金进行投资，这个功能我们愿称其为 「指数图谱」 🐶 。

图谱是这个业务场景上的叫法，实际上图谱应该是关系图而非统计图.

功能已发布，页面访问路线如上

先看看有哪些功能点

1. 精细打磨的移动端手势交互，平移、缩放、横扫不在话下 ：

依次为：缩放、平移、横扫

2. 底部产品卡和图表的联动交互：

依次为：点击图表上的气泡、滑动底部卡片

3. 无惧数据点太多看不到细节，我们有自适应的气泡抽样展示和自动聚焦：

依次为：抽样优化前、抽样优化后

那么，怎么做的呢？

最开始看到这个需求的时候，当时觉得可行性比较低。因为需求里面针对图谱的方案以及细节都特别模糊；不敢承诺各种功能和排期，所以先做了一轮比较完整的系分，增加一些说话的底气🫣

📱 第一步：同类产品调研

因为设计同学的灵感来自于 大众点评APP 上面的「美食地图」，所以第一步就是做了一次「同类产品调研」，仔细去看了一下 「美食地图」上究竟有哪些花样，有哪些体验优化的小细节，不看不知道，一看发现细节原来这么多啊 🤕：

图表和卡片的交互联动	点抽样展示	列表视图和卡片视图可切换	交互时卡片自动折叠	散点懒加载	上滑直接唤起详情页

做完这一步之后，大概能够知道自己距离“成品”有多远的距离，方便自己评估工期；另外还可以在系分评审的时候把这些细节提出来，防止临近发布了突然发现某个交互逻辑有个致命的漏洞（别问我怎么知道的，要命的）。
这波调研之后，最终我们在实现上致敬了「美食地图」50% 的体验细节优化 （狗头）。

⚙️ 第二步：功能点分析

第二步就是从需求本身的角度做功能点的分析，这样可以方便我们拆分组件，为后续做分层设计打下基础，明白哪些是需要支持可扩展的。这一步大家都熟悉，就不赘述了：

📦 第三步：通用化设计

有了功能点的分析之后，就可以进行通用化的设计了，这就来到了喜闻乐见的沉淀组件的设计环节 🌝

我们希望这个功能不仅仅是纯业务代码**，期望下次能够复用大部分核心功能 **（理想很丰满），所以在系分的时候是往通用化的方向去设计的，这里主要做了三件事情：分层设计、概念标准化、核心流程定义

1. 分层设计

拆的逻辑是按最基础的 M(数据层) - C(控制层) - V(视图层) 拆分的。

有了分层设计和功能点分析之后，就可以知道哪些应该放到组件内，哪些接口应该被抽象成通用接口，哪些应该保留扩展性供使用者自己来定义，就可以画个表格了，一一决定哪些模块应该放到组件内：

2. 概念标准化

下面来到造词环节，把一些常用的概念都定义成一个个名字，这样方便和后端、设计协同的时候效率更高，同时也方便自己定义清楚各个模型（类）。（这里其实取名越贴切越形象越好，有点考验语言能力了属实是）

3. 核心流程定义

这一步是脑补环节，在脑子里跑一遍整体的流程，也是整个需求最核心的流程，比如这里会分成四种流程：初始化流程 、散点图交互流程、底部卡片交互流程、顶部tab交互流程；

进而可以将四种流程里面的各节点做一些归类，比如都会有图表渲染、数据补全、卡片渲染这些共同的节点，而这些节点就可以实现成具体模型里的具体方法。

🌝 第四步：难点分析

根据上面拆分的各模块，列出哪些点是实现有困难的，耗时长的。这样就可以在评估工期的时候多 Battle 一下，还能砍砍需求，更可以让底层引擎/SDK来突破这些难点（比如找 F2 的核心开发者） :

📃 最后一步：

按照上述的设计进行代码编写。

难点实现

1. 移动端的图表手势交互体验优化

开发之初，F2 只支持单轴（x或者y）的平移缩放，也不支持全方向交互；在 swipe 上的体验也不太好（阻尼感很强），所以在项目开发过程中， F2 完成了很多体验优化，打磨出很多细致入微的良好体验：

• X轴、Y轴可同时开启平移、缩放


• swiper 体验效果优化


• 移出可视区之后的蒙层遮挡能力（view-clip)


• zIndex 元素层叠渲染


• 平移缩放性能优化

2. 气泡抽样展示优化

因为散点图上的点在初始化的缩放比例下分布非常密集，所以如果每个点上面都绘制一个气泡的话，就会显得密密麻麻的，根本无从下手（如下图1所示）。针对这样的问题，做了「气泡抽样展示」的优化。

实现方式上就是渲染前遍历所有的点，如果在这个点周围某个半径距离之内有其他点，那么就认为这个点是脏点（dirty point)，最后筛选出所有“干净”的点进行气泡展示。

如下图图1所示，灰色点（右上角）是干净点，而灰白色的点（偏中间的位置）因为其在圆圈半径范围之内有其他点存在，所以这个点是脏点。

多提一句，这样的过滤方式会使得密集区域的点都不会展示气泡，后续会进行优化。

3. 获取到可视区内的所有点

由于做了气泡抽样展示，所以上图中的底部卡片只会展示用户可视区内散点图上有气泡的点（细心的盆友可以发现，散点图上有两种点，一种是带气泡的交互点，一种是不带气泡的缩略点）。那么就需要一个获取「可视区内所有的点」，实现思路如下：

- 监听 PanEnd(平移结束）、PinchEnd(缩放结束）, SwipeEnd(横扫结束）的事件

 - 获取到平移/缩放/横扫之后最新的 scales

 - 根据最新的 scales 里面的 x、y 的 range 过滤一遍图表原数据

 - 将脏点从上一步的结果过滤出去

 - 底部卡片根据上一步的结果进行渲染展示

- 结束

                                           

// 根据当前的缩放比例，拿到「可视区」范围内的数据

function getRecordsByZoomScales(scales, data) {

  const { x: xScale, y: yScale } = scales;

  const { field: xField, min: xMin, max: xMax } = xScale;

  const { field: yField, min: yMin, max: yMax } = yScale;



  return data.filter((record) => {

    const isInView =

      record[xField] >= xMin &&

      record[xField] <= xMax &&

      record[yField] >= yMin &&

      record[yField] <= yMax;



    return isInView;

  });

}

// 使用时

export default props => {

  // 图表原数据

  const { data } = props;

  

  function handlePanEnd (scales, data) {

    // 手动高亮下面这一行

    getRecordsByZoomScales(scales, data);

  }

  

  return (

     <ReactCanvas>

       <Chart>

         {/* ... */}

         <ScrollBar onPanEnd={handlePanEnd}/>

       </Chart>

     </ReactCanvas>

  )

  

}

4. 数据懒加载

底部卡片的数量是由散点图上点的数量决定的，而每张卡上都有不少的数据量（基金产品信息、指数信息、标签信息），所以不能一次性就把所有点里关联的数据都查询出来（会导致接口返回数据过多）。

这里采取的是懒加载的方式 ，每次只在交互后查询相邻 N+2/N-2 张的卡片数据，并且增加了一份内存缓存来存储已经查询过的卡片数据：

基本的流程图如下：

- 触发散点图交互/滑动底部卡片

	- 读取缓存，过滤出没有缓存过的卡片

  - 发起数据调用，获取到卡片的数据

  - 写入缓存

  - 更新卡片数据，返回

- 更新卡片视图，渲染完成

实际线上效果

项目上线之后，我们发现散点图区域的交互率（包含平移，缩放）非常高，可以看出用户对新类型的选基工具抱有新鲜感，也乐于去进行探索；也有部分用户能够通过工具完成决策或者进行产品之间的详细对比（即点击底部卡片上的详情按钮），起到了一个工具类产品的作用 🌝 。

致谢

感谢 AntV 以及 F2 对移动端图表交互能力的支持。

为什么推荐使用ref而不是reactive

reactive本身具有很大局限性导致使用过程需要额外注意,如果忽视这些问题将对开发造成不小的麻烦;ref更像是vue2时代option api的data的替代,可以存放任何数据类型,而reactive声明的数据类型只能是对象;

先抛出结论,再详细说原因:非必要不用reactive! (官方文档也有对应的推荐)

官方原文:建议使用 ref() 作为声明响应式状态的主要 API。

最懂Vue的人都这么说了:推荐ref!!!!!!

reactive和 ref 对比

• ref 用于将基本类型的数据（如字符串、数字，布尔值等）和引用数据类型(对象) 转换为响应式数据。使用 ref 定义的数据可以通过 .value 属性访问和修改。


• reactive 用于将对象转换为响应式数据，包括复杂的嵌套对象和数组。使用 reactive 定义的数据可以直接访问和修改属性。

原因1:reactive有限的值类型

reactive只能声明引用数据类型(对象)

let  obj = reactive({

   name: '小明',

   age : 18

})

ref既能声明基本数据类型,也能声明对象和数组;

Vue 提供了一个 ref() 方法来允许我们创建可以使用任何值类型的响应式 ref

//对象

const state = ref({})

//数组

const state2 = ref([])

原因2:reactive使用不当会失去响应:

reactive一时爽,使用不恰当的时候失去响应泪两行,开开心心敲代码过程中,会感叹!!咦?怎么不行?为什么这么赋值失去响应了? 辣鸡reactive!!! 我要用 ref 👉👉yyds

1. 给reactive赋一整个普通对象/reactive对象

通常在页面数据回显时,需要将AJAX请求获取的对象直接赋值给响应式对象,如果操作不当就导致reactive声明的对象失去响应

• 
  

  赋值一个普通对象

  
  

  let state = reactive({ count: 0 })
  
  //这个赋值将导致state失去响应
  
  state = {count: 1}
  
  

  
  


• 
  

  赋值一个reactive对象

  
  

  
  

  如果给reactive的响应式对象赋值普通对象会失去响应,那么给它赋值一个reactive的响应式对象不就行了吗?下面试试看

  
  

  
  

<template>

  {{state}}

</template>    

​

<stcirpt setup>

const state = reactive({ count: 0 })

 //nextTick异步方法中修改state的值

nextTick(() => {

  //并不会触发修改DOM  ,说明失去响应了

  state = reactive({ count: 11 });

});

</stcirpt>

在nexTick中给state赋值一个reactive的响应式对象,但是DOM并没有更新!

解决方法:

0. 
   

   不要直接整个对象替换,对象属性一个个赋值

   
   

   let state = reactive({ count: 0 })
   
   //state={count:1}
   
   state.conut = 1 
   
   

   
   


1. 
   

   使用Object.assign

   
   

   let state = reactive({ count: 0 })
   
   // state =  {count:1}   state失去响应
   
   state = Object.assign(state , {count:1})
   
   

   
   


2. 
   

   使用ref定义对象

   
   

   
   

   非必要不用reactive

   
   

   
   

   let state = ref({ count: 0 })
   
   state.value={count:1}
   
   

   
   

为什么同样是赋值对象ref不会失去响应而reactive会?

ref 定义的数据（包括对象）时，返回的对象是一个包装过的简单值，而不是原始值的引用;

就和对象深拷贝一样,是将对象属性值的赋值

reactive定义数据（必须是对象），reactive返回的对象是对原始对象的引用，而不是简单值的包装。

类似对象的浅拷贝,是保存对象的栈地址,无论值怎么变还是指向原来的对象的堆地址;

reactive就算赋值一个新的对象,reactive还是指向原来对象堆地址

2.将reactive对象的属性-赋值给变量(断开连接/深拷贝)

这种类似深拷贝不共享同一内存地址了,只是字面量的赋值;对该变量赋值也不会影响原来对象的属性值

let state = reactive({ count: 0 })

//赋值

// n 是一个局部变量，同 state.count

// 失去响应性连接

let n = state.count

// 不影响原始的 state

n++

console.log(state.count) //0

有人就说了,既然赋值对象的属性,那我赋值一整个对象不就是浅拷贝了吗?那不就是上面说的给响应式对象的字面量赋一整个普通对象/reactive对象这种情况吗?这种是会失去响应的

3.直接reactive对象解构时

• 直接解构会失去响应

let state = reactive({ count: 0 })

//普通解构count 和 state.count 失去了响应性连接

let { count } = state 

count++ // state.count值依旧是0

解决方案:

• 
  

  使用toRefs解构不会失去响应

  
  

  
  

  使用toRefs解构后的属性是ref的响应式数据

  
  

  
  

const state = reactive({ count: 0 })

//使用toRefs解构,后的属性为ref的响应式变量

let { count } = toRefs(state)

count.value++ // state.count值改变为1

建议: ref一把梭

当使用reactive时,如果不了解reactive失去响应的情况,那么使用reactive会造成很多困扰!

推荐使用ref总结原因如下:

0. 
   

   reactive有限的值类型:只能声明引用数据类型(对象/数组)

   
   


1. 
   

   reactive在一些情况下会失去响应,这个情况会导致数据回显失去响应(数据改了,dom没更新)

   
   

   给响应式对象的字面量赋一整个普通对象,将会导致reactive声明的响应式数据失去响应

   
   

   <template>
   
      {{state.a}}
   
      {{state.b}}
   
      {{state.c}}
   
   </template>
   
   ​
   
   <script>
   
    let state = reactive({ a:1,b:2,c:3 })
   
    onMounted(()=>{
   
        //通AJAX请求获取的数据,回显到reactive,如果处理不好将导致变量失去响应,
   
       //回显失败,给响应式数据赋值一个普通对象
   
       state =  { a:11,b:22,c:333 }
   
      //回显成功,一个个属性赋值  
   
       state.a = 11
   
       state.b = 22
   
       state.c = 33 
   
    })
   
   </script>
   
   

   
   

   上面这个例子如果是使用ref进行声明,直接赋值即可,不需要将属性拆分一个个赋值

   
   

   使用ref替代reactive:

   
   

   <template>
   
      {{state.a}}
   
      {{state.b}}
   
      {{state.c}}
   
   </template>
   
   ​
   
   <script>
   
    let state = ref({ a:1,b:2,c:3 })
   
    onMounted(()=>{
   
       //回显成功
   
       state.value =  { a:11,b:22,c:333 }
   
    })
   
   </script>
   
   

   
   


2. 
   

   ref适用范围更大,声明的数据类型.基本数据类型和引用数据类型都行

   
   

虽然使用ref声明的变量,在读取和修改时都需要加.value小尾巴,但是正因为是这个小尾巴,我们review代码的时候就很清楚知道这是一个ref声明的响应式数据;

ref的.value小尾巴好麻烦!

ref声明的响应式变量携带迷人的.value小尾巴,让我们一眼就能确定它是一个响应式变量!虽然使用ref声明的变量,在读取和修改时都需要加.value小尾巴,但是正因为是这个小尾巴,我们review代码的时候就很清楚知道这是一个ref声明的响应式数据;

可能有些人不喜欢这个迷人小尾巴,如果我能自动补全阁下又如何应对?

volar插件能自动补全.value (强烈推荐!!!!!!!)

本人推荐ref一把梭,但是ref又得到处.value ,那就交给插件来完成吧!!!

• 
  

  valor 自动补全.value (不是默认开启,需要手动开启)

  
  


• 
  

  不会有人不知道Vue3需要不能使用vetur要用valor替代吧?不会不会吧? (必备volar插件)

  
  

可以看到当输入ref声明的响应式变量时,volar插件自动填充.value 那还有啥烦恼呢? 方便!

本文会根据各位的提问和留言持续更新;

@ 别骂了_我真的不懂vue 说(总结挺好的,因此摘抄了):

reactive 重新赋值丢失响应是因为引用地址变了，被proxy代理的对象已经不是原来那个所以丢失响应了，其实ref也是一样的，当把.value那一层替换成另外一个有着.value的对象也会丢失响应 ref定义的属性等价于reactive（{value:xxx}）

另外说使用Object.assign为什么可以更新模板

Object.assign解释是这样的： 如果目标对象与源对象具有相同的键（属性名），则目标对象中的属性将被源对象中的属性覆盖，后面的源对象的属性将类似地覆盖前面的源对象的同名属性。

那个解决方法里不用重新赋值，直接Object.assign（state,{count:1}）即可，所以只要proxy代理的引用地址没变，就会一直存在响应性

1.前言

当代移动应用广告的过度侵扰问题已经引起了广大用户的关注和不满。而芒果TV平台运营中心的副总经理陈超推出了一项名为"摇一摇开屏广告"的新策略↓

引发了更多对于用户体验的担忧下↓

在这种策略下，用户在不经意间被强制打开广告，这对用户来说无疑是一种糟糕的体验。当人处于运动的状态下，打开某些APP。

而“李跳跳”APP通过利用Android的无障碍模式，"李跳跳"成功帮助用户自动跳过这些令人困扰的开屏广告，从而有效地减轻了用户的不便。随之而来的不正当竞争指控引发了对于这类应用的法律和道德讨论。

我决定仿“李跳跳”写一个广告跳过助手，以呼吁对于这种过度侵扰性广告的关注，同时也为广大Android开发者们分享运用的技术原理。

2.效果图

3.无障碍模式

当我们深入探讨"李跳跳"及其仿制应用的功能实现时，了解Android的无障碍模式和AccessibilityService以及onAccessibilityEvent函数的详细内容至关重要。这些技术是这些应用背后的核心，让我们更深入地了解它们：

3.1Android的无障碍模式

无障碍模式是Android操作系统的一个功能，旨在提高设备的可用性和可访问性，特别是为了帮助那些有视觉、听觉或运动障碍的用户。通过无障碍模式，应用可以获取有关用户界面和用户操作的信息，以便在需要时提供更好的支持。

3.2 onServiceConnected函数

这是AccessibilityService的回调函数之一，当服务被绑定到系统时会被调用。在这个函数中，可以进行初始化操作，如设置服务的配置、注册事件监听等。

@Override

public void onServiceConnected() {

    // 在这里进行服务的初始化操作

    // 注册需要监听的事件类型

}

3.3 onAccessibilityEvent函数

这是AccessibilityService的核心函数，用于处理发生的可访问性事件。在这个函数中，可以检查事件类型、获取事件源信息以及采取相应的操作。
本次功能主要用到的就是这个函数

@Override 

public void onAccessibilityEvent(AccessibilityEvent event) {

    // 处理可访问性事件 

    // 获取事件类型、源信息，执行相应操作 

}

3.4 onInterrupt函数

这个函数在服务被中断时会被调用，例如，用户关闭了无障碍服务或系统资源不足。可以在这里进行一些清理工作或记录日志以跟踪服务的中断情况。

@Override

public void onInterrupt() {

    // 服务中断时执行清理或记录日志操作

}

3.5 onUnbind函数

当服务被解绑时，这个函数会被调用。可以在这里进行资源的释放和清理工作。

@Override

public boolean onUnbind(Intent intent) {

    // 解绑时执行资源释放和清理操作

    return super.onUnbind(intent);

}

3.6 onKeyEvent函数（未用到）

这个函数用于处理键盘事件。通过监听键盘事件，可以实现自定义的按键处理逻辑。例如，可以捕获特定按键的按下和释放事件，并执行相应操作。

@Override

public boolean onKeyEvent(KeyEvent event) {

    // 处理键盘事件，执行自定义逻辑

    return super.onKeyEvent(event);

}

3.7 onGesture函数（未用到）

onGesture()函数允许处理手势事件。这些事件可以包括触摸屏幕上的手势，例如滑动、缩放、旋转等。通过监听手势事件，可以实现各种手势相关的应用功能。

@Override

public boolean onGesture(int gestureId) {

    // 处理手势事件，执行自定义逻辑

    return super.onGesture(gestureId);

}

4.功能实现

4.1无障碍服务的启用和注册

• 创建AccessibilityService的类。

public class AdSkipService extends AccessibilityService {

    @Override

    public void onAccessibilityEvent(AccessibilityEvent event) {



    }



    @Override

    public void onInterrupt() {



    }



    @Override

    public boolean onUnbind(Intent intent) {

        return super.onUnbind(intent);

    }

}

• 在AndroidManifest.xml文件中声明AccessibilityService。

<service android:name=".service.AdSkipService"

    android:permission="android.permission.BIND_ACCESSIBILITY_SERVICE"

    android:enabled="true"

    android:exported="true">

    <intent-filter>

        <action android:name="android.accessibilityservice.AccessibilityService" />

    </intent-filter>

    <meta-data

        android:name="android.accessibilityservice"

        android:resource="@xml/accessibility_service_config" />

</service>

4.2 onAccessibilityEvent函数的实现

• 在onAccessibilityEvent函数中获取当前界面的控件，并在异步遍历所有子控件

@Override

public void onAccessibilityEvent(AccessibilityEvent event) {

    // 获取当前界面的控件

    AccessibilityNodeInfo nodeInfo = event.getSource();

    

    taskExecutorService.execute(new Runnable() {

        @Override

        public void run() {

            //遍历节点函数，查找所有控件

            iterateNodesToSkipAd(nodeInfo);

        }

    });

}

• 判断控件的文本是否带有“跳过”二字

/**

 * 判断节点内容是否是关键字(默认为”跳过“二字 )

 * @param node 节点

 * @param keyWords 关键字

 * @return 是否包含

 * */

public static boolean isKeywords(AccessibilityNodeInfo node, String keyWords){

    CharSequence text = node.getText();

    if (TextUtils.isEmpty(text)) {

        return false;

    }

    //查询是否包含"跳过"二字

    return text.toString().contains(keyWords);

}

• 触发控件的点击事件

/**

 * 点击跳过按钮

 * @param node 节点

 * @return 是否点击成功

 * */

private boolean clickSkipNode(AccessibilityNodeInfo node){

    //尝试点击

    boolean clicked = node.performAction(AccessibilityNodeInfo.ACTION_CLICK);

    //打印点击按钮的结果

    LogUtil.e("clicked result = " + clicked);

    return clicked;

}

注：本篇章为了读者方便理解，对代码进行了简化，删去了繁琐的逻辑判断。具体实现详见源码

5.结语

我们通过AccessibilityService和无障碍模式，提供了一种改善用户体验的方法，帮助用户摆脱令人不快的广告干扰。通过了解如何开发这样的应用，我们可以更好地理解无障碍技术的潜力，并在保护用户权益的前提下改善应用环境。

如果对你有所帮助，请记得帮我点一个赞和star，有什么意见和建议可以在评论区给我留言

源码地址：github.com/Giftedcat/A…

一、前言

鸿蒙元服务虽然与h5在很多地方虽然有相似之处，但还是有部分不同的地方，鸿蒙服务开发模式更接近与vue2版本，很多写法与其相似。该篇文章主要用于帮助有h5基础的伙伴能够快速上手鸿蒙元服务，并且对个人在开发过程中遇到的一些坑做个总结。

二、开发相关

项目目录

前端部分主要看js目录下的文件目录即可，除default目录外，其他文件都是与服务卡片相关的。

commom：存放公共配置文件方法等

components：存放公共组件
i18n：i18n相关

media：存放静态文件，图片等

pages：存放页面的目录，包括js，hml，css

utils：存放工具方法，比如网络请求封装等

app.js：全局文件，能够在这个文件中定义全局变量，拥有应用级的生命周期函数

其他关键目录：

supervisual：低代码相关

config.json：项目配置相关，包括路由等

config.json文件

用于给整个项目进行一些关键配置

定义路由

这种定义路由的方式，可能开发过微信小程序的伙伴会比较熟悉，在微信小程序中，一般第一个路径即是项目打开的页面，可惜在鸿蒙元服务中没有这个便捷的功能，designWidth用于定义页面以多宽的设计图来绘制，autoDesginWidth设为true，即是系统根据手机自动设置。

config.json详细配置请看官方文档: developer.harmonyos.com/cn/docs/doc…

HML

HML是一套类HTML的标记语言，通过组件，事件构建出页面的内容。页面具备数据绑定、事件绑定、列表渲染、条件渲染和逻辑控制等高级能力，由鸿蒙内部实现。

<!-- xxx.hml -->

<div class="container">

    <text class="title">{{count}}</text>

    <div class="box">

        <input type="button" class="btn" value="increase" onclick="increase" />

        <input type="button" class="btn" value="decrease" @click="decrease" />

        <!-- 传递额外参数 -->

        <input type="button" class="btn" value="double" @click="multiply(2)" />

        <input type="button" class="btn" value="decuple" @click="multiply(10)" />

        <input type="button" class="btn" value="square" @click="multiply(count)" />

    </div>

</div>

// xxx.js

export default {

  data: {

    count: 0

  },

  increase() {

    this.count++;

  },

  decrease() {

    this.count--;

  },

  multiply(multiplier) {

    this.count = multiplier * this.count;

  }

};

/* xxx.css */

.container {

    display: flex;

    flex-direction: column;

    justify-content: center;

    align-items: center;

    left: 0px;

    top: 0px;

    width: 454px;

    height: 454px;

}

.title {

    font-size: 30px;

    text-align: center;

    width: 200px;

    height: 100px;

}

.box {

    width: 454px;

    height: 200px;

    justify-content: center;

    align-items: center;

    flex-wrap: wrap;

}

.btn {

    width: 200px;

    border-radius: 0;

    margin-top: 10px;

    margin-left: 10px;

}

看这段代码是不是就觉得很亲近了，在hml中通过“{{}}”的形式绑定数据，用@和on的方法来绑定事件，同时支持冒泡、捕获等方式。

列表渲染for

<!-- xxx.hml -->

<div class="array-container" style="flex-direction: column;margin: 200px;">

  <!-- div列表渲染 -->

  <!-- 默认$item代表数组中的元素, $idx代表数组中的元素索引 -->

  <div for="{{array}}" tid="id" onclick="changeText">

    <text>{{$idx}}.{{$item.name}}</text>

  </div>

  <!-- 自定义元素变量名称 -->

  <div for="{{value in array}}" tid="id" onclick="changeText">    

    <text>{{$idx}}.{{value.name}}</text>

  </div>

  <!-- 自定义元素变量、索引名称 -->

  <div for="{{(index, value) in array}}" tid="id" onclick="changeText">    

    <text>{{index}}.{{value.name}}</text>

  </div>

</div>

tid等于vue中的key，id即为array每一项中的唯一属性，需要注意的是，与vue不同，在鸿蒙元服务中，tid是必须的，如果没有tid可能会引起运行异常的情况。

条件渲染if和show

<!-- xxx.hml -->

//if

<div class="container">

  <button class="btn" type="capsule" value="toggleShow" onclick="toggleShow"></button>

  <button class="btn" type="capsule" value="toggleDisplay" onclick="toggleDisplay"></button>

  <text if="{{visible}}"> Hello-world1 </text>

  <text elif="{{display}}"> Hello-world2 </text>

  <text else> Hello-World </text>

</div>



//show

<!-- xxx.hml -->

<div class="container">

  <button class="btn" type="capsule" value="toggle" onclick="toggle"></button>

  <text show="{{visible}}" > Hello World </text>

</div>

if和show相当于vue中的v-if和v-show，原理也一样。

自定义组件使用（props和emit传值）

<!-- template.hml -->

<div class="item"> 

  <text>Name: {{name}}</text>

  <text>Age: {{age}}</text>

  <text class="text-style" onclick="childClicked" id="text" ref="animator">点击这里查看隐藏文本</text>

</div>

<!-- template.js -->

export default {

     props：{

         name,

         age

         contentList

     }

     childClicked () {

     //获取标签对象

        //this.$element("text");

        //this.$element("text").currentOffset().y  获取属性;

        //通过ref的形式来获取

        //this.$refs.animator

        this.$emit('eventType1',{text:'123'});

     },

};

<!-- index.hml -->

//注册

<element name='comp' src='../../common/template.hml'></element>

<div>

//使用

  <comp name="Tony" age="18" content-list="contentList" @event-type1="textClicked"></comp>

</div>

<!-- template.js -->

export default {

     textClicked (e) {

        //e.detail  拿到传过来的数据  e.detail.text

     },

};

注意：组件传递props和emit属性时，强制使用横杆连接的变量名进行传递，接收时，需要使用驼峰名进行接收，通过e.detail拿到emit传过来的参数，通过$element()方法或ref的形式来获取元素对象，其他用法基本和vue2相同。

生命周期和插槽等用法参考官方文档developer.harmonyos.com/cn/docs/doc…

通用事件

developer.harmonyos.com/cn/docs/doc…

内部系统组件

常用的组件包括：

容器组件：dialog、div、滚动组件用于上拉加载(list、list-item、list-item-group)、popup、轮播组件（swiper）

基础组件：image、text、span、input、label

<div>

    <text>123</text>

</div>

注意：

1.div组件内部不能够直接嵌入文字，需要通过text组件进行包裹

2.list组件在相同方向的滚动不能嵌套使用，否则会造成滚动异常

3.image标签有些图片格式不支持，需要转换为可支持的格式

CSS

华为鸿蒙元服务不支持less，sass等预编译语言，只支持css，相对于h5来说，还做了部分阉割，有些属性在h5能用，在鸿蒙元服务确用不了。

元素标签默认样式

需要注意的是，在元服务中，所有的div标签都是一个flex盒子，所以在我们使用div的时候，如果是纵向布局，那我们需要去手动改变flex-direction: column，更改主轴方向。

//hml

<div id="tabBarCon">

    <div id="tab1">

    </div>

    <div id="tab2" onclick="handleJumpToCart">

    </div>

    <div id="tab3" onclick="handleJumpToMine">

    </div>

</div>

//css

.tabBarCon{

    flex-direction:column;

}

元素选择器

只支持部分选择器和部分伪类选择器，像h5中的伪元素选择器都是不支持的，也不支持嵌套使用，由于不存在伪元素选择器，所以遇到有时候一些特殊场景时，我们只能在hml中去判断元素索引来添加动态样式。

属性与h5中的差异

JS

特点：

1.支持ES6

2.用法和vue2相似

// app.js

export default {

  onCreate() {

    console.info('Application onCreate');

  },

  onDestroy() {

    console.info('Application onDestroy');

  },

  globalData: {

    appData: 'appData',

    appVersion: '2.0',

  },

  globalMethod() {

    console.info('This is a global method!');

    this.globalData.appVersion = '3.0';

  }

};

// index.js页面逻辑代码

export default {

  data: {

    appData: 'localData',

    appVersion:'1.0',

  },

  onInit() {

  //获取全局属性

    this.appData = this.$app.$def.globalData.appData;

    this.appVersion = this.$app.$def.globalData.appVersion;

  },

  invokeGlobalMethod() {

    this.$app.$def.globalMethod();

  },

  getAppVersion() {

    this.appVersion = this.$app.$def.globalData.appVersion;

  }

}

data：定义变量

onInit：生命周期函数

getAppVersion：方法，不需要写在methods里面，直接与生命周期函数同级
this.$app.$def：可以拿到全局对象，

导入导出

支持ESmodule

//import

import router from '@ohos.router';

//export

export const xxx=123;

应用级生命周期

页面级生命周期

网络请求

使用@ohos.net.http内置模块即可，下面是对网络请求做了一个简单封装，使用的时候直接导入，调用相应请求方法即可，可惜的鸿蒙元服务目前没法进行抓包，所以网络请求调试的时候只能通过打断点的形式进行调试。

import http from '@ohos.net.http';





import { invokeShowLogin } from '../common/invoke_user';



export default {

    interceptors(response) {

        const result =  JSON.parse(response.result || {});

        const {code,errno} = result

        if (errno === 1024 || code === 1005) {

            return invokeShowLogin();

        }



        return result;

    },



    get(url, data) {

       return http.createHttp().request(

            // 填写http请求的url地址，可以带参数也可以不带参数。URL地址需要开发者自定义。请求的参数可以在extraData中指定

            url,

            {

                method: http.RequestMethod.GET, // 可选，默认为http.RequestMethod.GET

                // 开发者根据自身业务需要添加header字段

                header: {

                    'Content-Type': 'application/json'

                },

                // 当使用POST请求时此字段用于传递内容

                extraData: data,

                connectTimeout: 10*1000,

                readTimeout: 10*1000,

            }

        ).then(res=>{

           return this.interceptors(res);

        });

    },



    post(url, data) {

        return http.createHttp().request(

            // 填写http请求的url地址，可以带参数也可以不带参数。URL地址需要开发者自定义。请求的参数可以在extraData中指定

            url,

            {

                method: http.RequestMethod.POST, // 可选，默认为http.RequestMethod.GET

                // 开发者根据自身业务需要添加header字段

                header: {

                    'Content-Type': ' application/x-www-form-urlencoded'

                },

                // 当使用POST请求时此字段用于传递内容

                extraData: data,

                connectTimeout: 10*1000, // 可选，默认为60s

                readTimeout: 10*1000, // 可选，默认为60s

            }

        ).then(res=>{

            return this.interceptors(res);

        });

    },



    postJson(url, data) {

        return http.createHttp().request(

            // 填写http请求的url地址，可以带参数也可以不带参数。URL地址需要开发者自定义。请求的参数可以在extraData中指定

            url,

            {

                method: http.RequestMethod.POST, // 可选，默认为http.RequestMethod.GET

                // 开发者根据自身业务需要添加header字段

                header: {

                    'Content-Type': 'application/json'

                },

                // 当使用POST请求时此字段用于传递内容

                extraData: data,

                connectTimeout: 10*1000, // 可选，默认为60s

                readTimeout: 10*1000, // 可选，默认为60s

            }

        ).then(res=>{

            return this.interceptors(res);

        })

    }

}

数据存储

只有本地持久化存储这种方式，关闭应用，数据不会丢失。

storage.set({

    key: 'loginInfo',

    value: JSON.stringify({

        uid, skey

    }),

});

storage.get({

    key: 'userInfo',

    value: JSON.stringify(userInfo),

});

路由跳转

<!-- index.hml -->

<div class="container">

  <text class="title">This is the index page.</text>

  <button type="capsule" value="Go to the second page" class="button" onclick="launch"></button>

</div>

// index.js

import router from '@ohos.router';

export default {

  launch() {

    router.push ({

      url: 'pages/detail/detail',

      //携带的参数

      params：{a:123}

    });

    //router.back()

    //router.replace()

  },

}.

// detail.js

import router from '@ohos.router';

export default {

  data:{

      a:''

  }

  onInit(){

  //页面携带过来的参数可以直接使用

      //this.a

  }

}

官方文档链接

1. config.json：developer.harmonyos.com/cn/docs/doc… &developer.harmonyos.com/cn/docs/doc…


2. http请求：developer.harmonyos.com/cn/docs/doc…


3. hml：developer.harmonyos.com/cn/docs/doc…


4. css：developer.harmonyos.com/cn/docs/doc…


5. js:developer.harmonyos.com/cn/docs/doc…


6. 生命周期：developer.harmonyos.com/cn/docs/doc…


7. 目录结构：developer.harmonyos.com/cn/docs/doc…

在软件开发中，研发效率永远是开发人员不断追求的主题之一。于公司而言，在竞争激烈的互联网行业中，产出得快和慢也许就决定着公司的生死存亡；于个人而言，效率高了就可以少加班，多出时间去提升自己、发展爱好、陪伴家人，工作、生活两不误。

提升效率的途径，无外乎就是「方法」和「工具」。以一个开发者的思维来想，就是将工作内容进行总结、归纳，从一组相似的工作内容中提炼共同点，抽象出解决这一类问题的方法，从而造出便于在今后的工作中更为快速解决这类问题的工具。这个「工具」可以是个函数、组件、中间件、插件，也可以是 IDE、其他开发工具的扩展，甚至是语言。

面向组件

在现代前端开发中，如果去问一个业务前端开发：「如何提升团队开发效率？」对方所回答的内容中，极有可能会出现「组件库」。没错，在前端工程化趋近完善的今天，在近几年 React、Vue 等组件化库/框架的影响下，面向组件开发的思维方式早已深入人心。

组件库提效有限

现在，组件库已经是一个前端团队的必备设施了，长远来看，团队一定且必须要有自己的组件库。开源的第三方组件库再好，对于一家企业的前端团队来说也只是短期用来充饥的，因为它们无法完全满足一家公司的业务场景，并且出于多终端支持的考虑，必定要进行二次开发或者自研。

组件库有了，团队和公司中推广的效果也不错，绝大多数的人都在用。使用组件开发页面相对 jQuery 时代要每块功能区都得从 、

<layout>

  <header>

    <title>欧雷流title>

    <navs />

  header>

  <layout>

    <sidebar>

      <navs />

    sidebar>

    <content>...content>

  layout>

  <footer>...footer>

layout>

<view>

  <field name="name" label="姓名" />

  <field name="gender" label="性别" />

  <field name="age" label="年龄" />

  <field name="birthday" label="生日" />

view>

<view>

  <group title="基本信息">

    <field name="name" label="姓名" />

    <field name="gender" label="性别" />

    <field name="age" label="年龄" />

    <field name="birthday" label="生日" />

  group>

  <group title="宠物">

    <field name="dogs" label="🐶" />

    <field name="cats" label="🐱" />

  group>

  <action ref="submit" text="提交" />

  <action ref="reset" text="重置" />

  <action ref="cancel" text="取消" />

view>

{

  name: "field",

  tag: "field",

  attrs: {

    name: "name",

    label: "姓名"

  },

  parent: {},

  children: [],

  remove: function() {},

  insert: function() {}

}

<view widget="form">

  <group title="基本信息" widget="fieldset">

    <field name="name" label="姓名" widget="input" />

    <field name="gender" label="性别" widget="radio" />

    <field name="age" label="年龄" widget="number" />

    <field name="birthday" label="生日" widget="date-picker" />

  group>

  <group title="宠物" widget="fieldset">

    <field name="dogs" label="🐶" widget="select" />

    <field name="cats" label="🐱" widget="select" />

  group>

  <action ref="submit" text="提交" widget="button" />

  <action ref="reset" text="重置" widget="button" />

  <action ref="cancel" text="取消" widget="button" />

view>