前端面试题手册

什么是 JS Bridge？JS Bridge，即JavaScript Bridge，是一种在不同环境或者平台之间进行通信的技术，尤其是在Web视图（如WebView）中嵌入的JavaScript与宿主应用（通常是移动应用）之间的通信桥梁。通过JS Bridge，可以使得原生应用可以调用JavaScript代码，JavaScript代码也能调用原生应用的API，从而实现混合开发，充分利用原生应用的性能优势与Web技术的灵活性。JSB 有哪些实现方式？实现JS Bridge的方式通常取决于所使用的平台和具体的需求，以下是一些常见的实现方式：URL Scheme：这是一种较为简单的实现方式。原生应用可以通过拦截WebView中的URL跳转请求来实现与JavaScript的通信。当JavaScript需要与原生应用通信时，它会尝试跳转到一个特殊的URL（如 myscheme://someaction?param1=value1），原生应用拦截这个URL请求，并解析出相应的行为和参数，然后执行相应的原生代码。注入API对象：通过原生代码将一些对象或者方法注入到WebView中的JavaScript环境里。Injected API可以直接在JavaScript代码中被调用，从而实现JavaScript对原生功能的调用。这种方式可以提供更加丰富和直接的接口给JavaScript。消息通道（如postMessage）：现代的Web视图组件（如iOS中的WKWebView）支持使用类似于HTML5中定义的 postMessage API的消息通道，可以实现双向通信。JavaScript可以通过这个API发送消息给原生代码，并且原生代码也可以返回消息给JavaScript。Native Modules：在一些JavaScript框架中，如React Native，可以创建特定的Native Modules来扩展原生应用的功能。这些模块可以被JavaScript代码直接调用，原生代码也可以向JavaScript环境发送事件。示例：假设我们需要实现一个简单的功能，让WebView中的JavaScript能够打开原生应用的摄像头并拍照。使用URL Scheme的方式实现可能如下：在JavaScript中，你可能会有这样的调用代码：function openNativeCamera() { window.location.href = 'myapp://camera/open';}在原生应用中（以iOS为例），你可能需要实现如下的拦截逻辑：- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType { NSURL *URL = [request URL]; if ([[URL scheme] isEqualToString:@"myapp"]) { if ([[URL host] isEqualToString:@"camera"] && [[URL path] isEqualToString:@"/open"]) { // 调用原生摄像头的代码 [self openCamera]; return NO; } } return YES;}- (void)openCamera { // 打开摄像头的逻辑}以上示例展示了如何通过URL Scheme拦截WebView中的跳转来调用原生功能。其他实现方式会有不同的代码示例，但核心思想都是建立一个通信通道，让JavaScript与原生代码能够互相调用。

AMD（Asynchronous Module Definition）和CommonJS是两种流行的JavaScript模块化规范，它们都被设计来允许代码分割成可重用的模块。但是，它们在模块定义、加载机制和使用场景上有所不同。AMD（Asynchronous Module Definition）主要特点：异步加载： AMD被设计用于浏览器环境，可以异步加载模块，不会阻塞页面渲染。定义模块： 使用define函数定义模块，可以显式声明依赖，并在所有依赖加载完成后运行模块的工厂函数。依赖前置： 依赖需要在模块开始加载之前声明，这样可以并行加载依赖。示例：define(['dependency1', 'dependency2'], function (dep1, dep2) { // 定义模块内容 var moduleName = function () { // 一些功能 }; return moduleName;});实现库： RequireJS 是最著名的实现AMD规范的库。CommonJS主要特点：同步加载： CommonJS被设计用于服务器环境，如Node.js，通常假设模块是在本地文件系统中，因此可以同步加载，不会造成浏览器卡顿。定义模块： 使用exports对象或module.exports定义模块的对外接口。后置依赖： 依赖关系通常是在模块的代码体内通过require调用来声明的。示例：var dep1 = require('dependency1');var dep2 = require('dependency2');function moduleName() { // 一些功能}module.exports = moduleName;实现环境： Node.js 原生支持CommonJS模块规范。总结区别加载方式：AMD为异步加载，适合浏览器环境；CommonJS为同步加载，适合服务器环境如Node.js。定义模块：AMD使用define方法，CommonJS使用exports或module.exports。依赖声明：AMD的依赖声明是前置的，而CommonJS依赖通常在需要时才声明。实现和适用环境：AMD的典型实现是RequireJS，主要用在浏览器端；CommonJS的实现是Node.js的模块系统，主要用在服务器端。在实际应用中，如果是开发面向浏览器的应用，并且需要异步加载模块，可能会倾向于使用AMD规范。如果是开发Node.js服务器端应用，CommonJS会是一种更加自然的选择。现代开发中，也有越来越多的工具和语法（如ES6模块）被用来跨越这两种规范的限制，实现更统一的模块化开发体验。

XSS攻击，全称是跨站脚本攻击（Cross-Site Scripting），它是一种网站应用程序的安全漏洞攻击，攻击者通过这种方式可以在用户浏览器端执行恶意脚本。这些恶意脚本一旦在用户浏览器上运行，就可以窃取用户信息、篡改网站内容、无意间欺骗用户执行某些操作等。XSS攻击通常分为三种类型：存储型XSS（Persistent XSS）：恶意脚本被永久存储在目标服务器，如数据库、消息论坛、访客留言等地方。当用户浏览相关页面时，恶意脚本就会被执行。例如，攻击者在社交媒体网站上发表带有恶意JavaScript代码的评论，当其他用户查看该评论时，此脚本便会在他们的浏览器上执行。反射型XSS（Reflected XSS）：恶意脚本不会被存储在服务器上，它是通过诸如URL、电子邮件、即时消息等传达给用户的，用户点击链接后，由服务器动态生成带有攻击代码的页面返回给用户，恶意脚本随即在用户浏览器上执行。比如一个搜索引擎的搜索结果页面包括了用户输入的搜索关键词，如果这个关键词没有被恰当地处理，攻击者可以构造一个特殊的URL，当用户点击这个链接时，搜索关键词处的恶意脚本就会执行。DOM型XSS（DOM-based XSS）：这种类型的攻击中，恶意代码并没有直接在服务器的响应中反映出来，而是在页面已经加载到用户浏览器后，由于DOM环境中的数据流动不安全，攻击脚本得以在客户端运行。例如，一个网页根据URL的参数来决定内容展示，如果没有对参数进行合适的处理，攻击者可以修改URL参数，使页面执行恶意脚本。防御XSS攻击的常用方法包括：对用户输入进行验证和过滤，避免直接输出未经处理的用户输入。使用HTTP-only Cookie，防止JavaScript访问敏感Cookie。实施内容安全策略（CSP），限制页面可以加载和执行的资源类型和来源。对重要的操作使用CSRF令牌，确保请求是由用户自愿发起的。以上就是XSS攻击的概述和防御策略。

CRSF攻击，全称是跨站请求伪造（Cross-Site Request Forgery），是一种网络攻击方式，它允许攻击者在用户不知情的情况下，以该用户的身份执行非授权的命令或更改用户账户信息。CRSF攻击通常利用用户已经认证的身份，例如在网站的认证机制中，用户通常通过输入密码等方式登录之后，会获得一个认证标记（如Cookie），后续的操作就不需要重复进行身份认证。CRSF攻击的典型场景如下：用户登录到银行网站，并在浏览器中保存了登录凭证（如Cookie）。在不退出银行网站的情况下，用户在另一个标签页中访问了一个恶意网站。恶意网站包含了一个指向银行网站的请求（例如，一个图片的链接或一个自动提交的表单），这个请求中包含了转账操作的命令。当用户的浏览器加载恶意网站时，此请求被发出，并且由于用户在银行网站上已经登录，请求中携带了用户的认证凭证。银行网站接收到请求后，误认为是用户自愿发起的操作，从而执行了转账。这种攻击的危险之处在于，用户完全不知情，而攻击者却可以执行诸如转账、密码更改、购买商品等操作。如果网站没有适当的防御机制，CSRF攻击可以对用户造成重大的财务或数据损失。防御CSRF攻击的常见措施包括：使用Anti-CSRF Token：服务器生成一个随机的、不可预测的token，并在每次敏感操作请求时要求客户端提交这个token，服务器验证此token后才执行操作。双重验证：对于重要操作，要求用户重新输入密码或进行其他形式的认证。设置Cookie的SameSite属性：通过设置Cookie的SameSite属性为Strict或Lax，可以限制Cookie不随跨站请求发送，从而减少CSRF攻击的风险。检查Referer和Origin头：服务器可以通过检查HTTP请求头部的Referer或Origin来验证请求的合法性。以上就是对CSRF攻击的简要说明以及如何防御这类攻击的方法。

Object.defineProperty 方法是 JavaScript 中的一个非常重要的方法，它允许精确地添加或修改对象的属性。通过这个方法，我们可以控制属性的各种特性，如它们是否可写、可枚举或可配置，甚至定义存取器属性（getter 和 setter）。Object.defineProperty 方法接受三个参数：要在其上定义属性的对象。将被定义或修改的属性的名称。描述符对象，它定义了属性的具体行为和特征。属性描述符对象可以包含以下键：value：属性的值。writable：如果为 true，则属性的值可以被重写。configurable：如果为 true，则该属性的描述符可以被改变，也可以从对象上删除该属性。enumerable：如果为 true，则该属性会出现在对象的枚举属性中。get：作为属性的 getter 函数，当访问属性时触发。set：作为属性的 setter 函数，当属性值被修改时触发。以下是一个使用 Object.defineProperty 的例子：const person = {};Object.defineProperty(person, 'name', { value: '张三', writable: false, enumerable: true, configurable: true});console.log(person.name); // 输出 '张三'person.name = '李四'; // 由于 writable 是 false，这里的赋值操作不会成功console.log(person.name); // 仍然输出 '张三'在上面的例子中，我们定义了一个对象 person 并使用 Object.defineProperty 给它添加了一个名为 name 的属性。这个属性被设置为不可写，所以尝试更改它的值将不会有任何效果。需要用到 Object.defineProperty 的情况包括：控制属性特性：当你需要精细地控制一个对象属性的可枚举性、可配置性、可写性等。创建只读属性：当你希望对象的某些属性是只读的，不允许修改。定义存取器属性：如果你想通过 getter 和 setter 控制属性的访问和赋值。保护对象结构：在对象创建后保护其结构不被意外改变，比如防止属性被删除。这些特性使得 Object.defineProperty 成为在创建具有特定行为的对象属性时非常有用的工具，特别是在模块和库的开发中，我们经常需要确保对象的接口行为符合预期，防止意外的修改。

JavaScript 中的定时器包括 setTimeout 和 setInterval，这两个函数通常用于延迟执行或定期执行某些代码。但是，它们的执行时间并不精确，原因主要有以下几点：单线程和事件循环：JavaScript 是单线程执行的，它依赖于事件循环来处理异步事件。当你设置一个定时器时，你实际上是告诉事件循环在未来的某个时间点上执行一段代码。但是，如果事件循环在处理其他任务时被阻塞，例如执行一个耗时的同步操作，那么定时器的代码执行将会被推迟直到主线程空闲为止。Web 浏览器的定时器分辨率：出于性能和节能的考虑，Web 浏览器的定时器分辨率不会非常高。这意味着定时器的回调函数可能不会在预期的精确毫秒数后立即执行。不同的浏览器和不同的环境（比如浏览器后台运行或系统睡眠）可能会对定时器的精度有不同的影响。最小延迟时间：在 HTML5 标准中，规定了 setTimeout 和 setInterval 的最小延迟时间通常不得低于4ms（若之前调用了5次以上的定时器，则最小延迟10ms）。这意味着即使你请求更短的时间间隔，执行也会被推迟到这个最小值。浏览器标签页的背景化：当用户将包含JavaScript定时器的浏览器标签页置于后台时，大多数现代浏览器会减少定时器的执行频率以节约资源和电池寿命。这可能导致后台标签页中的定时器变得非常不精确。垃圾回收：JavaScript的垃圾回收机制可能会暂时阻塞主线程，从而延迟定时器的执行。例如，假设你有一个使用 setTimeout 指定在10ms后执行的回调函数，但是此时主线程正在处理一个复杂的计算任务，这可能需要100ms才能完成。在这种情况下，即使定时器的时间到了，回调函数也必须等到计算任务完成后，事件循环才能调用它。所以实际上回调函数的执行时间将晚于预期的10ms。综上所述，由于单线程的特性、事件循环的机制、Web浏览器的实现细节和环境限制，JavaScript定时器的执行时间就不能保证绝对精确。开发者在使用定时器时，应该考虑到这些因素，并且不应该依赖定时器来进行精确的时间控制。

内存泄露通常是指在程序运行过程中，分配的内存未能及时释放，导致随着时间的推移，系统可用内存逐渐减少。当我们在JavaScript中处理原生DOM事件时，如果不正确移除这些事件监听器，很容易导致内存泄露。在详细解释原因之前，先来了解一下事件监听器和内存泄露的基本概念。事件监听器是我们绑定到DOM元素上的函数，用来响应特定的事件，比如点击或者键盘按键。而内存泄露则是指已经不再需要的内存，由于各种原因，没有被及时回收，使得应用程序占用的内存越来越多。现在，让我说明为什么不移除原生事件监听器会导致内存泄露：事件监听器与DOM元素的引用关系：当你给一个DOM元素添加事件监听器时，浏览器会创建一个引用，指向该监听器的函数。即使你从DOM树中移除了这个元素，如果事件监听器没有被移除，那么浏览器的事件处理系统仍然会保留一个对该函数的引用，这导致了DOM元素和监听器函数无法被垃圾回收机制回收，因为从技术上讲，它们依旧是可达的。闭包：在JavaScript中，闭包是一个常见的功能，它允许函数访问并操纵函数外部的变量。如果事件监听器是一个闭包，它可能会引用其他外部变量或对象。只要这个监听器存在，所有它引用的对象也都无法被回收，即使这些对象已经没有其他用途。复杂的引用链：在大型的web应用程序中，DOM元素、事件监听器、以及其他相关对象可能会构成复杂的引用链。这些引用链使得垃圾回收变得复杂，如果链中的某一部分没有被正确管理和解除引用，就可能导致整个链条上的对象都不能被回收。让我举一个例子来说明这个问题：假设我们有一个简单的网页应用，它有一个按钮，当用户点击时会弹出一个警告框：function setup() { var button = document.getElementById('myButton'); button.addEventListener('click', function handleClick() { alert('Button clicked!'); });}setup();如果我们某个时刻决定移除这个按钮：var button = document.getElementById('myButton');button.remove();虽然DOM元素被移除了，但是我们没有移除与之绑定的handleClick事件监听器。这意味着handleClick依然保留着对button元素的引用，因此即使我们从DOM中移除了这个元素，它也不会被垃圾回收。如果我们的应用中有很多这样的操作，随着时间的推移，内存消耗将不断增加，这就是内存泄露。解决这个问题的一个方法是在移除DOM元素之前，显式地移除事件监听器：var button = document.getElementById('myButton');button.removeEventListener('click', handleClick);button.remove();这样，我们就手动断开了事件监听器与DOM元素之间的引用关系，使得这些对象可以被垃圾回收。这是为什么在处理原生DOM事件时，开发者需要注意正确地添加和移除事件监听器，以避免不必要的内存

LocalStorage 是 Web Storage API 的一部分，它允许网页在用户浏览器本地存储数据。下面是 LocalStorage 对象常用的 API 方法：setItem(key, value): 该方法用于在 LocalStorage 中存储数据。它接收两个参数，key（键）表示存储数据的名称，而 value（值）则是实际存储的数据。例如：localStorage.setItem('username', 'JohnDoe');getItem(key): 通过 key（键）检索存储在 LocalStorage 中的值。如果指定的键不存在，它将返回 null。例如：let userName = localStorage.getItem('username');console.log(userName); // 输出: JohnDoeremoveItem(key): 删除 LocalStorage 中的指定 key（键）的数据。例如：localStorage.removeItem('username');clear(): 清除 LocalStorage 中的所有数据。例如：localStorage.clear();length: 一个只读属性，返回 LocalStorage 中的数据项数。例如：let numberOfItems = localStorage.length;console.log(numberOfItems);key(index): 根据索引来获取 LocalStorage 中的键。索引从 0 开始。如果索引超出了范围，将返回 null。例如：let firstKeyName = localStorage.key(0);console.log(firstKeyName);LocalStorage 的数据会以字符串的形式存储，即使你存储的是数字或是对象。如果需要存储对象，通常会使用 JSON.stringify 方法将对象转换为字符串格式存储，检索时再用 JSON.parse 方法将字符串转换回对象。例如：let user = { name: 'John', age: 30 };localStorage.setItem('user', JSON.stringify(user));let retrievedUser = JSON.parse(localStorage.getItem('user'));console.log(retrievedUser); // 输出: { name: 'John', age: 30 }以上就是 LocalStorage 对象的主要 API。需要注意的是，虽然 LocalStorage 提供了方便的本地存储机制，但它并不适合存储敏感信息，因为这些信息是以明文形式存储的，且没有到期时间，容易受到跨站脚本（XSS）攻击的影响。

WebP 图片简介：WebP 是一种现代图像格式，由Google在2010年发布。它是一种旨在为网页图像压缩提供优异的压缩比的格式，其目标是减小图像的文件大小，而在视觉上保持高质量。WebP 支持无损压缩和有损压缩，同时还支持透明度（Alpha通道）和动画。WebP 的优势：更小的文件大小： 相较于传统的JPEG和PNG格式，WebP图像通常可以在不牺牲视觉质量的情况下提供更小的文件大小。这意味着更快的加载时间和更低的带宽消耗，这对于移动设备用户和带宽有限的环境尤其重要。支持有损和无损压缩： WebP既可以提供有损压缩以减少文件大小，也可以提供无损压缩来保持图像质量。这使得它比只能提供一种压缩方式的格式更为灵活。支持动画： WebP可以替代传统的GIF格式，提供更优的动画压缩效果，同时文件尺寸比GIF更小。支持透明度： 除了对颜色的压缩外，WebP还支持8位的透明通道，即使是在有损压缩的情况下也能处理透明度，这对于网页设计中的图标和图形元素非常有用。色彩表现： WebP支持广色域，这意味着它能够展现更丰富的颜色和更平滑的色彩过渡。WebP 的缺点：兼容性问题： 尽管WebP的支持正在增加，但一些旧的浏览器和图像编辑软件还不支持WebP格式。这可能导致必须为不同的用户提供不同格式的图片。编辑软件支持有限： 相较于JPEG和PNG，WebP格式在图像编辑软件中的支持较少，可能需要使用特定的工具来编辑或转换这些图像。用户认知： 普通用户可能不熟悉WebP格式，对于需要用户上传图片的网站来说，可能需要额外的工作来确保用户上传的图片是支持的格式。转换成本： 对于已经有大量存量图片的网站，将图片转换为WebP格式可能需要消耗一定的时间和资源。例子：为了说明WebP格式的优势，我们可以考虑一个在线商城。该商城的页面包含了大量的产品图片，如果这些图片使用WebP格式而不是JPEG或PNG，那么页面加载速度可能会显著提高，从而改善用户体验和提升转化率。在一个实际测试中，转换JPEG图片到WebP格式，可能会看到文件大小减少25%以上，而视觉上的差异几乎察觉不到。这对于用户来说意味着更快的加载时间，对于商城运营者来说，则意味着更低的数据传输费用。然而，为了确保所有用户都能正常浏览图片，商城可能需要保留JPEG或PNG格式的备份，以便不支持WebP的浏览器也能显示图片。

移动设备的Android和iOS平台在软键盘弹出的处理方式上确实存在一些差异，主要反映在以下几个方面：1. 视图调整Android:Android平台上，当软键盘弹出时，默认情况下会重新调整活动(Activity)的大小，以确保当前获得焦点的输入字段可见。开发者可以通过设置AndroidManifest.xml中Activity的windowSoftInputMode属性来调整这一行为。例如，adjustResize会调整Activity的大小，而adjustPan会上移整个视图。例子：<activity android:name=".MainActivity" android:windowSoftInputMode="adjustResize"></activity>iOS:在iOS上，软键盘的弹出默认不会引起视图的调整，除非开发者主动编写代码来处理键盘事件。开发者通常需要监听键盘的UIKeyboardWillShow和UIKeyboardWillHide通知，并据此调整视图，比如通过更改底部视图的约束或者滚动视图的contentInset。例子：NotificationCenter.default.addObserver(self, selector: #selector(keyboardWillShow), name: UIResponder.keyboardWillShowNotification, object: nil)NotificationCenter.default.addObserver(self, selector: #selector(keyboardWillHide), name: UIResponder.keyboardWillHideNotification, object: nil)@objc func keyboardWillShow(notification: NSNotification) { // 调整视图以适应键盘}@objc func keyboardWillHide(notification: NSNotification) { // 恢复视图}2. 第三方键盘支持Android:Android系统在较早时候就开放了对第三方键盘应用的支持，因此Android上的应用需要能够适应多样的键盘布局和行为。iOS:iOS开始对第三方键盘支持是从iOS 8开始的，iOS平台上的应用也需要适应不同的键盘行为，虽然Apple提供了一套相对统一的界面风格。3. 输入法切换Android:Android设备通常会在软键盘上提供一个方便的输入法切换按钮，允许用户快速切换不同的键盘。iOS:iOS设备通常需要用户通过点击全局的键盘切换键或者长按地球标志键来切换输入法。4. API和框架支持Android:Android提供了InputMethodManager等API来管理软键盘的显示和隐藏。iOS:iOS通过UIKit框架中的UITextField、UITextView等组件与键盘进行交互，同时提供了相关的API来控制键盘的行为。5. 软键盘定制Android:Android允许开发者相对更深层次地定制软键盘，例如通过创建自定义输入法编辑器（IME）。iOS:iOS对于键盘的定制性较低，对于标准的键盘行为有着较严格的界面指南。总结：Android和iOS在软键盘弹出的处理方式上体现出的差异主要是由于两个平台的设计哲学和开发者工具的不同。Android提供了更多的自动调整视图的选项和对第三方键盘的支持，而iOS则要求开发者更加主动地管理键盘事件和视图调整。开发者在开发跨平台应用时，需要了解这些差异，并确保提供适合各自平台的用户体验。