其他高频知识点

78 阅读16分钟

1. node是如何处理高并发的

Node.js处理高并发的能力主要得益于其非阻塞I/O模型、事件驱动机制以及单线程架构。以下是对这些特性的详细解释:

  1. 非阻塞I/O:Node.js采用非阻塞I/O,这意味着在进行I/O操作时(如读取文件、发送请求到外部服务或数据库),Node.js不会等待操作完成,而是将操作交给底层系统,同时继续处理后续的代码。一旦I/O操作完成,系统会触发回调函数来处理结果。这种方式减少了线程切换的开销,提高了整个应用程序的执行效率。
  2. 事件驱动和回调函数:Node.js基于事件驱动的模型,通过注册和监听事件来响应请求。当某个异步操作完成或触发了特定的事件,Node.js会执行相应的回调函数来处理结果。这种方式避免了线程阻塞,使得Node.js能够同时处理多个请求。
  3. 单线程架构与事件循环机制:Node.js采用单线程架构,并通过事件循环机制实现异步I/O操作。当有异步I/O操作完成时,会将对应的事件加入到事件队列中,由事件循环机制负责调度执行。这意味着在等待I/O操作完成时,不会占用CPU资源。相反,Node.js会使用事件循环机制快速地处理其他请求。这种机制充分利用了CPU资源,减少了I/O的阻塞等待时间,提高了处理请求的效率。

此外,Node.js在实现高并发时,还可以利用集群和负载均衡来处理大量的请求。通过使用多个进程或服务器来扩展应用程序,可以将请求分配到集群中的不同节点上,从而使整个系统更加快速和高效。

最后,除了Node.js自身的特性外,编写高效的代码和算法也是实现高并发的关键。在Node.js中,可以使用适当的算法来处理大量的数据,并有效地管理内存和CPU资源。

2. 小程序从聊天记录选择文件,上传失败,你觉得应该如何去解决和排查这个问题

  1. 检查文件选择功能

    • 确保小程序的文件选择功能正常,能够正确获取到用户选择的文件路径和文件信息。
    • 检查用户选择文件时是否有权限限制,例如是否允许从聊天记录中选择文件。
  2. 检查文件上传接口

    • 查看小程序的文件上传接口文档,确保按照正确的参数和格式进行调用。
    • 检查接口调用时是否携带了必要的认证信息,如token或session_key。
  3. 检查文件大小和类型限制

    • 确认服务器或接口对上传文件的大小和类型是否有限制,以及用户选择的文件是否满足这些限制。
    • 如果有限制,需要提示用户选择符合要求的文件。
  4. 检查网络连接

    • 确认用户设备的网络连接是否正常,是否存在网络延迟或断开的情况。
    • 可以尝试在网络环境良好的情况下重新上传文件。
  5. 查看服务器日志和错误信息

    • 如果小程序前端无法直接定位问题,可以联系后端开发人员查看服务器日志,了解上传失败的具体原因。
    • 根据服务器返回的错误信息,进一步排查问题所在。
  6. 检查小程序和服务器版本

    • 确保小程序和服务器端的版本都是最新的,避免因版本不兼容导致的问题。
  7. 测试其他场景和设备

    • 在不同的设备和网络环境下测试文件上传功能,以排除特定设备或网络环境导致的问题。
  8. 查看小程序官方文档和社区

    • 查阅小程序官方文档,了解是否有关于文件上传的常见问题或解决方案。
    • 在小程序开发者社区或论坛中搜索类似问题,看是否有其他开发者遇到过并分享了解决方案。

3. Vite作为一种新型前端构建工具,与其他打包工具相比,具有一些明显的优势和缺点。

优势:

  1. 极速的服务启动:Vite使用原生ESM文件,无需打包,从而实现了快速的服务启动。这使得开发过程中的热重载和冷启动都更为迅速。
  2. 优化的构建过程:Vite对打包流程进行了优化,采用按需加载的方式,只对请求的模块进行编译,极大地缩短了编译时间。这种优化在大型项目中尤为明显,能显著提高开发效率。
  3. 丰富的功能和插件:Vite支持TypeScript、JSX、CSS等,无需额外配置即可使用。同时,它提供了丰富的插件接口,允许开发者在开发和构建之间共享插件。
  4. 生态整合:Vite集成了Rollup打包器,可以生成更小、更快的代码包,同时保持了Rollup的灵活性和可扩展性。

缺点:

  1. 生态尚未成熟:由于Vite是一个相对较新的技术,其生态尚未广泛建立,因此可能存在一些不稳定性或兼容性问题。此外,与一些成熟的打包工具相比,Vite的加载器和插件可能不够丰富。
  2. 项目类型限制:Vite主要面向Vue.js项目,因此在其他类型的项目中可能无法发挥出最佳效果。
  3. 浏览器兼容性:Vite要求开发浏览器支持ES Module,并且不能识别CommonJS语法,这可能会限制其在一些老旧浏览器或特定环境下的使用。

4. vite打包大文件性能会不会有影响?

是的,如果Vite打包大文件,性能可能会受到影响。但可以通过一些优化手段来减轻这种影响。例如,使用Vite社区插件中的vite-plugin-compression进行gzip压缩,可以显著减小文件体积,从而提升打包性能和加载速度。在配置这个插件时,可以设定一个阈值,只有大于这个阈值的文件才会被压缩。此外,还可以通过分析项目的文件大小和引用情况,采取针对性的文件分包、cdn引入等技术来优化性能。

请注意,Gzip压缩主要对文本类型的资源有明显提升,对于图片、音频、视频等媒体资源可能并不适用。因此,在优化大文件性能时,还需要根据文件类型来选择合适的优化策略。

5. 前端告警和日志上报埋点都是怎么做的

前端告警

前端告警是指当应用程序出现错误或异常情况时,系统能够自动触发警报通知相关人员,以便及时处理。

  1. 使用第三方服务:如Sentry、Bugsnag等,这些服务可以监控前端的异常和错误,并在出现问题时发送告警通知。
  2. 自定义错误处理:通过捕获window对象的error和unhandledrejection事件,自定义错误处理逻辑,并在检测到错误时发送告警。
  3. 性能监控告警:使用性能监控工具(如Performance API)来监控页面的加载性能,当性能指标超过阈值时触发告警。

日志上报

日志上报是指将应用程序在运行过程中产生的日志信息发送到后端服务器进行存储和分析。这有助于开发人员了解应用程序的运行状态,发现潜在问题,并进行性能优化。

  1. 使用console对象:在前端代码中通过console.log等方法输出日志信息,但这种方式主要用于开发调试,并不适合生产环境。
  2. Ajax请求:通过Ajax向服务器发送日志信息,可以自定义发送的格式和频率,但需要注意跨域和请求被浏览器拦截的问题。
  3. Beacon API:使用浏览器的Beacon API来发送日志数据,该API可以在页面卸载或关闭时可靠地发送数据,确保日志不会丢失。
  4. 第三方日志服务:如Loggly、Papertrail等,这些服务提供了前端日志的收集、存储和分析功能。

埋点

埋点是指在前端应用程序中预设一些关键点,用于收集用户行为数据。通过埋点收集到的数据,开发人员可以了解用户的使用习惯、偏好等信息,进而优化产品功能和用户体验。

  1. 基于Ajax的埋点上报:通过封装Ajax请求来上报埋点数据,与服务端约定接口进行数据传输。但需要注意跨域和请求被拦截的问题。
  2. 基于img标签的埋点上报:通过动态创建一个img标签,并设置其src属性为上报数据的URL,实现数据的上报。这种方式实时性较好,但无法延迟上报。
  3. CSS和按钮结合上报:通过CSS定义content属性,当按钮被点击时触发上报。但这种方式无法动态传入变量。
  4. 可视化埋点:使用可视化工具在前端页面上直接进行埋点操作,无需修改代码。这种方式对于非技术人员来说较为友好,但可能不够灵活。

6. webwoker是什么?有什么用?什么场景可以使用

Web Worker是HTML5中的一个功能,它为JavaScript创建了一个多线程环境。这意味着主线程可以创建Worker线程,将一些任务分配给后者运行,而主线程和Worker线程可以同时运行,互不干扰。这种机制允许JavaScript实现真正的并行处理,提高了页面的性能。

Web Worker的主要作用在于处理那些可能会阻塞主线程的任务,如复杂的计算、大量的数据处理、图像处理、实时通信等。通过将这些任务卸载给独立的Worker线程运行,可以避免影响页面的响应,使得主线程(通常负责UI交互)能够流畅运行,不会被阻塞或拖慢。

具体来说,Web Worker可以在以下场景中使用:

  1. 大数据处理:通过将耗时的数据处理任务交给Web Worker,可以避免阻塞主线程,保持页面的流畅性。
  2. 图像处理:对于需要处理大量图像数据的应用,可以使用Web Worker来实现图像处理,如滤镜、缩放、裁剪等操作。
  3. 计算密集型任务:对于需要进行复杂计算的应用,使用Web Worker可以将计算任务分解为多个子任务,提高计算效率。
  4. 实时通信:Web Worker可以用于实现实时通信功能,如聊天应用、多人协作编辑等,通过与服务器建立长连接,实现实时的数据传输。
  5. 数据缓存和离线应用:Web Worker可以用于实现数据的本地缓存和离线应用功能,通过在后台进行数据的同步和更新,使应用在无网络状态下仍能正常运行。
  6. 后台任务:对于需要在后台运行的任务,如定时任务、后台通知等,可以使用Web Worker来实现。

需要注意的是,Web Worker一旦新建成功,就会始终运行,不会被主线程上的活动(比如用户点击按钮、提交表单)打断。这有利于随时响应主线程的通信,但也造成了Web Worker比较耗费资源,因此不应该过度使用,而且一旦使用完毕,就应该关闭。

7. 大图转化成base64以后大小会减小吗

大图转化成base64以后大小不会减小。实际上,通过Base64编码,原来的3个字节编码后将成为4个字节,即字节增加了33.3%,数据量相应变大。因此,10M的数据通过Base64编码后大小大概为10M*133.3%=13.33M。所以,大图转化成base64后,其大小实际上是增加的。

8. base64对小图片能压缩吗

Base64本身并不直接对小图片进行压缩。Base64编码是一种用64个字符来表示任意二进制数据的方法,它主要用于在文本中嵌入二进制数据。然而,Base64编码会增加数据的大小,因为每3个字节的二进制数据会被编码为4个Base64字符。

9. 上传服务器的静态资源是否被压缩过

上传服务器的静态资源是否被压缩过,这完全取决于上传这些资源之前的处理流程。以下是一些可能的情况:

  1. 手动压缩:如果你在上传资源之前手动使用了压缩工具或软件(如使用图像编辑软件压缩图片,或使用gzip等工具压缩文件),那么这些资源在上传时就已经是压缩状态了。
  2. 构建流程中的压缩:在Web开发过程中,构建流程(如使用Webpack、Gulp等构建工具)可能会自动压缩某些资源,如CSS、JavaScript文件或图片。这些压缩后的资源随后会被上传到服务器。
  3. 服务器端的压缩:一些服务器或CDN(内容分发网络)服务提供了自动压缩静态资源的功能。这意味着,即使你上传的是未压缩的资源,当这些资源被请求时,服务器会在发送之前实时地进行压缩。这通常是通过配置服务器的gzip或deflate模块来实现的。
  4. 不压缩:如果你没有采取任何压缩措施,并且服务器也没有配置为自动压缩资源,那么上传的资源就是未压缩的状态。

要确定服务器上的静态资源是否被压缩,可以:

  • 检查文件大小:压缩后的文件通常比未压缩的文件小。你可以比较原始文件和服务器上的文件大小来初步判断。
  • 检查HTTP响应头:当浏览器请求资源时,服务器会在HTTP响应头中包含一些信息。如果资源已经被压缩,响应头中通常会包含Content-Encoding: gzip或类似的标记。
  • 直接查看资源:如果你有权访问服务器,你可以直接登录到服务器并查看文件内容。压缩后的文件内容通常是不可读的二进制数据。

请注意,即使资源在服务器上是压缩的,也并不意味着每次请求都会发送压缩后的版本。有些服务器会根据请求头中的Accept-Encoding字段来判断是否发送压缩后的资源。如果客户端(如浏览器)不支持压缩,服务器会发送未压缩的版本。

10. 浏览器解析到静态资源是压缩过的还是没有

浏览器解析到的静态资源是否被压缩过,取决于服务器如何响应浏览器的请求。

当浏览器请求一个静态资源时,它会在HTTP请求头中包含Accept-Encoding字段,表明它支持哪些压缩方式,比如gzipdeflate等。如果服务器配置为对静态资源进行压缩,并且客户端(即浏览器)支持相应的压缩方式,那么服务器会返回压缩后的资源,并在HTTP响应头中设置Content-Encoding字段,表明所使用的压缩方式。

在这种情况下,浏览器会接收到压缩后的资源。然后,浏览器会根据Content-Encoding字段的值,使用相应的解压算法对资源进行解压,然后才能正确地解析和显示该资源。

如果服务器没有配置为对静态资源进行压缩,或者客户端不支持任何压缩方式,那么服务器会返回未压缩的资源。浏览器将直接解析和显示这些未压缩的资源

11. 虚拟列表 item height 不定怎么办?

  1. 预先测量

    • 在数据项渲染之前,预先测量每个数据项的高度。这可以通过将每个数据项渲染到屏幕外的DOM元素中,并读取其高度来实现。
    • 将这些高度值存储起来,并在需要时用于计算滚动位置和渲染范围。
  2. 动态测量

    • 当数据项首次进入可视区域时,动态测量其高度。
    • 缓存测量得到的高度值,以便后续快速访问。
    • 这种方法需要监听滚动事件,并在数据项进入可视区域时进行测量和渲染。
  3. 估计与调整

    • 如果数据项的高度在一定范围内变化,可以尝试使用一个估计值来计算初始位置。
    • 当数据项实际渲染后,再根据真实高度调整滚动位置。
  4. 使用库

    • 有许多第三方库支持不定高的虚拟列表,例如 react-windowreact-virtualized 等。这些库通常提供了灵活的配置选项来处理不定高的情况。
  5. 考虑设计

    • 如果可能的话,尽量使数据项的高度固定或在一个可预测的范围内。这可以简化虚拟列表的实现,并提高性能。
  6. 优化滚动性能

    • 当处理大量不定高数据项时,滚动性能可能成为一个问题。使用 windowing 或 chunking 技术来进一步优化滚动体验。
    • 例如,只在用户停止滚动一段时间后才更新视图,以减少不必要的渲染和测量操作。