• 原文: medium.com/proandroidd…


• 译者：程序员 DHL


• 本文已收录于仓库 Technical-Article-Translation

这篇文章，主要分享在 Android 14 以上新增的权限 READ_MEDIA_VISUAL_USER_SELECTED，该权限允许用户仅授予对选定媒体的访问权限（Photos / Videos)），而不是访问整个媒体库。

新的权限弹窗

当你的 App 运行在 Andrid 14 以上的设备时，如果请求访问照片，会出现以下对话框，你将看到新的选项。

受影响的行为

当我们在项目中声明新的权限 READ_MEDIA_VISUAL_USER_SELECTED ，并且用户选择 Select photos and videos(Select photos or Select videos) ：

• 
  

  READ_MEDIA_IMAGES 和 READ_MEDIA_VIDEO 权限都会被拒绝

  
  


• 
  

  READ_MEDIA_VISUAL_USER_SELECTED 权限被授予时，将会被允许临时访问用户的照片和视频

  
  


• 
  

  如果我们需要访问其他照片和视频，我们需要同时申请 READ_MEDIA_IMAGES 或者 READ_MEDIA_VIDEO 权限

  
  

如何在项目中使用新的权限

• 在 AndroidManifest.xml 文件中添加下面的权限

<uses-permission android:name="android.permission.READ_MEDIA_IMAGES" />



// new permisison

<uses-permission android:name="android.permission.READ_MEDIA_VISUAL_USER_SELECTED" />

• 使用 ActivityResultContract 请求新的权限

val permissionLauncher =

    rememberLauncherForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { mapResults ->

        mapResults.forEach {

            Log.d(TAG, "Permission: ${it.key} Status: ${it.value}")

        }

        // check if any of the requested permissions is granted or not

        if (mapResults.values.any { it }) {

            // query the content resolver

            queryContentResolver(context) { listOfImages ->

                imageDataModelList = listOfImages

            }

        }

    }

为什么要使用 RequestMultiplePermissions，因为我们需要同时请求 READ_MEDIA_IMAGES , READ_MEDIA_VIDEO 权限

• 启动权限申请流程

OutlinedButton(onClick = {

    permissionLauncher.launch(arrayOf(READ_MEDIA_IMAGES, READ_MEDIA_VISUAL_USER_SELECTED))

}) {

    Text("Allow to read all or select images")

}

关于 Android 12 、 Android 13 、Android 14 功能和权限的变更，点击下方链接前往查看：

• 
  

  快速适配 Android 14

  
  


• 
  

  Android 13这些权限废弃，你的应用受影响了吗？

  
  


• 
  

  Android 12 已来，你的 App 崩溃了吗？

  
  

最后我们看一下运行效果

全文到这里就结束了，感谢你的阅读，坚持原创不易，欢迎在看、点赞、分享给身边的小伙伴，我会持续分享原创干货！！！

我开了一个云同步编译工具（SyncKit），主要用于本地写代码，同步到远程设备，在远程设备上进行编译，最后将编译的结果同步到本地，代码已经上传到 Github，欢迎前往仓库 hi-dhl/SyncKit 查看。

• 仓库 SyncKit：https://github.com/hi-dhl/SyncKit


• 下载地址：https://github.com/hi-dhl/SyncKit/releases

Hi 大家好，我是 DHL，就职于美团、快手、小米。公众号：ByteCode ，分享有用、有趣的硬核原创内容，Kotlin、Jetpack、性能优化、系统源码、算法及数据结构、动画、大厂面经，真诚推荐你关注我。

• 公众号：ByteCode


• 哔哩哔哩： space.bilibili.com/498153238


• 掘金： juejin.im/user/259450…


• 博客： hi-dhl.com


• Github： github.com/hi-dhl

最新文章

• 国外大厂面试题， 7 个 Android Lifecycle 重要的知识点


• Android 13这些权限废弃，你的应用受影响了吗？


• Android 12 已来，你的 App 崩溃了吗？


• Android 利器，我开发了云同步编译工具


• Twitter 上有趣的代码


• 谁动了我的内存，揭秘 OOM 崩溃下降 90% 的秘密


• 反射技巧让你的性能提升 N 倍


• 90%人不懂的泛型局限性，泛型擦除，星投影


• 揭秘反射真的很耗时吗，射 10 万次耗时多久


• Google 宣布废弃 LiveData.observe 方法


• 影响性能的 Kotlin 代码（一）


• 揭秘 Kotlin 中的 == 和 ===

开源新项目

• 
  

  云同步编译工具（SyncKit），本地写代码，远程编译，欢迎前去查看 SyncKit

  
  


• 
  

  KtKit 小巧而实用，用 Kotlin 语言编写的工具库，欢迎前去查看 KtKit

  
  


• 
  

  最全、最新的 AndroidX Jetpack 相关组件的实战项目以及相关组件原理分析文章，正在逐渐增加 Jetpack 新成员，仓库持续更新，欢迎前去查看 AndroidX-Jetpack-Practice

  
  


• 
  

  LeetCode / 剑指 offer，包含多种解题思路、时间复杂度、空间复杂度分析，在线阅读

  
  

简介：本文介绍了使用 localStorage 判断设置值是否过期的方法。通过设置过期时间，我们可以使用 setItemWithExpiration 函数将数据存储到 localStorage 中，并使用 getItemWithExpiration 函数获取数据并检查是否过期。localStorage 提供简单的 API 方法来存储、检索和删除数据，并具有持久性和域隔离的特点。通过本文的方法，你可以方便地管理数据，并灵活设置过期时间，实现更多的数据存储和管理功能。

目标：在网站中实现定期弹窗功能，以提示用户。

选择实现方式：为了实现持久化存储和检测功能，我们选择使用localStorage作为首选方案。

解决方案：

1. 存储设置值：使用localStorage将设置值存储在浏览器中，以便在用户访问网站时保持数据的持久性。


2. 设置过期时间：根据需求，为设置值设定一个过期时间，表示多长时间后需要再次弹窗提示用户。


3. 检测过期状态：每次用户访问网站时，检测存储的设置值是否已过期。若过期，则触发弹窗功能，提醒用户。


4. 更新设置值：在弹窗提示后，可以根据用户的操作进行相应的更新操作，例如延长过期时间或更新设置内容。

优势：

1. 持久化存储：使用localStorage可以将设置值保存在浏览器中，即使用户关闭了浏览器或重新启动设备，设置值仍然有效。


2. 简单易用：localStorage提供了简单的API，方便存储和读取数据，实现起来相对简单。


3. 跨浏览器支持：localStorage是HTML5的标准特性，几乎所有现代浏览器都支持它，因此具有良好的跨浏览器兼容性。

注意事项：

1. 需要根据业务需求合理设置过期时间，避免频繁弹窗对用户体验造成困扰。


2. 在使用localStorage时，要考虑浏览器的隐私设置，以确保能够正常存储和读取数据。

说一下locaStorage

localStorage 是 Web 浏览器提供的一种存储数据的机制，它允许在浏览器中存储和检索键值对数据。

以下是关于 localStorage 的一些重要特点和使用方法：

1. 
   

   持久性：与会话存储（session storage）相比，localStorage 是一种持久性的存储机制。存储在 localStorage 中的数据在用户关闭浏览器后仍然保留，下次打开网页时仍然可用。

   
   


2. 
   

   容量限制：每个域名下的 localStorage 存储空间通常为 5MB。这个限制是针对整个域名的，不是针对单个页面或单个 localStorage 对象的。

   
   


3. 
   

   键值对数据存储：localStorage 使用键值对的方式存储数据。每个键和对应的值都是字符串类型。如果要存储其他数据类型（如对象或数组），需要进行序列化和反序列化操作。

   
   


4. 
   

   API 方法：

   
   

   属性	方法
   localStorage.setItem(key, value)	将键值对存储到 localStorage 中。如果键已存在，则更新对应的值。
   localStorage.getItem(key)	根据键获取存储在 localStorage 中的值
   localStorage.removeItem(key)	根据键从 localStorage 中删除对应的键值对
   localStorage.clear()	清除所有存储在 localStorage 中的键值对。
   localStorage.key(index)	根据索引获取对应位置的键名。

   
   


5. 
   

   域限制：localStorage 存储的数据与特定的域名相关。不同的域名之间的 localStorage 是相互隔离的，一个网站无法访问另一个网站的 localStorage 数据。

   
   


6. 
   

   安全性：localStorage 中的数据存储在用户的本地浏览器中，因此可以被用户修改或删除。敏感数据应该避免存储在 localStorage 中，并使用其他更安全的机制来处理。

   
   

以下是一个示例，展示如何使用 localStorage 存储和检索数据：

// 存储数据到 localStorage

localStorage.setItem('name', 'localStorage');

localStorage.setItem('size', '5mb');



// 从 localStorage 中获取数据

const name = localStorage.getItem('name');

const age = localStorage.getItem('size');



console.log(name); // 输出: localStorage

console.log(size); // 输出: 5mb



// 从 localStorage 中删除数据

localStorage.removeItem('size');



// 清除所有的 localStorage 数据

localStorage.clear();

总结来说，localStorage 是一种用于在 Web 浏览器中持久存储键值对数据的机制。它提供简单的 API 方法来存储、检索和删除数据，并具有一定的容量限制和域隔离。

判断本地存储时间的实现

存储时间与值

使用以下代码将值与过期时间存储到localStorage中：

const expiration = 24 * 60 * 60 * 1000 * 7; // 设置过期时间为七天

// const expiration = 2 * 60 * 1000; // 设置过期时间为2分钟

setItemWithExpiration("read_rule", true, expiration);

下面是相应的函数实现：

// 存储数据到LocalStorage，并设置过期时间（单位：毫秒）

function setItemWithExpiration(key, value, expiration) {

    const item = {

        value: value,

        expiration: Date.now() + expiration

    };

    localStorage.setItem(key, JSON.stringify(item));

}

获取值并判断是否过期

使用以下代码从localStorage中获取值，并判断其是否过期：

const retrievedData = getItemWithExpiration("read_rule");

下面是相应的函数实现：

// 从LocalStorage中获取数据，并检查是否过期

function getItemWithExpiration(key) {

    const item = JSON.parse(localStorage.getItem(key));

    if (item && Date.now() < item.expiration) {

        return item.value;

    }

    // 如果数据已过期或不存在，则返回 null 或其他默认值

    return null;

}

通过以上实现，可以方便地存储带有过期时间的值，并根据需要获取和判断其有效性。如果存储的数据已过期或不存在，函数getItemWithExpiration将返回null或

前言

每位开发人员在自己的职业生涯、学习经历中，都会出一些坏习惯，本文将列举开发人员常犯的坏习惯。希望大家能够意识和改变这些坏习惯。

不遵循项目规范

每个公司都会定义一套代码规范、代码格式规范、提交规范等，但是有些开发人员就是不遵循相关的 规范，命名不规范、魔鬼数字、提交代码覆盖他人代码等问题经常发生，如果大家能够遵循相关规范，这些问题都可以避免。

用复杂SQL语句来解决问题

程序员在开发功能时，总想着是否能用一条SQL语句来完成这个功能，于是实现的SQL语句写的非常复杂，包含各种子查询嵌套，函数转换等。这样的SQL语句一旦出现了性能问题，很难进行相关优化。

缺少全局把控思维，只关注某一块业务

新增新功能只关注某一小块业务，不考虑系统整体的扩展性，其他模块已经有相关的实现了，却又重复实现，导致重复代码严重。修改功能不考虑对其他模块的影响。

函数复杂冗长,逻辑混乱

一个函数几百行，复杂函数不做拆分，导致代码变得越来月臃肿，最后谁也不敢动。函数还是要遵循设计模式的单一职责，一个函数只做一件事情。如果函数逻辑确实复杂，需要进行拆分，保证逻辑清晰。

缺乏主动思考，拿来主义

实现相关功能，先网上百度一下，拷贝相关的代码，能够运行成功认为万事大吉。到了生产却出现了各种各样的问题，因为网上的demo程序和实际项目的在场景使用上有区别，尤其是相关的参数配置，一定要弄清楚具体的含义，不同场景下，设置参数的值不同。

核心业务逻辑,缺少相关日志和注释

很多核心的业务逻辑实现，整个方法几乎没看到相关注释和日志打印，除了自己能看懂代码逻辑，其他人根本看不懂。一旦生产出了问题，找不到有效的日志输出，问题根本无法定位。

修改代码，缺少必要测试

很多人都会存在侥幸心里，认为只是改了一个变量或者只修改一行代码，不用自测了应该没有问题，殊不知就是因为改一行代码导致了严重的bug。所以修改代码一定要进行自测。

需求没理清，直接写代码

很多程序员在接到需求后，不怎么思考就开始写代码，写着写着发现自己的理解与实际的需求有偏差，造成无意义返工。所以需要多花些时间梳理需求，整理相关思路，能规避很多不合理的问题。

讨论问题，表达没有逻辑、没有重点

讨论问题不交代背景，上来就说自己的方案，别人听得云里雾里，让你从头描述你又讲不明。需要学会沟通和表达，才能进行有效的沟通和合作。

不能从错误中吸取教训

作为一位开发人员，你会犯很多错误，这不可避免也没什么大不了的。但如果你总是犯同样的错误，不能从中吸取教训，那态度就出现问题了。

总结

关于这些坏习惯，你是否中招了，大家应该尽早规避这些坏习惯，成为一名优秀的程序员。

你是否遇到过这样的情况：想要修改子元素的样式却发现使用父元素选择器无法生效。这时，你就需要了解一下CSS样式穿透的概念。

简单介绍

一般来说，我们可以通过父级选择器来选中它下面的子元素。例如：

.parent .child {

  color: red;

}

但是，有些时候我们需要给子元素中特定的元素修改样式，而不是所有的子元素都修改。这时，我们就需要了解CSS样式穿透这个概念。

CSS样式穿透

在CSS中，我们可以使用“/deep/”、“::v-deep”、“::shadow”等方式实现CSS样式的穿透。

使用/deep/

通过使用/deep/关键字，可以达到子组件穿透自身样式的目的。例如：

.parent /deep/ .child {

  color: red;

}

这种方式相比于上述普通方法，能够选中更深层次的子元素（即使用多个空格连接的子元素）。但是，由于浏览器对“/deep/”选择器支持并不友好，因此尽量避免使用。

使用::v-deep

在Vue框架中，如果需要穿透组件样式，可以使用::v-deep或者>>>选择器。例如：

.parent ::v-deep .child {

  color: red;

}

这种方式只对Vue组件可用，且与/deep/的作用类似。

使用::shadow

在Web Components规范中，定义了Shadow DOM的概念，它能够使得元素的样式隔离开来，不会影响到其它元素。如果我们需要在Shadow DOM中修改样式，可以使用::shadow伪类。

parent::shadow .child {

  color: red;

}

这种方式相比较于上述两种方法，更加安全和规范，但需要先了解Shadow DOM的概念。

补充说明

尽管CSS样式穿透能够方便地修改子元素样式，但是在实际开发中还是应当尽可能地避免使用它们。

CSS一直致力于封装样式，降低代码耦合度，而使用CSS样式穿透会将样式的层级深度加深，增加样式的维护成本。

此外，在跨浏览器、跨框架的情况下，CSS样式穿透的表现都不尽相同，因此建议在项目中谨慎使用。

结语

CSS样式穿透虽然能够带来方便，却也需要谨慎使用，遵循代码封装的原则，保持样式的简洁、规范和易维护。

笔者是一个六年前端，没有大厂经历，也没有什么出彩的项目，所以今年以来，前端现在这种行情下并没有收到多少面试，但是为数不多的面试中，百分之九十都问到了性能优化的问题，而且问题都出奇的一致：

平时的工作中你有做过什么性能优化？

对于这个问题其实我的内心os是（各位轻喷~）：

你们怎么都这么爱问性能优化的问题？我的简历中也没有写到这个啊。

你们的业务都这么复杂吗？怎么动不动就要性能优化？

你们的代码写的这么拉吗？不优化都不能使用吗？

性能优化是一个高级前端的必要技能吗？

首先客观现实是笔者平时工作中的业务并不复杂，需要性能优化的地方确实不多，一些存在性能瓶颈的大多是使用了其他团队开发的东西，比如播放直播视频的SDK、3D地图引擎等，也找过他们进行优化，但是没用，他们也优化不动。

所以每次被问到这个问题我就很尴尬，说工作中没有遇到过性能问题，估计面试官也不信，直接说没有做过性能优化，那又显得我这个六年经验的前端太水了，连这个都不做，所以每次我只能硬说。

没吃过猪肉，还没见过猪跑吗？其实性能优化的文章我也看过很多，各种名词我还是知道一点的，比如：

• 性能问题排查：

1.数据埋点上报

2.使用控制台的NetWork、Performance等工具

3.webpack-bundle-analyzer插件分析打包产物

• http相关：

1.gzip压缩

2.强缓存、协商缓存

• 图片相关：

1.图片压缩

2.图片懒加载

3.雪碧图、使用字体图标、svg

• webpack相关：

1.优化文件搜索

2.多进程打包

3.分包

4.代码压缩

5.使用CDN

• 框架相关：

1.vue性能优化、react性能优化

2.异步组件

3.tree shaking

4.服务端渲染

• 代码实现

1.按需加载，逻辑后移，优先保证首屏内容渲染

2.复杂计算使用web worker

3.接口缓存、计算结果缓存

4.预加载

5.骨架屏

6.虚拟滚动

等等。

但这些绝大部分我并没有实践过，所以我都说不出口，说我没有机会实践也行，说我没有好奇心不好学不爱思考不主动发现问题也行，总之结果就是没有经验。

所以通常我硬着头皮只能说出以下这些：

1.开发前会花点时间梳理业务，全局视角过一遍交互和视觉，思考组件划分，找出项目中相似的部分，提取为公共组件和通用逻辑。

2.代码开发中尽量保证写出的代码清晰、可维护，比如：清晰的目录和文件结构、添加必要的注释、提取公共函数公共组件、组件单向数据流、组件功能尽量单一等。

3.时刻关注可能会存在性能问题的部分，比如：

路由组件异步加载

动态加载一些初始不需要用到的资源

频繁切换的组件使用KeepAlive进行缓存

缓存复杂或常用的计算结果

对实时性不高的接口进行缓存

同一个接口多次请求时取消上一次没有完成的请求

页面中存在很多接口时进行优先级排序，优先请求页面重要信息的接口，并关注同一时刻请求的接口数量，如果过多进行分批请求

对于一些确实比较慢的接口使用loading或骨架屏

懒加载列表，懒加载图片，对移出可视区的图片和dom进行销毁

关注页面中使用到的图片大小，推动后端进行图片压缩

地图撒点时使用聚合减少地图引擎渲染压力

对于一些频繁的操作使用防抖或节流

使用三方库或组件库尽量采用按需加载，减少打包体积

组件卸载时取消事件的监听、取消组件中的定时器、销毁一些三方库的实例

我工作中的实践也就以上这些，其实就是写代码的基本要求，另外我觉得如果业务复杂，以上这些也并不能阻止性能问题的出现，更多的还是当出现了问题，去思考如何解决。

比如我开源的一个思维导图项目mind-map，当节点数量多了会非常卡，调试分析思考后发现原因是做法不合理，每次画布上有操作后都是清空画布上的所有元素，然后重新创建所有元素，数据驱动视图，原理非常简单，但是因为是通过svg实现，所以就是DOM节点，这玩意我们都知道，当节点数量非常多以后，删除节点和创建节点都是非常耗时的，所以数据驱动视图的框架，比如Vue会通过虚拟DOM的diff算法对比来找出最小的更新部分，但是我没有做。。。所以。。。那么我就自然的做了一些优化，比如：

思维导图场景，大部分情况下操作的其实就是其中一个或部分节点，所以不需要重新删除创建所有元素，那么就可以通过节点复用的方式来优化，将真实节点缓存起来，渲染时通过数据唯一的id来检查是否存在可复用节点，如果没有，那么代表是新增节点，那么创建新节点即可；如果有，那么就判断节点数据是否发生改变，没有改变直接复用，如果发生了改变那么判断是否可以进行更新，如果更新成本高那么直接重新创建；另外也需要和上一次的缓存进行对比，找出本次渲染不需要的节点进行删除；当然，为了避免缓存节点数量无限膨胀，也通过LRU缓存算法来管理

对于不影响其他节点的操作只更新被操作的节点

通过setTimeout异步渲染节点，留一些中间时间来响应页面其他操作

将触发渲染的任务放到队列中，在下一帧进行处理，合并掉一些中间状态

对于鼠标移动和滚动的场景，通过节流来优化

进行一些取舍，早期节点激活时可以修改节点的所有样式，导致激活操作需要重新计算节点大小，更新节点样式，在多选和全选操作下非常耗时，所以后期改为只允许修改不改变节点大小的样式属性

其他一些细节优化：对于数据没有改变的操作不触发赋值或函数调用，一些不起眼的操作可能也是需要耗费时间的；改变了不涉及节点大小的属性不触发节点大小重新计算等

经过以上这些修改后，性能确实有了很大程度的提升，不过有些项目可以通过不断的优化来提升性能，但是有些可能就是设计缺陷，比如我开源的另一个白板项目，更好的方式其实是重做它。

写到这里其实并没有解决本文标题提出的问题：

为什么面试官这么爱问性能优化？

因为我没有怎么做过面试官，甚至面试经验其实都不太多，写这篇文章目的主要有两个：

1.想听听有面试官经验的各位的想法或建议

2.想看看和我有类似情况的面试者面对这个问题，或者说类似的问题是如何回答的

最后再牢骚几句：

有时会感慨时间过的真快，一转眼，作为一个前端已经工作了六年，即将三十而立却立不起来，这么多年的工作，更多的只是收获了六年的经历，但是并没有六年的能力，回过头看，当初的有些选择确实是错误的，也许这就是人生把。

作为一个普通的前端，在如今的行情下面试确实很艰难，尤其是我这种不擅长面试的人，不过话说回来，改变哪有不痛苦的，除了面对也没有其他办法。

背景

常和我们的客户端厮混，也经常陪他们发版，每次发版编译打包都可以在那边玩一局游戏了。一边幸灾乐祸，一边庆幸h5编译还好挺快的，直到我们的项目也发展成了*山，巨石项目。由于线上要给用户查看历史的推广活动，所以很多老的业务项目都还是留在项目中，导致我们的router层爆炸，打包速度直线下降，开发过程中，开了hmr稍微有点改动也要等个几秒钟，恨不得立刻重启一个新项目。但是现实告诉你，忍住，别吐，后面还有更多的业务活动加进来。那么怎么解决这个问题呢，这个时候mp的思路是个不错的选择。

关键点

打包慢，本质原因是依赖庞大，组件过多。开发过程中，我们开新的业务组件时，往往和其他业务组件是隔离的，那么我们打包的时候是不是可以把那些不相干的业务组件隔离出去，当然可以。打包工具，从入口开始进行扫描，单页面的模块引入基本都是借助router，所以，关键的是如果我们能够控制router的数量，其实就能够控制编译和打包规模了。

问题

router在vue项目中我们常用的是全家桶的库vue-router，vue-router最多提供了懒加载，动态引入功能并不支持。有小伙伴说router的引入路径可不可以动态传入，我只能说小伙子你很机智，但是vue-router并不支持动态的引入路径。因此我们换个思路，就是在入口的位置控制router的规模，通过不同规模的router实例来实现router的动态引入。当然这需要我们对router库进行一定改造，使其变的灵活易用

一般的router

通常的router如下：

// router.js



/*global require*/



const Vue = require('vue')



const Router = require('vue-router')



Vue.use(Router)



const routes = [



{



path: '/routermap',



component: (resolve) => require(['../containers/map.vue'], resolve),



name: 'routermap',



desc: '路由列表'



},



{



path: '/',



component: (resolve) => require(['../containers/index.vue'], resolve)



},



{



path: '*',



component: (resolve) => require(['../containers/nofound.vue'], resolve),



name: 'defaultPage',



desc: '默认页'



}



]



const router = new Router({



mode: 'history',



routes



})



router.afterEach((to, from) => {



///



})



export default router



// 引入 entry.js



import router from './router.js'



router.beforeEach((to, from, next) => {



///



next()



})



router.afterEach(function(to, from) {



///



})



new Vue({



el: '#app',



template: '<App/>',



router,



})

我们可以不断的往routes数组中添加新的router item来添加新的业务组件，这也是我们的项目不断变大的根本，这样既不好维护，也会导致后面的编译效率

易于维护和管理的router

其实好的管理和维护本质就是分门别类，把类似功能的放在一起，而不是一锅粥都放在一起，这样基本就能解决追踪维护的功能，对应router管理其实也不是很复杂，多建几个文件夹就行如下：

对应routes/index.js代码如下：

import testRouter from './test.js'



const routes = [



    {



        path: '/map',



        component: (resolve) => require(['../containers/map.vue'], resolve),



        name: 'map',



        desc: '路由列表'



    },



    {



        path: '/',



        component: (resolve) => require(['../containers/index.vue'], resolve)



    },



    ...testRouter,



    // 可以扩展其他router



    {



        path: '*',



        component: (resolve) => require(['../containers/nofound.vue'], resolve),



        name: 'defaultPage',



        desc: '默认页'



    }



]



// test.js



/**



* 测试相关页面路由映射



*/



/*global require*/



export default [



    {



        path: '/test/tools',



        name: 'testTools',



        component: resolve => require(['@test/tools/index.vue'], resolve),



        desc: '测试工具'



    }



]

我们通过把router分为几个类别的js，然后在通过router item的数组展开合并，就做到了分门别类，虽然看似简单，但是可以把管理和维护效果提升几个数量级。

支持mp的router

虽然上面支持了易于管理和维护，但是实际上我们如果只是单一入口的话，导出的还是一个巨大的router。那么如何支持多入口呢，其实也不用想的过于复杂，我们让类似test.js的router文件既支持router item的数组导出，也支持类似routes/index.js一样的router实例导出即可。所谓既能分也能合才是最灵活的，这里我们可以利用工厂模式做一个factory.js，如下：

/**



* app 内的页面路由映射



*/



/*global require*/



const Vue = require('vue')



const Router = require('vue-router')



Vue.use(Router)



const RouterFactory = (routes) => {



    return new Router({



        mode: 'history',



        routes: [



            {



                path: '/map',



                component: (resolve) => require(['../containers/map.vue'], resolve),



                name: 'map',



                desc: '路由列表'



            },



            {



                path: '/',



                component: (resolve) => require(['../containers/index.vue'], resolve)



            },



            ...routes,



            {



                path: '*',



                component: (resolve) => require(['../containers/nofound.vue'], resolve),



                name: 'defaultPage',



                desc: '默认页'



            }



        ]



    })



}



export default RouterFactory

这个factory.js产出的router实例和routes/index.js一模一样所以我们只需组装一下test.js即可，如下：

/*global require*/



import RouterFactory from './factory'



export const testRouter = [



    {



        path: '/test/tools',



        name: 'testTools',



        component: resolve => require(['@test/tools/index.vue'], resolve),



        desc: '测试工具'



    }



]



export default RouterFactory(developRouter)



// routes/index.js的引入变化一下即可



import testRouter from './test.js'



// 修改为=》



import { testRouter } from './test.js'

那么我们的入口该如何修改呢？也很简单：

// testEntry.js



import router from './routes/test.js'



router.beforeEach((to, from, next) => {



    ///



    next()



})



router.afterEach(function(to, from) {



    ///



})



new Vue({



    el: '#app',



    template: '<App/>',



    router,



})

我们建立了一个新的入口文件 testEntry.js 这个入口只引入了test相关的模块组件

如何灵活的和编译命令做配合呢

根据上面，我们进行mp改造的基础已经做好，关于如何多入口编译webpack或者其他打包里面都是基础知识，这里就不多赘述。这里主要聊一下如何灵活的配合命令做编译和部署。

既然router我们都可以分为不同的文件，编译文件我们同样可以拆分为不同的文件，这也使得我们的命令可以灵活多变，这里我们以webpack做为示例：

根据上图示例 我们的webpack的配置文件仅仅改动了entry，我们稍微改造一下build.js，使其能够接受不同的编译命令：

// build.js



let page = 'all'



if (process.argv[2]) {



    page = process.argv[2]



}



let configMap = {



    'all': require('./webpack.prod.conf'),



    'app': require('./webpack.app.conf')



}



let webpackConfig = configMap[page]



// dev-server.js



let page = 'all'



if (process.argv[2]) {



    page = process.argv[2]



}



let configMap = {



    'all': require('./webpack.dev.conf'),



    'app': require('./webpack.app.dev.conf')



}



let webpackConfig = configMap[page]

对应的脚本配置：

// package.json



"scripts": {



    "dev": "node build/dev-server.js",



    "build": "node build/build.js",



    "build:app": "node build/build.js app",



    "dev:app": "node build/dev-server.js app"



},

以上app对应test。最后，我们只需要在命令行执行相应命令，即可实现我们可控的router规模的开发，基本随便来新的需求，咱都可以夜夜做新郎，怎么搞都是飞速。当然部署的话我们也可以单独执行一部分页面的部署命令到单独的域名，换个思路也可以作为一种预发测试的部署方法。

# 整体项目的开发编译



npm run dev



# 单独的app，也即test项目的开发编译



npm run dev:app



# 整体项目的部署



npm run build



# 单独的app，也即test项目的部署



npm run build:app

结语

以上，即如何利用mp思路，提高我们的编译开发效率。时常有人会在提高网页性能的时候说到mp，但mp本质上并不能提高页面的性能，比如白屏优化。而路由中使用懒加载其实才是提高部分网页性能的出力者，关于白屏优化，本篇文章不作展开讨论。

这几天在医院对身体各方面进行了一次比较全面的检查，结果比较令人满意。一转眼，接受肾移植已经 5 周年了，写一篇博文，对这些年的身体以及治疗情况进行了一个汇总。

发病

在 30 岁左右进行体检时，已经发现肾功能指标不太理想，因此进行了有针对性的调整。但随着时间的推移和工作的繁忙，逐渐也放松了对健康的重视。尽管发病前几个月进行体检时，各方面的指标也还说得过去。但病来如山倒，对于肾脏疾病来说，后期恶化的速度是十分迅猛的。

当时手里有几个项目正在进行，资金的压力也比较大。尽管身体已经发出了明显的信号，但总想着再坚持一下，即使家人一再催促，我也始终没有进行必要的检查。直到几乎完全无法进食（吃任何东西都马上会吐）才不得已去了医院，确诊十分迅速，因为已经没有了讨论的必要。此时，肌酐在 2100+，血红蛋白 46，按照医生的话来说，能活着走到医院已经属于大惊喜了。

由于贫血严重，输了几次血，但血红蛋白并没有得到太大的改善。为了尽快进行较彻底的透析，在与医生商量后，尽管血红蛋白不足 60，还是强行进行了植入透析管的手术，开启了我的透析生涯。

透析

透析有两种形式：一种是血液透析（大多数人知道的透析方式），另一种是腹膜透析。血液透析通常在指定的血液透析中心（或医院）进行，每周三次，每次四个小时。腹膜透析则可以在家中进行，每天透析次数根据患者的身体情况而有所变化，通常为 2 到 5 次，每次透析液置换时间约为 20 分钟。

我选择了腹膜透析。相较于血液透析，腹膜透析的场地和时间更自由。另外，腹膜透析通常对残肾功能保护比较好，有利于日后的移植。腹膜透析也有两种方式，一种是手动，就是每天手工进行几次透析液的置换操作。另一种则是自动透析（APD），通常是每天临睡前将腹部的透析管连接到设备上。在患者睡眠的过程中，设备会进行多次的液体交换。早上醒来的时候便将腹透管与设备断开，白天与正常人一样可以自由行动。有这么多的优势，我自然会选择自动透析的方式。

理想很丰满，现实很残酷。透析后发现我的腹膜滲透能力不是太好。仅依赖夜间的透析机进行透析完全无法满足排出毒素和水分的需要。因此，在此基础上逐渐增加了白天的手动透析操作。到移植前，我白天需要进行 5 次手工操作，夜间进行 12 个小时的机器自动透析。已然创下了我所在地区的透析记录。

经过几个月的透析治疗，随着身体状况的逐步改善，家人便联系了移植医院，催促我进行移植手术。但是，处于某种考虑，当时我并没有太基于进行移植。在外人看来，透析是一种无趣、繁琐、束缚人的治疗方式，但对我来说，它是一种身心调理。在这几年的透析治疗中，我的心态发生了巨大的转变，变得更加平和从容。此外，透析还让我的生活变得十分有规律，为我日后的健康生活打下了基础。

移植

最终，在进行了四年的透析后，我选择进行肾移植。为了能够更好地应对这次手术，我在准备移植前已经进行了一年有针对性的锻炼。再加上之前有意无意地“错过”了几次移植的机会，在接到医院的电话时，我十分平静。内心很笃定手术会成功。

不过事情似乎没有想的那么顺利。手术当天还是出现了不理想的状况，本来只需要 4 到 6 个小时的手术进行了接近 10 个小时。而且在手术后的第五天，从很多指标上看，手术似乎出现了明显失败的迹象。最重要的是，医生怀疑移植肾出现了破碎的可能，于是又进行了一次手术。在第二次手术前，尽管从各方面的指标上来看问题不小，但我个人感觉异常良好，因此我是抱着十分轻松的心态接受第二次手术。事后从妻子的口中得知，当时医生已经让家人做最坏打算了。第二次手术进行的时间不比第一次少，而且同第一次一样，出现了十分严重的术后反应。经过 ICU 的洗礼，人没有太大的事情。好消息是，第二次手术确认了第一次手术没有太大的问题，移植肾也无大碍。

在突破了该医院移植的最长住院记录后，经过 35 天，我终于回到了家，进入了术后康复阶段。

康复

回到家后马上遇到了几个十分棘手的问题。

第一个是体能太差。这是因为在进行第二次手术后，创口部分又出现了一次比较严重的出血情况。为了加快速度，两个医生在加护病房中对创口进行了紧急处置。经过这次治疗，我被要求只能用一个姿势躺着。经过了 20 多天的卧床，虽然伤口问题不大了，但下肺萎缩严重。刚回到家一个月里，即使在静息的状态下，心率也在 100 以上。为了改善体能，我从手术后 2 个月便开始恢复体能锻炼，并将这个习惯一直保持至今，现在每天也会进行一到两个小时的健身。

第二个症状是神经震颤，这是药物他克莫司所具备的副作用，强度因人而异，而我显然是反应比较大的那个。当时手已经很难拿住筷子了，情况与帕金森症很类似。为了改善这种情况，我尝试每天写毛笔字，不是为了练字，主要是提高自己的控制力。随着药量的减少、身体对药物的逐步适应，在手术一年后，这个症状得到了明显的改善。目前除了做一些很精细的操作外，基本上看不出有什么异常。

第三点是脑子出现了问题。大量的麻醉以及短期内高剂量的激素治疗让我的思维出现了明显的窒塞。在手术后的三到四个月中，我几乎无法通过短信发出一段没有错误的文字，基本上是脑子知道想要什么，但表述总是有问题。好在自己对这种情况有清晰的认识，努力尝试通过阅读、思考、交流、学习来改善这种状况。学习 Swift、SwiftUI、Core Data 也是在这个背景下自己主动采用的一种治疗措施，想了解这段时间的情况，可以阅读 老人新兵 —— 一款 iOS APP 的开发手记一文。

应该说，几年的透析生活给了我相当大的帮助。在移植手术后的这几年，我保持了相当健康的生活方式和乐观的心态。经过数年的调养，身体的指标也越来越好。

这是我每个月经常性检查的一些指标，通过这些指标可以看出，我的肾功指标在移植后逐年好转直至正常。大多数移植患者的指标在移植后很短的时间（几天到几周）都会恢复正常，然后随着时间的推移逐渐再出现问题。而我至少到目前来看，指标还处于上升通道中。希望能够继续保持下去。

只有经过长时间的积累，才能看出数据的价值。使用“健康笔记”App，我不仅对自己的身体指标有了清晰的认识，而且这些数据给我和医生提供了重要的参考指标，让我能有针对性地调整身体。如果你或你的家人、朋友需要长期跟踪健康数据，可以尝试使用该应用程序。请注意，该应用程序最初是为我自己编写的，对新手不够友好，但功能非常实用。

未来

尽管这些年，身体出现了或多或少的问题，不过我还是非常幸运的。遇到了善良的器官捐赠者，有最爱我的家人，总能转危为安的运气、一直碰到不错的医护，以及获得了很多朋友的支持。

明年我就到了知天命的年龄，希望能以平和的心态继续积极、健康地生活下去，做一些自己想做并且对社会有意义的事情。

祝大家身体健康。

前言

大家好，我是 simple ，我的理想是利用科技手段来解决生活中遇到的各种问题。

众所周知，感觉是最不靠谱的东西，这完全取决于主观意识。我们做性能优化一定要取决于一些指标，而Performance API向我们提供了访问和测量浏览器性能相关信息的方式。通过它，我们可以获取有关页面加载时间、资源加载性能、用户交互延迟等详细信息，用于性能分析和优化，而不是完全靠自己的感官意识，感觉更快了或者更慢了。

指标收集

1. Navigation Timing API - 页面加载时间

// 获取页面加载时间相关的性能指标

const navigationTiming = performance.timing;

console.log('页面开始加载时间: ', navigationTiming.navigationStart);

console.log('DOMContentLoaded 事件发生时间: ', navigationTiming.domContentLoadedEventEnd);

console.log('页面加载完成时间: ', navigationTiming.loadEventEnd);

console.log('页面从加载到结束所需时间',navigationTiming.loadEventEnd - navigationTiming.navigationStart)

2. Resource Timing API - 资源加载性能

// 获取资源加载性能数据

const resources = performance.getEntriesByType('resource');

resources.forEach(resource => {

  console.log('资源 URL: ', resource.name);

  console.log('资源开始加载时间: ', resource.startTime);

  console.log('资源加载结束时间: ', resource.responseEnd);

  console.log('资源加载持续时间: ', resource.duration);

});

3. User Timing API - 自定义时间点

// 标记自定义时间点

performance.mark('startOperation');

// 执行需要测量的操作



for(let i = 0;i < 10000;i++) {}



performance.mark('endOperation');

// 测量时间差

performance.measure('operationDuration', 'startOperation', 'endOperation');

const measurement = performance.getEntriesByName('operationDuration')[0];

console.log('操作执行时间: ', measurement.duration);

// 和console.time,console.timeEnd比较相似

4. Long Tasks API - 长任务性能

// 获取长任务性能数据

const longTasks = performance.getEntriesByType('longtask');

longTasks.forEach(task => {

  console.log('任务开始时间: ', task.startTime);

  console.log('任务持续时间: ', task.duration);

});

5. Navigation Observer API - 导航事件监测

// 创建 PerformanceObserver 对象并监听导航事件

const observer = new PerformanceObserver(list => {

  const entries = list.getEntries();

  entries.forEach(entry => {

    console.log('导航类型: ', entry.type);

    // navigate 表示页面的初始导航，即浏览器打开新的网页或重新加载当前网页。

    // reload 表示页面的重新加载，即浏览器刷新当前网页。

    // back_forward 表示通过浏览器的前进或后退按钮导航到页面。

    console.log('导航开始时间: ', entry.startTime);

    console.log('导航持续时间: ', entry.duration);

  });

});

// 监听 navigation 类型的事件

observer.observe({ type: 'navigation', buffered: true });

6. LCP的采集

LCP（Largest Contentful Paint）表示最大内容绘制，指的是页面上最大的可见内容元素（例如图片、视频等）绘制完成的时间点。LCP反映了用户感知到的页面加载速度，因为它代表了用户最关注的内容何时变得可见。LCP 应在页面首次开始加载后的2.5 秒内发生。

new PerformanceObserver((entryList) => {

  for (const entry of entryList.getEntries()) {

    console.log('Largest Contentful Paint:', entry.startTime);

  }

}).observe({type: 'largest-contentful-paint', buffered: true});

浏览器会多次报告 LCP ，而真正的 LCP 是用户交互前最近一次报告的 LCP。

7. FID的收集

FID（First Input Delay）表示首次输入延迟，衡量了用户首次与页面进行交互（例如点击按钮、链接等）时，响应所需的时间。较低的FID值表示页面对用户输入更敏感，用户可以更快地与页面进行交互，页面的 FID 应为100 毫秒或更短。

new PerformanceObserver(function(list, obs) {  

  const firstInput = list.getEntries()[0];  

  const firstInputDelay = firstInput.processingStart - firstInput.startTime;  

  const firstInputDuration = firstInput.duration;  

  console.log('First Input Delay', firstInputDuration);

  obs.disconnect();  

}).observe({type: 'first-input', buffered: true});

8. CLS的收集

CLS（Cumulative Layout Shift）表示累积布局偏移，衡量了页面在加载过程中发生的意外布局变化程度。当页面上的元素在加载过程中发生位置偏移，导致用户正在交互时意外点击链接或按钮，就会产生布局偏移。页面的 CLS 应保持在 0.1  或更少，这里的0.1表示10%。请注意，CLS 的计算可能涉及复杂的算法和权重计算，下列代码示例仅演示了基本的计算过程。

const observer = new PerformanceObserver((entryList) => {

  const entries = entryList.getEntries();

  let clsScore = 0;

  entries.forEach(entry => {

    // 计算每个布局变化的分数

    clsScore += entry.value;

  });

  console.log('CLS 值: ', clsScore);

});



// 监听 Layout Shift 类型的条目

observer.observe({ type: 'layout-shift', buffered: true });

小结

• 测量页面加载时间：性能 API 允许我们测量和分析网页加载所需的时间。通过使用性能计时指标，如 navigationStart、domContentLoadedEventEnd 和 loadEventEnd，我们可以准确测量页面加载过程中各个阶段的持续时间。


• 分析资源加载性能：利用性能 API，我们可以检查网页上正在加载的各个资源（如图像、脚本、样式表）的性能。这包括跟踪资源加载时间、大小和状态码，有助于识别影响整体性能的瓶颈或问题。


• 监测用户交互延迟：性能 API 使我们能够测量用户交互和浏览器响应之间的延迟。通过跟踪类似于 firstInputDelay（FID）和 firstInputTime 的指标，我们可以评估网页对用户操作（如点击或触摸）的响应速度，并确定改进的方向。


• 基准测试和比较分析：性能 API 允许我们对网页的不同版本或不同网页的性能进行基准测试和比较分析。通过收集性能数据和指标，我们可以评估代码更改、优化或第三方资源对页面性能的影响，并做出明智的决策。


• 性能优化和报告：利用性能 API 获得的洞察力，我们可以确定性能瓶颈和改进的方向。然后，可以使用这些信息来实施优化，例如减小文件大小、降低服务器响应时间、优化缓存策略和提高渲染
  
  作者：simple_lau
  来源：juejin.cn/post/7238779568478552122
  效率。

前几天在前端技术群里聊起Code Review的事，大伙儿似乎都憋了一肚子气：

我觉得这份难言之隐应该要让更多人看到，就跟Henry约了个稿：

于是Henry赶在周末，一边带娃，一边给我抹眼泪整理（脱敏）出了这篇小小的屎山合集，供大家品鉴。

以下是正文。

（文字大部分是Henry所写，沐洒进行了一些精简和调整）

1. 直接操作DOM

const a = document.querySelector('.a');



    const scrollListener = throttle(() => {

      const currentY = window.scrollY;



      if (currentY > 100) {

        a.classList.add('show');

      } else {

        a.classList.remove('show');

      }

    }, 300);



    window.addEventListener('scroll', scrollListener);

    return () => {

      window.removeEventListener('scroll', scrollListener);

    };

上面的代码在监听scroll方法的回调函数中，直接上手修改DOM的类名。众所周知，React属于响应式编程，大部份情况都不需要直接操作DOM，具体原因参考官方文档（react.dev/learn/manip…

优化方法也很简单，充分发挥响应式编程的优点，用变量代替即可：

const [refreshStatus, setRefreshStatus] = useState('');



const scrollListener = throttle(() => {

  if (tab.getBoundingClientRect().top < topH) {

    setRefreshStatus('show');

  } else {

    setRefreshStatus('');

  }

}, 300);



return <div className={['page_refresh', refreshStatus].join(' ')}/>;

2. useEffect不指定依赖

依赖参数缺失。

useEffect(() => {

    console.log('no deps=====')

    // code...

});

这样的话，每次页面有重渲染，该useEffect都会执行，带来严重的性能问题。例如我们项目中，这个useEffect内部执行的是第一点中的内容，即每次都会绑定一个scroll事件的回调，而且页面中有实时轮询接口每隔5s刷新一次列表，用户在该页面稍加停留，就会有卡顿问题出现。解决方案很简单，根据useEffect的回调函数内容可知，如果需要在第一次渲染之后挂载一个scroll的回调函数，那么就给useEffect第二个参数传入空数组即可，参考官方文档(react.dev/reference/r…

useEffect(() => {

    // code...

}, []);

3. 硬编码

硬编码，即一些数据信息或配置信息直接写死在逻辑代码中，例如

这两行代码本意是从url上拿到指定的参数的值，如果没有，会用一个固定的配置做兜底。

乍一看代码逻辑很清晰，但再想深一层，兜底值具体的含义是什么？为什么要用这两个值来兜底？写这行代码的同学可能很快可以解答，但是一段时间之后，写代码的人和提需求的人都找不到了呢？

这个示例代码还比较简单，拿对应的值去后台可以找到对应的含义，如果是写死的是枚举值，而且还没有类型定义，那代码就很难维护了。

解决此类问题，要么将这些内容配置化，即写到一个config文件中，使用清晰的语义化命名变量；要么，至少在硬编码的地方写上注释，交代清楚这里需要硬编码的前因后果。

4. 放任文件长度，只着眼于当下的需求

很多同学做需求、写代码都比较少从全局考虑，只关注到当前需求如何完成。从“战术”上来说没有问题，快速完成产品的需求、快速迭代产品也是大家希望看到的。

可一旦只关注“战术实现”而忽略“战略设计”，除非做的产品是月抛型的，否则一定会遇到旧逻辑难以修改的情况。

如果再加上一个文件被多达10余人修改过的情况，那么每改一行代码都会是一场灾难，例如最近接手的一个页面：

单文件高达1600多行！哪怕去除300多行的注释，和300多行的模板，剩下的逻辑代码也有1000行左右，这种代码可读性就极其糟糕，必须进行拆分。

而很常见的是，由于每一任经手人都疏于考虑全局，导致大量代码毫无模块化可言，甚至出现多个useEffect的依赖是完全相同的：

这里明显还有另一个问题：滥用hooks。

从行号可以看出来确实是相同的依赖写了多个useEffect，很明显是多个同学各写各的的需求引入的这些hooks。

这代码跑肯定是能跑的，但是很可能会出现多个hooks中修改同一个变量，导致其他地方在使用的时候需要搞一些很tricky的操作来修Bug。

5.变量无初始值

在typescript的加持下，对变量的类型定义可以说是日益严格了。可是在一些变量的类型定义比较复杂的情况下，可能一个变量的字段很多、层级很复杂，此时有些同学就可能想偷个懒了，例如：

const [variable, setVariable] = useState();



// some code...

const queryData = function() {

    // some logic

    setVariable({ show: true });

};



useEffect(() => {

    queryData();

}, []);



return variable.show ?  : null;

这里的问题很明显，如果queryData耗时比较长，在第一次渲染的时候，最后一行的variable.show就会报错了，因为variable的初始值是undefined。所以声明变量时，一定要根据变量的类型设置好有效默认值。

6. 三元选择符嵌套使用

网上很多人会推荐说用三元选择符代替简单的if-else，但几乎没有见过有人提到嵌套使用三元选择符的事情，如果看到如下代码，不知道各位读者会作何感想？

{condition1 === 1

    ? "数据加载中"

    : condition2

    ? "没有更多了"

    : condition3

    ? "当前没有可用房间"

    : "数据加载中"}

真的很难理解，明明只是一个简单的提示语句的判断，却需要拿出分析性能的精力去理解，多少有点得不偿失了。

这还只是一种比较简单的三元选择符的嵌套，因为当各个条件分支都为true时，就直接返回了，没有做更多的判断，如果再多做一层，都会直接把人的cpu的干爆炸了。 

替代方案： 

1. 直接用if-else，可读性更高，以后如果要加逻辑也很方便。


2. Early Return，也叫卫语句，这种写法能有效简化逻辑，增加可读性。

if (condition1 === 1) return "数据加载中";

if (condition2) return "没有更多了";

if (condition3) return "当前没有可用房间";

return "数据加载中";

虽然不嵌套的三元选择符很简单，但是在例如jsx的模版中，仍然不建议大量使用三元选择符，因为可能会出现如下代码：

return (

    condition1 ? (

        <div className={condition2 ? cls1 : cls2}>

            {condition3 ? "111" : "222"}

            {condition4 ? (

                a : b} />

            ) : null

        

前言

大家好，我是林三心，用最通俗易懂的话讲最难的知识点是我的座右铭，基础是进阶的前提是我的初心。

大早上被叫醒！

前几天周末，大早上的时候，太阳才刚出来，我突然被老大电话叫醒了，并通知我速速进入飞书会议，说是服务器发生了警报，出现了严重事故。

进到会议才发现是我们的后端有一个接口，让监控直接红色了。由于这一块代码我比较熟，所以老大让我紧急定位并处理一下这个严重的问题~

定位问题

所以本全干工程师就开始了后端接口的问题定位~

初步定位

首先说说这个接口的背景，这个接口是提供给用户用作导入用的，用户在做导入的时候，有可能导入的数据超级大，所以会不会是因为导入的数据量太大了，所以导致此接口直接崩掉呢？

但是老大查了日志后跟我说，这个用户在以前也导入过这么大的数据量，但是那时候都没啥问题的啊~

所以我觉得这应该不是用户行为造成的，而是什么新功能造成的这个BUG~于是我看了涉及到此接口的最近的提交，发现确实是有一个新功能在最近上线了，是涉及到 json-schema 的

简单认识 json-schema

什么是 json-schema 呢？给大家举个小例子，让大家简单认识一下吧，比如下方的三个属性

• name


• age


• cars

他们都有对应的数据类型，他们需要通过 json-schema 来寻找到自己对应的类型

// jsonschema

const schema = {

  name: {

    $ref: 1

  },

  age: {

    $ref: 2

  },

  cars: {

    $ref: 3

  }

}



// jsonschema合集

const schemaDefination = {

  1: {

    type: 'string'

  },

  2: {

    type: 'number'

  },

  3: {

    $ref: 4

  },

  4: {

    type: 'array'

  }

}



// 得出结果

const result = build(schema, schemaDefination)

console.log(result)

// {

//   name: 'string',

//   age: 'number',

//   cars: 'array'

// }

继续定位问题

回到这个 BUG 上，我继续定位。其实刚刚上面的例子是很简单的例子，但是其实在这个功能里，数据量和负责度远远没这么简单，我们刚刚看到的 schemaDefination 其实就是所有 jsonschema 的引用的结合

// 实际上可能有几百个

const schema1 = {

  $ref: 1

}

const schema2 = {

  $ref: 2

}

const schema3 = {

  $ref: 3

}



const schemaDefination = gen(schema1, schema2, schema3)

console.log(schemaDefination)

// 实际上可能有几百个

// {

//   1: {

//     type: 'string'

//   },

//   2: {

//     type: 'number'

//   },

//   3: {

//     type: 'array'

//   }

// }

也就是一开始会先根据所有 schema 去生成一个引用的集合 schemaDefination，而这个集合可能有几百个，数据量挺大

最终定位

然后到最终的时候 schema 结合 schemaDefination 去生成结果，我感觉就是在这一步导致了 BUG

// 得出结果

// 可能要 build 几百次

const result1 = build(schema1, schemaDefination)

const result2 = build(schema2, schemaDefination)

const result3 = build(schema3, schemaDefination)

为什么我觉得是这一步出问题呢？我们刚刚说了 schemaDefination 是所有 schema 的引用集合，数据量很大，你每次 build 的时候 schema 传的是一个 schema，但是你 schemaDefination 传的是集合！！！

正常来说应该是传 schema 时只需要传对应的 schemaDefination 即可，比如

// 合理的

const result1 = build({

  $ref: 1

}, {

  1: {

    type: 'string'

  }

})



// 不合理的

const result1 = build({

  $ref: 1

}, {

  1: {

    type: 'string'

  },

  2: {

    type: 'number'

  },

  3: {

    type: 'array'

  }

})

而我们现在就是处于不合理的情况，于是我特地看了 build 这个函数的内部实现，发现有 对象序列化处理 的代码，想一下下面的模拟代码

const obj = { 几百个数据 }

while(i < 300) {

  JSON.stringfy(obj)

  i++

}

这样的代码会给服务器造成非常大的压力，甚至把接口给搞崩！！！

解决问题，性能提升几百倍！

上面其实我已经分析出问题所在了：传 schema 的时候不要传整个 Defination集合！，所以我们只需要传入所需的 defination， 那么性能是不是可以优化几百倍！！！

解决手段

所以我们只需要写一个函数，过滤出所需要的 defination 即可，例如

// 找出所有被 ref 的数据模型

const filter = (

  schema,

  schemaDefinitions,

) => {

  // 进行过滤操作

}



// jsonschema

const schema = {

  name: {

    $ref: 1

  }

}



// jsonschema合集

const schemaDefination = {

  1: {

    type: 'string'

  },

  2: {

    type: 'number'

  },

  3: {

    $ref: 4

  },

  4: {

    type: 'array'

  }

}



// 过滤

const defination = filter(schema, schemaDefination)

console.log(defination)

//{

//  1: {

//    type: 'string'

//  },

//}

所以只需要在 build 的时候传入过滤后的 defination 即可！

const result1 = build(schema1, filter(schema1, schemaDefination))

const result2 = build(schema2, filter(schema2, schemaDefination))

const result3 = build(schema3, filter(schema3, schemaDefination))

测试无误，继续睡觉！

然后拿到一份用户的数据，在测试环境测了一下，没有发生之前那个 BUG 了！合并代码！打包上线！继续睡觉！

结语 & 加学习群 & 摸鱼群

我是林三心

• 一个待过小型toG型外包公司、大型外包公司、小公司、潜力型创业公司、大公司的作死型前端选手；


• 一个偏前端的全干工程师；


• 一个不正经的掘金作者；


• 一个逗比的B站up主；


• 一个不帅的小红书博主；


• 一个喜欢打铁的篮球菜鸟；


• 一个喜欢历史的乏味少年；


• 一个喜欢rap的五音不全弱鸡

如果你想一起学习前端，一起摸鱼，一起研究简历优化，一起研究面试进步，一起交流历史音乐篮球rap，可以来俺的摸鱼学习群哈哈，点这个，有7000多名前端小伙伴在等着一起学习哦 --> 摸鱼沸点

故事是这样的：

我们的商城需要在日本上线去赚小日子过得不错的日本人的钱，所以支付是首要的。就找了一家做日本本地支付的公司做对接，公司名字当然不能说，打我也不说。

第一天，很愉快，签了协议，给了开发文档。俺就准备开始撸代码了。

API文档

这开发文档，打开两秒钟就自动挂掉了，我只能一次又一次的点击Reload。

后来实在受不了了，我趁着那两三秒钟显示的时间，截图对照着看。结果就是所有的字段不能复制粘贴了，只能一个一个敲。

还是这个API文档，必输字段和非必输字段乱的一塌糊涂，哪些是必输纯靠试，有的必输字段调试的时候有问题，对面直接甩过来一句，要么不传了吧。听得我懵懵的。

加密，验签

然后到了加密，验签。竟然能只给了node的demo，咱对接的大部分是后端程序员吧,没事，咱自己写。比较坑的是MD5加密完是大写的字母，这三方公司转小写了，也没有提示，折腾了一会，测了一会也就通了，还好还好。

场景支持

在之后就是支付的一个场景了，日本是没有微信支付宝这样的便捷支付的，要么信用卡，要么便利店支付。

稍微说下便利店支付，就是说，客户下完单之后，会给到一个回执，是一串数字，我们且称之为支付码，他们便利店有一个类似于ATM机的柜员机，去这个机子上凭借这串支付码打印出来一个凭条，然后拿着这个凭条去找便利店的店员，现金支付。

就是这个场景，就是这个数字，三方它就给客户显示一次，就一次，点击支付的时候显示一次。要是客户不截图，那么不好意思，您就重新下单吧。而且这个支付码我们拿不到，这个跳转了他们的页面，也不发个邮件告知。这明显没法用啊，我们的订单过期时间三天，客户这三天啥时候想去便利店支付都行，可是这只显示一次太扯了。

同样的请求再发一次显示的是支付进行中。这怎么玩，好说歹说他们排期开发了两周，把这个订单号重入解决了，就是说同一笔订单再次进入是可以看到那串支付码的。

测试环境不能测

最后，写完了，调通了，测一下支付，结果他们测试环境不支持日本的这个便利店支付测试，what? 测试环境不能测试？那我这么久在干什么，让我们上线上测，我的代码在测试环境还没搞完，让我上生产，最后上了，没测通，对方的问题，当天下午就把代码给回滚了。等着对方调试完继续测。

业务不完整

还有，不支持退款，作为一个支付公司，不支持退款，我们客户退款只能线下转账，闹呢。

以前对接三方的时候，遇到问题地想到的是我们是不是哪里做错了，再看看文档。对接这个公司，就跟他们公司的测试一样，找bug呢。

建议

这里是本文的重点，咱就是给点建议，作为一家提供服务的公司，不管是啥服务。

1. 对外API文档应当可以正常显示，必输非必输定义正确，字段类型标注准确。


2. 若是有验签的步骤，介绍步骤详细并配上各个语言的demo，并强调格式以及大小写。


3. 牵扯到业务的，需要站在客户的角度思考，这个是否合情合理。


4. 业务的完整性，有可能是尚未开发完全，但是得有备选的方案。

界面无滚动条

滚动条的优化也有很多种，比如随便再网上搜索美化浏览器滚动条样式，就会出现些用css去美化滚动条的方案。


那种更好呢？

没有更好只有更合适

• 像默认的滚动条的话，他能让你方便摁着往下滑动（他比较宽）特别省劲，不用担心美化过后变细摁不到问题。


• 美化后的滚动条样式啊更贴合网站主题，让用户体验更好。


• 无滚动条（鼠标放上去后出现）这种更适合像一个页面好多个块，每个块的话还很多内容（都有滚动条）。如果像这种都默认都出现滚动条的话，也太不美观了。

那咱们就从无滚动条展开说说！！！

无滚动条设计

比如像element ui组件内像input的自定义模块数据过多的时候出现的下拉框内的滚动条，如下图：

在element-ui里面它其实是有内部组件el-scrollbar在的。那么它是怎么实现无滚动条呢？

如下图咱们先把:hover勾选上让滚动条一直处于显示得状态。然后咱们再分析他的实现。

当我把样式稍微修改下，咱们再观察下图：

这么看是不是就很明白了 他其实用margin值把整个容器扩大了点然后溢出隐藏，其实滚动条还在就是给界面上看不到了而已。

然后它自己用dom画了个滚动条，如下图：

经过上面分析，咱们已经很清楚得了解到一个无滚动条是从那个方面实现得了。

1. 使用margin值把滚动条给溢出隐藏掉。


2. 使用div自己画了一个滚动条。方便咱们隐藏、显示、更改样式等。

无滚动条实现

那咱们再从细节上拆分下具体实现要考虑那些点：

1. 需要计算滚动条得宽度用来margin扩大得距离（每个界面上得滚动条得宽度是不一样得）。
   


2. 需要计算画的div滚动条得高度（这个内容多少会影响滚动条的高度）。
   


3. 需要根据滚动条去transform: translateY(19.3916%);移动咱们自己画的div滚动条的。
   


4. 需要根据摁着画的div滚动条，去实际更改需要滚动的高度。
   


5. 需要点击滚动轴的柱子支持跳到目标的滚动位置；

一 计算界面原本滚动条的宽度

计算下界面上原本滚动条的宽度如下：

let scrollBarWidth;



export default function() {

  if (scrollBarWidth !== undefined) return scrollBarWidth;



  const outer = document.createElement('div');

  outer.className = 'el-scrollbar__wrap';

  outer.style.visibility = 'hidden';

  outer.style.width = '100px';

  outer.style.position = 'absolute';

  outer.style.top = '-9999px';

  document.body.appendChild(outer);



  const widthNoScroll = outer.offsetWidth;

  outer.style.overflow = 'scroll';



  const inner = document.createElement('div');

  inner.style.width = '100%';

  outer.appendChild(inner);



  const widthWithScroll = inner.offsetWidth;

  outer.parentNode.removeChild(outer);

  scrollBarWidth = widthNoScroll - widthWithScroll;



  return scrollBarWidth;

};

先创建了一个div, 设置成scroll, 然后再在里面嵌套一个没有滚动条的div设置宽度100%, 获取到两者的offsetWidth, 相减获取到scrollBarWidth。赋值给scrollBarWidth 是惰性加载的优化，只需要计算一次就可以了。 具体展现如下图：

二 计算画的滚动条的高度height

计算下画的div滚动条的高度height。是用当前容器的内部高度 / 容器整个滚动条的高度 * 100计算出百分比;

比如：

const warp = this.$refs.wrap; // 或者使用documnet获取容器

const heightPercentage = (wrap.clientHeight * 100 / wrap.scrollHeight); // height

const widthPercentage = (wrap.clientWidth * 100 / wrap.scrollWidth); // width

解析： 如当前容器高30px,内容撑起来总共高100px,那么滚动条的高度就是当前容器的30%;

三 计算滚动条需要移动的值

计算画的div需要滚动条的高度moveY是， 获取当前容器滚动的scrollTop / 当前容器内部高度 * 100：

算法一：

解析 使用transform: translateY(0%);是移动的是自己本身的百分比那么（容器滚动的scrollTop / 当前容器内部高度 * 100）算法如下：

const warp = this.$refs.wrap; // 或者使用documnet获取容器

this.moveY = ((wrap.scrollTop * 100) / wrap.clientHeight);

this.moveX = ((wrap.scrollLeft * 100) / wrap.clientWidth);

算法二：

解析：使用定位top值，这个比较好理解滚动条的滚动 / 容器的滚动总高度 * 100得到百分比，如下：

const warp = this.$refs.wrap; // 或者使用documnet获取容器

this.moveY = ((wrap.scrollTop * 100) / wrap.scrollHeight);

this.moveX = ((wrap.scrollLeft * 100) / wrap.scrollWidth);

把计算出来的moveY、moveX的方法 绑定给scroll 滚动事件就可以了。

四 摁着画的div滚动条 经行拖动

滚动条都是支持拖着上下左右移动的，那咱们也要支持下：

• 获取当前滚动条的高度或者宽度可以使用getBoundingClientRect()如下图：


• 获取拖着移动的距离 就是再鼠标摁下先计一个当前的x1、y1监听move的x2、y2相减就是拖动的距离了。


• 获取到拖动的距离后转成transform || top值。

一个简单的拖动组件如下：

<template>

  <div

    ref="draggableRef"

    class="draggable"

    :style="style"

  >

    <slot />

  </div>

</template>



<script>

export default {

  name: 'DraggableComponent',



  props: {

    initialValue: {

      type: Object,

      required: false,

      default: () => ({ x: 0, y: 0 }),

    },

  },



  data() {

    return {

      currentValue: { x: 0, y: 0 },

      isDragging: false,

      startX: 0,

      startY: 0,

      diffX: 0,

      diffY: 0,

    };

  },



  computed: {

    style() {

      return `left: ${this.currentValue.x + this.diffX}px; top: ${this.currentValue.y + this.diffY}px`;

    },

  },



  watch: {

    initialValue: {

      handler(val) {

        this.currentValue = val;

      },

      immediate: true,

    },

  },



  mounted() {

    this.$nextTick(() => {

      const { draggableRef } = this.$refs;

      if (draggableRef) {

        draggableRef.addEventListener('mousedown', this.startDrag);

        document.addEventListener('mousemove', this.moveDrag);

        document.addEventListener('mouseup', this.endDrag);

      }

    });

  },



  beforeDestroy() {

    const { draggableRef } = this.$refs;

    draggableRef.removeEventListener('mousedown', this.startDrag);

    document.removeEventListener('mousemove', this.moveDrag);

    document.removeEventListener('mouseup', this.endDrag);

  },



  methods: {

    startDrag({ clientX: x1, clientY: y1 }) {

      this.isDragging = true;

      document.onselectstart = () => false;

      this.startX = x1;

      this.startY = y1;

    },



    moveDrag({ clientX: x2, clientY: y2 }) {

      if (this.isDragging) {

        this.diffX = x2 - this.startX;

        this.diffY = y2 - this.startY;

      }

    },



    endDrag() {

      this.isDragging = false;

      document.onselectstart = () => true;

      this.currentValue.x += this.diffX;

      this.currentValue.y += this.diffY;

      this.diffX = 0;

      this.diffY = 0;

    },

  },

};

</script>



<style>

.draggable {

  position: fixed;

  z-index: 9;

}

</style>

咱们需要获取到画的滚动条的高度，然后根据拖动的距离算出来transform: translateY(0%);或者top值；

如上面拖动组件 拖动部分代码就不在重复了 咱们直接用diffX、diffY、lastX、lastY来用了。

• diffX、diffY 是拖动差的值


• lastX、lastY 是上一次也就是未拖动前的值translateY || top

算法一(transform)

const thumb = document.querySelector('el-scrollbar__thumb'); // element ui  el-scrollbar 的滚动条

const { height: thumbHeight } = thumb?.getBoundingClientRect() || {};





const diffY = 10;

const lastY = '300'; // transform: translateY(300%);`

const moveY = (diffY / thumbHeight) + lastY;

算法二(top)

const thumb = document.querySelector('el-scrollbar__thumb'); // element ui  el-scrollbar 的滚动条

const { height: thumbHeight } = thumb?.getBoundingClientRect() || {};





const diffY = 10;

const lastY = 30; // top: 30%`

const moveY = (diffY / wrap.scrollWidth * 100) + lastY;

五 点击滚动轴使滚动条跳转到该位置

• getBoundingClientRect 的 top 是获取到距离浏览器顶部的距离。
  写一个点击事件如下

function clickTrackHandler(event) {

  const wrap = this.$refs.wrap;

  // 1. 减去clientX  正好能获取到需要滚动到的位置

 const offset = Math.abs(e.target.getBoundingClientRect().top - e.clientX);



 // 2. 利用offset 的到画的滚动条的实际位置 两种算法transform || top

  const thumb = document.querySelector('el-scrollbar__thumb'); // element ui  el-scrollbar 的滚动条

  const { height: thumbHeight } = thumb?.getBoundingClientRect() || {};



  const translateY = offset / height * 100; // transform 

  const top = offset / wrap.scrollHeight * 100; // top



  // 3、计算实际需要滚动的高度 使界面滚动到该位置。两种算法transform(scrollTop2) || top(scrollTop1)

  const scrollTop1 = top * wrap.scrollHeight; // top

  const scrollTop2 = translateY * wrap.clientHeight; // transform

}

总结

针对无滚动条如果是vue使用的话，再了解具体实现后可以直接用element 的el-scrollbar组件就好，如果在其他框架中， 结合上面的逻辑也会很快封装一个组件。

标题不够严谨，应该是不想写业务代码的程序员可以做什么。

这里主要覆盖大家可能平时没关注，或者是国内少见的工作；所以像 technical product manager, project manager 这种就不再赘述了。

这里也主要分享 IT 行业内的岗位，要是除开行业限制，范围就太大了。

Developer Relation/Advocate

国外有很多面向开发者的技术创新公司，比如 Vercel ，PlanetScale ，Prisma ，Algolia 等。

这类公司的用户就是开发者，所以他们的市场活动也都是围绕着开发者；他们需要让更多的开发者可以更容易地把他们的技术用到他们的技术栈里，所以就有了这种岗位。用中文来表达，可能有点类似是布道师的意思？

国内更多是将技术应用起来，而不是创造一些新的技术，所以这种岗位在国内就非常少见了。当然近几年也还是有一些技术驱动型公司的，像 PingCAP ，Agora 等。

希望国内有更多像这样的公司出来。

Technical Recruiter

这个工作从 title 上就大概知道是做什么的了。

这个岗位有深有浅，深的可能是比较完整的招聘职能，浅的可能就是 HR 部门里面试和筛选技术候选人的。

Technical Writer

这个听着像是产品经理的工作，确实会和产品的职责有小部分重叠。

这是个面向内部的岗位，不喜欢对外对用户 /客户的朋友会非常喜欢。通常是一些比较大型的企业要做软件迁移或者什么系统、流程升级之类的时候，因为会牵扯到非常多的 moving parts ，所以通常都需要一个独立岗位来负责 documentation 的工作。

工作内容包括采访以及记录各部门的现有流程和业务需求，然后是新流程 /系统 /软件的手册、图表等等。

这里的“technical”不是我们研发中的技术，更多是“业务”层面的意思。同样这个岗位对技术要求不高，但是有研发背景是非常加分的。

Technical Support

通常这个岗位归属客服部门，高于普通 customer service rep 。普通的 customer support 是客户遇到问题时的第一层支持 - 基本会讲话、了解产品就能干的工作；如果第一层解决不了客户的问题，就会升级到后面 technical support 了。

这个岗位范围会更广一点，几乎任何 IT 公司都会有这种支持岗；对技术要求根据不同公司而不同，比如 Vercel 对这个岗位的技术要求肯定比 HelpScout （一个客服软件）要高。

但整体来说都不如研发要求高，但对应的薪酬待遇也没有研发那么好。

结语

其实说了这么多总结下来就是国外技术生态、开源氛围好很多，并且对技术足够的重视，促使很多技术公司的出现，然后催生了这些工作。

如果觉得本帖有启发，欢迎留言支持鼓励后续的创作。

其他相关文章

《找海外工作时可以做的一