探析它之前，我们先抛出以下几个疑问：

• 为什么需要 V8 引擎呢？

• V8 引擎到底是个啥？

• 它可以做些什么呢？

• 了解它能有什么收获呢？

接下来就针对以上几个问题进行详细描述。

由来

我们都知道，JS 是一种解释型语言，支持动态类型（明显不同于 Java 等这类静态语言就是在命名一个变量时不需要声明变量的类型）、弱类型、基于原型的语言，内置支持类型。而一般 JS 都是在前端执行（直接影响界面），需要能够快速响应用户，那么就要求语言本身可以被快速地解析和执行，JS 引擎就为此而问世。

这里提到了解释型语言和静态语言（编译型语言），先简单介绍一下二者：

• 解释型语言（JS）

  • 每次运行时需要解释器按句依次解释源代码执行，将它们翻译成机器认识的机器代码再执行

• 编译型语言（Java)

  • 运行时可经过编译器翻译成可执行文件，再由机器运行该可执行文件即可

从上面的描述中可以看到 JS 运行时每次都要根据源文件进行解释然后执行，而编译型的只需要编译一次，下次可直接运行其可执行文件，但是这样就会导致跨平台的兼容性很差，因此各有优劣。

而众多 JS 引擎（V8、JavaScriptCore、SpiderMonkey、Chakra等）中 V8 是最为出色的，加上它也是应用于当前最流行的谷歌浏览器，所以我们非常有必要去认识和了解一下，这样对于开发者也就更清楚 JS 在浏览器中到底是如何运行的了。

认识

定义

• 使用 C++ 开发

• 谷歌开源

• 编译成原生机器码（支持IA-32, x86-64, ARM, or MIPS CPUs）

• 使用了如内联缓存（inline caching）等方法来提高性能

• 运行速度快，可媲美二进制程序

• 支持众多操作系统，如 windows、linux、android 等

• 支持其他硬件架构，如 IA32,X64,ARM 等

• 具有很好的可移植和跨平台特性

运行

先来一张官方流程图：

准备

JS 文件加载（不归 V8 管）：可能来自于网络请求、本地的cache或者是也可以是来自service worker，这是 V8 运行的前提（有源文件才有要解释执行的）。 3种加载方式 & V8的优化：

• Cold load: 首次加载脚本文件时，没有任何数据缓存

• Warm load：V8 分析到如果使用了相同的脚本文件，会将编译后的代码与脚本文件一起缓存到磁盘缓存中

• Hot load: 当第三次加载相同的脚本文件时，V8 可以从磁盘缓存中载入脚本，并且还能拿到上次加载时编译后的代码，这样可以避免完全从头开始解析和编译脚本

而在 V8 6.6 版本的时候进一步改进代码缓存策略，简单讲就是从缓存代码依赖编译过程的模式，改变成两个过程解耦，并增加了可缓存的代码量，从而提升了解析和编译的时间，大大提升了性能，具体细节见V8 6.6 进一步改进缓存性能。

分析

此过程是将上面环节得到的 JS 代码转换为 AST（抽象语法树）。

词法分析

从左往右逐个字符地扫描源代码，通过分析，产生一个不同的标记，这里的标记称为 token，代表着源代码的最小单位，通俗讲就是将一段代码拆分成最小的不可再拆分的单元，这个过程称为词法标记，该过程的产物供下面的语法分析环节使用。

这里罗列一下词法分析器常用的 token 标记种类：

• 常数（整数、小数、字符、字符串等）

• 操作符（算术操作符、比较操作符、逻辑操作符）

• 分隔符（逗号、分号、括号等）

• 保留字

• 标识符（变量名、函数名、类名等）

TOKEN-TYPE TOKEN-VALUE\
-----------------------------------------------\
T_IF                 if\
T_WHILE              while\
T_ASSIGN             =\
T_GREATTHAN          >\
T_GREATEQUAL         >=\
T_IDENTIFIER name    / numTickets / ...\
T_INTEGERCONSTANT    100 / 1 / 12 / ....\
T_STRINGCONSTANT     "This is a string" / "hello" / ...

上面提到会逐个从左至右扫描代码然后分析，那么很明显就会想到两种方案，扫描完再分析（非流式处理）和边扫描边分析（流式处理），简单画一下他们的时序图就能发现流式处理效率要高得多，同时分析完也会释放分析过程中占用的内存，也能大大提高内存使用效率，可见该优化的细节处理。

语法分析

语法分析是指根据某种给定的形式文法对由单词序列构成的输入文本（例如上个阶段的词法分析产物-tokens stream），进行分析并确定其语法结构的过程，最后产出其 AST（抽象语法树）。

V8 会将语法分析的过程分为两个阶段来执行：

• Pre-parser

  • 跳过还未使用的代码

  • 不会生成对应的 AST，会产生不带有变量的引用和声明的 scopes 信息

  • 解析速度会是 Full-parser 的 2 倍

  • 根据 JS 的语法规则仅抛出一些特定的错误信息

• Full-parser

  • 解析那些使用的代码

  • 生成对应的 AST

  • 产生具体的 scopes 信息，带有变量引用和声明等信息

  • 抛出所有的 JS 语法错误

为什么要做两次解析？

如果仅有一次，那只能是 Full-parser，但这样的话，大量未使用的代码会消耗非常多的解析时间，结合实例来看下：通过 Coverage 录制的方式可以分析页面哪些代码没有用到，如下图可以看到最高有 75% 的没有被执行。

但是预解析并不是万能的，得失是并存的，很明显的一个场景：该文件中的代码全都执行了，那其实就是没必要的，当然这种情况其实还是占比远不如上面的例子，所以这里其实也是一种权衡，需要照顾大多数来达到综合性能的提升。

下面给出一个示例：

function add(x, y) {
    if (typeof x === "number") {
        return x + y;
    } else {
        return x + 'tadm';
    }
}

复制上面的代码到 web1 和 web2 可以很直观的看到他们的 tokens 和 AST 结构（也可自行写一些代码体验）。

• tokens

[
    {
        "type": "Keyword",
        "value": "function"
    },
    {
        "type": "Identifier",
        "value": "add"
    },
    {
        "type": "Punctuator",
        "value": "("
    },
    {
        "type": "Identifier",
        "value": "x"
    },
    {
        "type": "Punctuator",
        "value": ","
    },
    {
        "type": "Identifier",
        "value": "y"
    },
    {
        "type": "Punctuator",
        "value": ")"
    },
    {
        "type": "Punctuator",
        "value": "{"
    },
    {
        "type": "Keyword",
        "value": "if"
    },
    {
        "type": "Punctuator",
        "value": "("
    },
    {
        "type": "Keyword",
        "value": "typeof"
    },
    {
        "type": "Identifier",
        "value": "x"
    },
    {
        "type": "Punctuator",
        "value": "==="
    },
    {
        "type": "String",
        "value": "\"number\""
    },
    {
        "type": "Punctuator",
        "value": ")"
    },
    {
        "type": "Punctuator",
        "value": "{"
    },
    {
        "type": "Keyword",
        "value": "return"
    },
    {
        "type": "Identifier",
        "value": "x"
    },
    {
        "type": "Punctuator",
        "value": "+"
    },
    {
        "type": "Identifier",
        "value": "y"
    },
    {
        "type": "Punctuator",
        "value": ";"
    },
    {
        "type": "Punctuator",
        "value": "}"
    },
    {
        "type": "Keyword",
        "value": "else"
    },
    {
        "type": "Punctuator",
        "value": "{"
    },
    {
        "type": "Keyword",
        "value": "return"
    },
    {
        "type": "Identifier",
        "value": "x"
    },
    {
        "type": "Punctuator",
        "value": "+"
    },
    {
        "type": "String",
        "value": "'tadm'"
    },
    {
        "type": "Punctuator",
        "value": ";"
    },
    {
        "type": "Punctuator",
        "value": "}"
    },
    {
        "type": "Punctuator",
        "value": "}"
    }
]

• AST

{
  "type": "Program",
  "body": [
    {
      "type": "FunctionDeclaration",
      "id": {
        "type": "Identifier",
        "name": "add"
      },
      "params": [
        {
          "type": "Identifier",
          "name": "x"
        },
        {
          "type": "Identifier",
          "name": "y"
        }
      ],
      "body": {
        "type": "BlockStatement",
        "body": [
          {
            "type": "IfStatement",
            "test": {
              "type": "BinaryExpression",
              "operator": "===",
              "left": {
                "type": "UnaryExpression",
                "operator": "typeof",
                "argument": {
                  "type": "Identifier",
                  "name": "x"
                },
                "prefix": true
              },
              "right": {
                "type": "Literal",
                "value": "number",
                "raw": "\"number\""
              }
            },
            "consequent": {
              "type": "BlockStatement",
              "body": [
                {
                  "type": "ReturnStatement",
                  "argument": {
                    "type": "BinaryExpression",
                    "operator": "+",
                    "left": {
                      "type": "Identifier",
                      "name": "x"
                    },
                    "right": {
                      "type": "Identifier",
                      "name": "y"
                    }
                  }
                }
              ]
            },
            "alternate": {
              "type": "BlockStatement",
              "body": [
                {
                  "type": "ReturnStatement",
                  "argument": {
                    "type": "BinaryExpression",
                    "operator": "+",
                    "left": {
                      "type": "Identifier",
                      "name": "x"
                    },
                    "right": {
                      "type": "Literal",
                      "value": "tadm",
                      "raw": "'tadm'"
                    }
                  }
                }
              ]
            }
          }
        ]
      },
      "generator": false,
      "expression": false,
      "async": false
    }
  ],
  "sourceType": "script"
}

解释

该阶段就是将上面产生的 AST 转换成字节码。

这里增加字节码（中间产物）的好处是，并不是将 AST 直接翻译成机器码，因为对应的 cpu 系统会不一致，翻译成机器码时要结合每种 cpu 底层的指令集，这样实现起来代码复杂度会非常高；还有个就是内存占用的问题，因为机器码会存储在内存中，而退出进程后又会存储在磁盘上，加上转换后的机器码多出来很多信息，会比源文件大很多，导致了严重的内存占用问题。

V8 在执行字节码的过程中，使用到了通用寄存器和累加寄存器，函数参数和局部变量保存在通用寄存器里面，累加器中保存中间计算结果，在执行指令的过程中，如果直接由 cpu 从内存中读取数据的话，比较影响程序执行的性能，使用寄存器存储中间数据的设计，可以大大提升 cpu 执行的速度。

编译

这个过程主要是 V8 的 TurboFan编译器 将字节码翻译成机器码的过程。

字节码配合解释器和编译器这一技术设计，可以称为JIT（即时编译技术），Java 虚拟机也是类似的技术，解释器在解释执行字节码时，会收集代码信息，标记一些热点代码（就是一段代码被重复执行多次），TurboFan 会将热点代码直接编译成机器码，缓存起来，下次调用直接运行对应的二进制的机器码，加快执行速度。

在 TurboFan 将字节码编译成机器码的过程中，还进行了简化处理：常量合并、强制折减、代数重新组合。

比如：3 + 4 --> 7，x + 1 + 2 --> x + 3 ......

执行

到这里我们就开始执行上一阶段产出的机器码。

而在 JS 的执行过程中，经常遇到的就是对象属性的访问。作为一种动态的语言，一个简单的属性访问可能包含着复杂的语义，比如Object.xxx的形式，可能是属性的直接访问，也可能去调用的对象的Getter方法，还有可能是要通过原型链往上层对象中查找。这种不确定性而且动态判断的情况，会浪费很多查找时间，所以 V8 会把第一次分析的结果放在缓存中，当再次访问相同的属性时，会优先从缓存中去取，调用 GetProperty(Object, "xxx", feedback_cache) 的方法获取缓存，如果有缓存结果，就会跳过查找过程，又大大提升了运行性能。

除了上面针对读取对象属性的结果缓存的优化，V8 还引入了 Object Shapes（隐藏类）的概念，这里面会记录一些对象的基本信息（比如对象拥有的所有属性、每个属性对于这个对象的偏移量等），这样我们去访问属性时就可以直接通过属性名和偏移量直接定位到他的内存地址，读取即可，大大提升访问效率。

既然 V8 提出了隐藏类（两个形状相同的对象会去复用同一个隐藏类，何为形状相同的对象？两个对象满足有相同个数的相同属性名称和相同的属性顺序），那么我们开发者也可以很好的去利用它：

• 尽量创建形状相同的对象

• 创建完对象后尽量不要再去操作属性，即不增加或者删除属性，也就不会破环对象的形状

完成

到此 V8 已经完成了一份 JS 代码的读取、分析、解释、编译、执行。

总结

以上就是从 JS 代码下载到最终在 V8 引擎执行的过程分析，可以发现 V8 其实有很多实现的技术点，有着很巧妙的设计思想，比如流式处理、缓存中间产物、垃圾回收等，这里面又会涉及到很多细节，很值得继续深入研究。

作者：Tadm
来源：https://juejin.cn/post/7032278688192430117

前言

作为一个前端，对于console.log的调试可谓是相当熟悉，话不多说就是好用！帮助我们解决了很多bug^_^
但是！有因必有果（虽然不知道为什么说这句但是很顺口），如果把console发到生产环境也是很头疼的，尤其是如果打印的信息很私密的话，可能要凉凉TT

删除console方式介绍

对于在生产环境必须要清除的console语句，如果手动一个个删除，听上去就很辛苦，因此这篇文章本着看到了就要学，学到了就要用的精神我打算介绍一下手写loader的方式清除代码中的console语句，在此之前也介绍一下其他可以清除console语句的方式吧哈哈

1. 方式一：暴力清除

通过编辑器查找所有console，或者eslint编译时的报错提示定位语句，然后清除，就是有点费手，不够优雅
因此下面需要介绍几种优雅的清除方式

2. 方式二 ：uglifyjs-webpack-plugin

该插件可用于压缩我们的js代码，同时可以通过配置去掉console语句，安装后配置在webpack的optimization下，即可使用，需要注意的是：此配置只在production环境下生效

安装
npm i uglifyjs-webpack-plugin

其中drop_console和pure_funcs的区别是：

• drop_console的配置值为boolean，也就是说如果为true，那么代码中所有带console前缀的调试方式都会被清除，包括console.log,console.warn等

• pure_funcs的配置值是一个数组，也就是可以配置清除那些带console前缀的语句，截图中配的是['console.log'],因此生产环境上只会清除console.log,如果代码中包含其他带console的前缀，如console.warn则保留

但是需要注意的是，该方法只对ES5语法有效，如果你的代码中涉及ES6就会报错

3. 方式三：terser-webpack-plugin

webpack v5 开箱即带有最新版本的 terser-webpack-plugin。如果你使用的是 webpack v5 或更高版本，同时希望自定义配置，那么仍需要安装 terser-webpack-plugin。如果使用 webpack v4，则必须安装 terser-webpack-plugin v4 的版本。

安装
npm i terser-webpack-plugin@4

terser-webpack-plugin对于清楚console的配置可谓是跟uglifyjs-webpack-plugin一点没差，但是他们最大的差别就是TerserWebpackPlugin支持ES6的语法

4. 方式四：手写loader删除console

终于进入了主题了，朋友们

1. 什么是loader

众所周知，webpack只能理解js，json等文件，那么除了js，json之外的文件就需要通过loader去顺利加载，因此loader在其中担任的就是翻译工作。loader可以看作一个node模块，实际上就是一个函数，但他不能是一个箭头函数，因为它需要继承webpack的this，可以在loader中使用webpack的方法。

• 单一原则，一个loader只做一件事

• 调用方式，loader是从右向左调用，遵循链式调用

• 统一原则，输入输出都是字符串或者二进制数据

根据第三点，下面的代码就会报错，因为输出的是数字而不是字符串或二进制数据

module.exports = function(source) {
    return 111
}

1. 新建清除console语句的loader

首先新建一个dropConsole.js文件

// source：表示当前要处理的内容
const reg = /(console.log\()(.*)(\))/g;
module.exports = function(source) {
    // 通过正则表达式将当前处理内容中的console替换为空字符串
    source = source.replace(reg, "")
    // 再把处理好的内容return出去，坚守输入输出都是字符串的原则，并可达到链式调用的目的供下一个loader处理
    return source
}

1. 在webpack的配置文件中引入

module: {
    rules:[
        {
            test: /\.js/,
            use: [
               {
                loader: path.resolve(__dirname, "./dropConsole.js"),
                options: {
                 name: "前端"
                }
               }
            ]
        },
      {
   ]
}

在webpack的配置中，loader的导入需要绝对路径，否则导入失效，如果想要像第三方loader一样引入，就需要配置resolveLoader 中的modules属性，告诉webpack，当node_modules中找不到时，去别的目录下找

module: {
    rules:[
        {
            test: /\.js/,
            use: [
               {
                loader: 'dropConsole',
                options: {
                 name: "前端"
                }
               }
            ]
        },
      {
   ]
}
resolveLoader:{
    modules:["./node_modules","./build"] //此时我的loader写在build目录下
},

正常运行后，调试台将不会打印console信息

1. 最后介绍几种在loader中常用的webpack api

• this.query:返回webpack的参数即options的对象

• this.callback:同步模式，可以把自定义处理好的数据传递给webpack

const reg = /(console.log\()(.*)(\))/g;
module.exports = function(source) {
    source = source.replace(reg, "");
    this.callback(null,source);
    // return的作用是让webpack知道loader返回的结果应该在this.callback当中，而不是return中
    return     
}

• this.async():异步模式，可以大致的认为是this.callback的异步版本，因为最终返回的也是this.callback

const  path = require('path')
const util  = require('util')
const babel = require('@babel/core')


const transform = util.promisify(babel.transform)

module.exports = function(source,map,meta) {
  var callback = this.async();

  transform(source).then(({code,map})=> {
      callback(null, code,map)
  }).catch(err=> {
      callback(err)
  })
};

最后的最后，webpack博大精深，值得我们好好学习，深入研究！

作者：我也想一夜暴富
来源：https://juejin.cn/post/7038413043084034062

为什么要热更新

热更新主要是针对app上线之后页面出现bug，修改之后又得打包，上线，每次用户都得在应用市场去下载很影响用户体验，如果用户不愿意更新，一直提示都不愿意更新，这个bug就会一直存在。 可能你一不小心写错了代码，整个团队的努力都会付之东流，苦不苦，冤不冤，想想都苦，所以这个时候热更新就显得很重要了。

首先你需要在manifest.json 中修改版本号

如果之前是1.0.0那么修改之后比如是1.0.1或者1.1.0这样

然后你需要在HBuilderX中打一个wgt包

在顶部>发行>原生App-制作移动App资源升级包

包的位置会在控制台里面输出

你需要和后端约定一下接口，传递参数

然后你就可以在app.vue的onLaunch里面编写热更新的代码了，如果你有其他需求，你可以在其他页面的onLoad里面编写。

// #ifdef APP-PLUS  //APP上面才会执行
plus.runtime.getProperty(plus.runtime.appid,
function(widgetInfo) {
    uni.request({
        url: '请求url写你自己的',
        method: "POST",
        data: {
            version: widgetInfo.version,
            //app版本号
            name: widgetInfo.name //app名称
        },
        success: (result) = >{
            console.log(result) //请求成功的数据
            var data = result.data.data
            if (data.update && data.wgtUrl) {
                var uploadTask = uni.downloadFile({ //下载
                    url: data.wgtUrl,
                    //后端传的wgt文件
                    success: (downloadResult) = >{ //下载成功执行
                        if (downloadResult.statusCode === 200) {
                            plus.runtime.install(downloadResult.tempFilePath, {
                                force: flase
                            },
                            function() {
                                plus.runtime.restart();
                            },
                            function(e) {});
                        }
                    },
                }) uploadTask.onProgressUpdate((res) = >{
                    // 测试条件，取消上传任务。
                    if (res.progress == 100) { //res.progress 上传进度
                        uploadTask.abort();
                    }
                });
            }
        }
    });
});
// #endif

不支持的情况

• SDK 部分有调整，比如新增了 Maps 模块等，不可通过此方式升级，必须通过整包的方式升级。

• 原生插件的增改，同样不能使用此方式。
  对于老的非自定义组件编译模式，这种模式已经被淘汰下线。但以防万一也需要说明下，老的非自定义组件编译模式，如果之前工程没有 nvue 文件，但更新中新增了 nvue 文件，不能使用此方式。因为非自定义组件编译模式如果没有nvue文件是不会打包weex引擎进去的，原生引擎无法动态添加。自定义组件模式默认就含着weex引擎，不管工程下有没有nvue文件。

注意事项

• 条件编译，仅在 App 平台执行此升级逻辑。

• appid 以及版本信息等，在 HBuilderX 真机运行开发期间，均为 HBuilder 这个应用的信息，因此需要打包自定义基座或正式包测试升级功能。

• plus.runtime.version 或者 uni.getSystemInfo() 读取到的是 apk/ipa 包的版本号，而非 manifest.json 资源中的版本信息，所以这里用 plus.runtime.getProperty() 来获取相关信息。

• 安装 wgt 资源包成功后，必须执行 plus.runtime.restart()，否则新的内容并不会生效。

• 如果App的原生引擎不升级，只升级wgt包时需要注意测试wgt资源和原生基座的兼容性。平台默认会对不匹配的版本进行提醒，如果自测没问题，可以在manifest中配置忽略提示，详见ask.dcloud.net.cn/article/356…

• http://www.example.com 是一个仅用做示例说明的地址，实际应用中应该是真实的 IP 或有效域名，请勿直接复制粘贴使用。

关于热更新是否影响应用上架

应用市场为了防止开发者不经市场审核许可，给用户提供违法内容，对热更新大多持排斥态度。

但实际上热更新使用非常普遍，不管是原生开发中还是跨平台开发。

Apple曾经禁止过jspatch，但没有打击其他的热更新方案，包括cordovar、react native、DCloud。封杀jspatch其实是因为jspatch有严重安全漏洞，可以被黑客利用，造成三方黑客可篡改其他App的数据。

使用热更新需要注意：

• 上架审核期间不要弹出热更新提示

• 热更新内容使用https下载，避免被三方网络劫持

• 不要更新违法内容、不要通过热更新破坏应用市场的利益，比如iOS的虚拟支付要老老实实给Apple分钱

如果你的应用没有犯这些错误，应用市场是不会管的。

作者：是一个秃头
来源：https://juejin.cn/post/7039273141901721608

GC回收机制

一、前言

垃圾回收：Garbage Collection，简写 GC。JVM 中的垃圾回收器会自动回收无用的对象。

但是 GC 自动回收的代价是：当这种自动化机制出错，我们就需要深入理解 GC 回收机制，甚至需要对这些 自动化 的技术实施必要的监控与调节。

在虚拟机中，程序计数器、虚拟机栈、本地方法栈 3 个区域随线程而生，随线程而灭，栈中的栈帧随着方法的进入和退出而执行着出栈和入栈操作。所以这几个区域不需要考虑回收的问题。

而在 堆和方法区 中，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样。这部分的只有在程序运行期间才会知道需要创建哪些对象，这部分的内存的创建和回收是动态的，也是垃圾回收器重点关注的地方。

二、什么是垃圾

垃圾 就是 内存中已经没有用的对象。既然是 垃圾回收，就必须知道哪些对象是垃圾。

Java 虚拟机中使用了一种叫做 可达性分析 的算法 来决定对象是否可以被回收。

上图中 A、B、C、D、E 与 GCRoot 直接或间接产生引用链，所以 GC 扫描到这些对象时，并不会执行回收操作；J、K、M虽然之间有引用链，但是并没有与 GCRoot 存在引用链，所以当 GC 扫描到他们时会将他们回收。

注意的是，上图中所有的对象，包括 GCRoot，都是内存中的引用。

作为 GCRoot 的几种对象

1. Java虚拟机栈（局部变量表）中的引用的对象；

2. 方法区中静态引用指向的对象；

3. 仍处于存活状态中的线程对象；

4. Native方法中 JNI 引用的对象；

三、什么时候回收

不同的虚拟机实现有着不同的 GC 实现机制，但一般情况下都会存在下面两种情况：

1. Allocation Failure：在堆内存分配中，如果因为可用剩余空间不足导致对象内存分配失败，这时系统会触发一次 GC。

2. System.gc()：在应用层，Java开发工程师可以主动调用此API来请求一次 GC。

四、验证GCRoot的几种情况

在验证之前，先了解Java命令时的参数。

-Xms：初始分配 JVM 运行时的内存大小，如果不指定则默认为物理内存的 1/64。

举个小例子

// 表示从物理内存中分配出 200M 空间给 JVM 内存
java -Xms200m HelloWorld

1.验证虚拟机栈（栈帧中的局部变量）中引用的对象作为 GCRoot

// 验证代码
public class GCRootLocalVariable {

    private int _10MB = 10 * 1024 * 1024;
    private byte[] memory = new byte[8 * _10MB];

    public static void main(String[] args) {
        System.out.println("开始时：");
        printMemory();
        method();
        System.gc();
        System.out.println("第二次GC完成");
        printMemory();
    }

    public static void method() {
        GCRootLocalVariable gc = new GCRootLocalVariable();
        System.gc();
        System.out.println("第一次GC完成");
        printMemory();
    }

    // 打印出当前JVM剩余空间和总的空间大小
    public static void printMemory() {
        long freeMemory = Runtime.getRuntime().freeMemory();
        long totalMemory = Runtime.getRuntime().totalMemory();
        System.out.println("剩余空间：" + freeMemory / 1024 / 1024 + "M");
        System.out.println("总共空间：" + totalMemory / 1024 / 1024 + "M");
    }
}
// 打印日志：
开始时：
剩余空间：119M
总共空间：123M
第一次GC完成
剩余空间：40M
总共空间：123M
第二次GC完成
剩余空间：120M
总共空间：123M

从上述代码中可以看到：

第一次打印内存信息，分别为 119M 和 123M；

第二次打印内存信息，分别为 40M 和 123M；剩余空间小了 80M，是因为在 method() 方法中创建了局部变量 gc（位于栈帧中的局部变量），并且这个 gc 对象会被作为 GCRoot。虽然创建的对象未被使用并且调用了 System.gc()，但是因为该方法未结束，所以创建的对象不能被回收。

第三次打印内存信息，分别为 120M 和 123M；method() 方法已经结束，创建的对象 gc 也随方法消失，不再有引用类型指向该 80M 对象。

【值得注意的是】

private int _10MB = 10 * 1024 * 1024;
private byte[] memory = new byte[8 * _10MB];

上面 2 行代码是必须的，如果去掉，那么 3 次打印结果将会一致，idea 也会出现Instantiation of utility class 警告信息，说这个类只存在静态方法，没必要创建这个对象。

这也就是说为什么创建 GCRootLocalVariable() 会需要 80M 的大小，是因为 GCRootLocalVariable 在创建时就会为其内部变量 memory 确定 80M 的大小。

2.验证方法区中的静态变量引用的对象作为 GCRoot

public class GCRootStaticVariable {
    private static int _10M = 10 * 1024 * 1024;
    private byte[] memory;
    private static GCRootStaticVariable staticVariable;

    public GCRootStaticVariable(int size) {
        memory = new byte[size];
    }

    public static void main(String[] args) {
        System.out.println("程序开始：");
        printMemory();
        GCRootStaticVariable g = new GCRootStaticVariable(2 * _10M);
        g.staticVariable = new GCRootStaticVariable(4 * _10M);
        // 将g设置为null，调用GC时可以回收此对象内存
        g = null;
        System.gc();
        System.out.println("GC完成");
        printMemory();
    }

    // 打印JVM剩余空间和总空间
    private static void printMemory() {
        long freeMemory = Runtime.getRuntime().freeMemory();
        long totalMemory = Runtime.getRuntime().totalMemory();
        System.out.println("剩余空间" + freeMemory/1024/1024 + "M");
        System.out.println("总共空间" + totalMemory/1024/1024 + "M");
    }
}

打印结果：
程序开始：
剩余空间119M
总共空间123M
GC完成
剩余空间81M
总共空间123M

通过上述打印结果可知：

1. 程序刚开始时打印结果为 119M；

2. 当创建 g 对象时分配 20M 内存，又为静态变量 staticVariable 分配 40M 内存；

3. 当调用 gc 回收时，非静态变量 memory 分配的 20M 内存被回收；

4. 但是作为 GCRoot 的静态变量 staticVariable 不会被回收，所以最终打印结果少了 40M 内存。

3.验证活跃线程作为GCRoot

public class GCRootThread {

    private int _10M = 10 * 1024 * 1024;
    private byte[] memory = new byte[8 * _10M];

    public static void main(String[] args) throws InterruptedException {
        System.out.println("程序开始：");
        printMemory();
        AsyncTask asyncTask = new AsyncTask(new GCRootThread());
        Thread thread = new Thread(asyncTask);
        thread.start();
        System.gc();
        System.out.println("main方法执行完成，执行gc");
        printMemory();
        thread.join();
        asyncTask = null;
        System.gc();
        System.out.println("线程代码执行完成，执行gc");
        printMemory();
    }

    private static void printMemory() {
        long freeMemory = Runtime.getRuntime().freeMemory();
        long totalMemory = Runtime.getRuntime().totalMemory();
        System.out.println("剩余内存：" + freeMemory / 1024 / 1024 + "M");
        System.out.println("总共内存：" + totalMemory / 1024 / 1024 + "M");
    }

    private static class AsyncTask implements Runnable {

        private GCRootThread gcRootThread;

        public AsyncTask(GCRootThread gcRootThread) {
            this.gcRootThread = gcRootThread;
        }

        @Override
        public void run() {
            try {
                Thread.sleep(500);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}
打印结果：
程序开始：
剩余内存：119M
总共内存：123M
main方法执行完成，执行gc
剩余内存：41M
总共内存：123M
线程代码执行完成，执行gc
剩余内存：120M
总共内存：123M

通过上述打印结果可知：

1. 程序刚开始时可用内存为 119M；

2. 第一次调用 gc 时，线程并没有执行结束，并且它作为 GCRoot ,所以它所引用的 80M 内存不会被 GC 回收掉；

3. thread.join() 保证线程结束后再调用后续代码，所以当第二次调用 GC 时，线程已经执行完毕并被置为 null；

4. 这时线程已经销毁，所以该线程所引用的 80M 内存被 GC 回收掉。

4.测试成员变量是否可作为GCRoot

public class GCRootClassVariable {
    private static int _10M = 10 * 1024 * 1024;
    private byte[] memory;
    private GCRootClassVariable gcRootClassVariable;

    public GCRootClassVariable(int size) {
        memory = new byte[size];
    }

    public static void main(String[] args) {
        System.out.println("程序开始：");
        printMemory();
        GCRootClassVariable g = new GCRootClassVariable(2 * _10M);
        g.gcRootClassVariable = new GCRootClassVariable(4 * _10M);
        g = null;
        System.gc();
        System.out.println("GC完成");
        printMemory();
    }

    private static void printMemory() {
        long freeMemory = Runtime.getRuntime().freeMemory();
        long totalMemory = Runtime.getRuntime().totalMemory();
        System.out.println("剩余内存：" + freeMemory / 1024 / 1024 + "M");
        System.out.println("总共内存：" + totalMemory / 1024 / 1024 + "M");
    }
}
打印结果：
程序开始：
剩余内存：119M
总共内存：123M
GC完成
剩余内存：121M
总共内存：123M

上述打印结果可知：

1. 第一次打印结果与第二次打印结果一致：全局变量 gcRootClassVariable 随着 g=null 后被销毁。

2. 所以全局变量并不能作为 GCRoot。

五、如何回收垃圾（常见的几种垃圾回收算法）

1.标记清除算法（Mark and Sweep GC）

从 “GCRoots” 集合开始，将内存整个遍历一次，保留所有可以被 GCRoots 直接或间接引用到的对象，而剩下的对象都当做垃圾对待并回收。

上述整个过程分为两步：

1. Mark标记阶段：找到内存中的所有 GC Root 对象，只要是和 GC Root 对象直接或间接相连则标记为灰色（存活对象），否则标记为黑色（垃圾对象）。

2. Sweep清楚阶段：当遍历完所有的 GC Root 之后，则将标记为垃圾的对象直接清楚。

标记清除算法优缺点

【优点】

实现简单，不需要将对象进行移动。

【缺点】

需要中断进程内其他组件的执行，并且可能产生内存碎片，提高了垃圾回收的频率。

2.复制算法（Copying）

1. 将现有的内存空间分为两块，每次只使用其中一块；

2. 在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中；

3. 之后清除正在使用的内存块中的所有对象；

4. 交换两个内存的角色，完成垃圾回收（目前使用A，B是空闲，算法完成后A为空闲，设置B为使用状态）。

复制算法优缺点

【优点】

按顺序分配内存即可；实现简单、运行高效，不用考虑内存碎片问题。

【缺点】

可用的内存大小缩小为原来的一半，对象存活率高时会频繁进行复制。

3.标记压缩算法（Mark-Compact）

1. 需要先从根节点开始对所有可达对象做一次标记；

2. 之后并不简单地清理未标记的对象，而是将所有的存活对象压缩到内存的一端；

3. 最后清理边界外所有的空间。

所有，标记压缩也分为两步完成：

1. Mark标记阶段：找到内存中的所有 GC Root 对象，只要和 GC Root 对象直接或间接相连则标记为灰色（存活对象），否则标记为黑色（垃圾对象）

2. Compact压缩阶段：将剩余存活对象按顺序压缩到内存的某一端

标记压缩算法优缺点

【优点】

避免了碎片产生，又不需要两块相同的内存空间，性价比较高。

【缺点】

所谓压缩操作，仍需要进行局部对象移动，一定程度上还是降低了效率。

分代回收策略

Java 虚拟机根据对象存活的周期不同，把堆内存划分为 新生代、老年代，这就是 JVM 的内存分代策略。

注意：在 HotSpot 中除了 新生代 和 老年代，还有 永久代。

分代回收的中心思想：对于新创建的对象会在新生代中分配内存，此区域的对象生命周期一般较短，如果经过多次回收仍然存活下来，则将它们转移到老年代中。

一、年轻代

新生成的对象优先存放在新生代中，存活率很低。

新生代中，常规应用进行一次垃圾收集一般可以回收 70% ~ 95% 的空间，回收效率很高。所以一般采用的 GC 回收算法是 复制算法。

新生代也可细分3部分：Eden、Survivor0(简称 S0)、Survivor1(简称 S1)，这 3 部分按照 8:1:1 的比例来划分新生代。

新生成的对象会存放在 Eden 区。

当 Eden 区满时，会触发垃圾回收，回收掉垃圾之后，将剩下存活的对象存放到 S0 区。当下一次 Eden 区满时，再次触发垃圾回收，这时会将 Eden 区 和 S0 区存活的对象全部复制到 S1 区，并清空 Eden 区和 S0 区。

上述步骤重复 15 次之后，依然存活下来的对象存放到 老年区。

二、老年代

一个对象如果在新生代存活了足够长的时间而没有被清理掉，则会被复制到老年代。

老年代的内存大小一般比新生代大，能存放更多的对象。如果对象比较大（比如长字符串或大数组），并且新生代的剩余空间不足，则这个大对象会直接被分配到老年代上。

可以使用 -XX:PretenureSizeThreshold 来控制直接升入老年代的对象大小。

因为老年代对象的生命周期较长，不需要过多的复制操作，所以一般采用标记压缩的回收算法。

【注意的是】

有这么一种情况，老年代中的对象会引用新生代中的对象，这时如果要执行新生代的 GC，则可能要查询整个老年代引用新生代的情况，这种效率是极低的。所以老年代中维护了一个 512byte 的 table，所有老年代对象引用新生代对象的引用都记录在这里。这样新生代 GC 时只需要查询这个表即可。

三、GC log分析

为了让上层应用开发人员更加方便调试 Java 程序，JVM 提供了相应的 GC 日志，在 GC 执行垃圾回收事件中，会有各种相应的 log 被打印出来。

新生代和老年代打印的日志是有区别的：

【新生代GC：轻GC】这一区域的 GC 叫做 Minor GC。因为 Java 对象大多都具备朝生夕灭的特性，所以 Minor GC 非常频繁，一般回收速度比较快。

【老年代GC：重GC】发生在这一区域的 GC 叫做 Major GC 或者 Full GC，当出现 Major GC，经常会伴随至少一次 Minor GC。

Major GC 和 Full GC 在有些虚拟机中还是有区别的：前者是仅回收老年代中的垃圾对象，后者是回收整个堆中的垃圾对象。

常用的 GC 命令参数

添加 VM Options 参数：分配堆内存 20M，10M给新生代，10M给老年代

// VM args: -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8
public class MinorGCTest {

    private static final int _1M = 1024 * 1024;

    public static void main(String[] args) {
        byte[] a, b, c, d;
        a = new byte[2 * _1M];
        b = new byte[2 * _1M];
        c = new byte[2 * _1M];
        d = new byte[_1M];
    }
}
打印结果：（这里测试是第二次修改后的运行效果）
[GC (Allocation Failure) [PSYoungGen: 7820K->840K(9216K)] 7820K->6992K(19456K), 0.0072302 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 
[Full GC (Ergonomics) [PSYoungGen: 840K->0K(9216K)] [ParOldGen: 6152K->6759K(10240K)] 6992K->6759K(19456K), [Metaspace: 3198K->3198K(1056768K)], 0.0087734 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
Heap
 PSYoungGen      total 9216K, used 1190K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
  eden space 8192K, 14% used [0x00000000ff600000,0x00000000ff7298d8,0x00000000ffe00000)
  from space 1024K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x00000000fff00000)
  to   space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000)
 ParOldGen       total 10240K, used 6759K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
  object space 10240K, 66% used [0x00000000fec00000,0x00000000ff299cd0,0x00000000ff600000)
 Metaspace       used 3205K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 351K, capacity 388K, committed 512K, reserved 1048576K

上述字段意思代表如下：

1. 第一次运行效果后，因为 Eden 区 8M，S0 和 S1 各 1M。所以 a、b、c、d 共有 7M 空间都会在 Eden 区。

2. 修改 d = new byte[2 * _1M]，再次运行；

3. JVM 会将 a/b/c 存放到 Eden 区，Eden 占有 6M 空间，无法再分配 2M 空间给 d；

4. 因此会执行一次轻 GC，并尝试将 a/b/c 复制到 S1 区；

5. 但是因为 S1 区只有 1M 空间，所以没办法存储 a/b/c 三者任一对象。

6. 这种情况下，JVM 将 a/b/c 转移到老年代，将 d 保存在 Eden 区。

【最终结果】

Eden区 占用 2M 空间（d），老年代占用 6M 空间（a,b,c）

四、引用

通过 GC Roots 的引用可达性来判断对象是否存活，JVM 中的引入关系有以下四种：

软引用的用法

public class SoftReferenceNormal {

    static class SoftObject {
        byte[] data = new byte[120 * 1024 * 1024]; // 120M
    }

    public static void main(String[] args) {
        SoftReference<SoftObject> softObj = new SoftReference<>(new SoftObject());
        System.out.println("第一次GC前，软引用：" + softObj.get());
        System.gc();
        System.out.println("第一次GC后，软引用：" + softObj.get());
        SoftObject obj = new SoftObject();
        System.out.println("分配100M强引用，软引用：" + softObj.get());
    }
}

添加 VM Option 参数：-Xmx200M 给堆内存分配最大200M内存

第一次 GC 前，软引用：SoftReferenceNormal$SoftObject@1b6d3586
第一次 GC 后，软引用：SoftReferenceNormal$SoftObject@1b6d3586
分配 100M 强引用，软引用：null

1. 添加参数后位堆内存分配最大 200M 空间，分配给 softObj 对象 120M。

2. 第一次 GC 后，因为剩余内存任然够，所以软引用并没有被回收。

3. 当分配 100M 强引用后，堆内存空间不够，会触发GC回收，回收掉软引用。

软引用隐藏的问题

【注意】

被软引用对象关联的对象会自动被垃圾回收器回收，但是软引用对象本身也是一个对象，这些创建的软引用并不会自动被垃圾回收器回收掉。

public class SoftReferenceTest {

    static class SoftObject {
        byte[] data = new byte[1024]; // 占用1k空间
    }

    private static final int _100K = 100 * 1024;
    // 静态集合保存软引用，会导致这些软引用对象本身无法被垃圾回收器回收
    private static Set<SoftReference<SoftObject>> cache = new HashSet<>(_100K);

    public static void main(String[] args) {
        for (int i = 0; i < _100K; i++) {
            SoftObject obj = new SoftObject();
            cache.add(new SoftReference(obj));
            if (i * 10000 == 0) {
                System.out.println("cache size is " + cache.size());
            }
        }
        System.out.println("END");
    }
}

添加 VM Option 参数：-Xms4m -Xmx4m -Xmn2m

// 打印结果：
cache size is 1
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
    at SoftReferenceTest$SoftObject.<init>(SoftReferenceTest.java:8)
    at SoftReferenceTest.main(SoftReferenceTest.java:17)

程序崩溃，崩溃的原因并不是堆内存溢出，而是超出了 GC 开销限制。

这里错误的原因是：JVM 不停的回收软引用中的对象，回收次数过快，回收内存较小，占用资源过高了。

【解决方案】注册一个引用队列，将这个对象从 Set 中移除掉。

public class SoftReferenceTest {

    static class SoftObject {
        byte[] data = new byte[1024]; // 占用1k空间
    }

    private static final int _100K = 100 * 1024;
    // 静态集合保存软引用，会导致这些软引用对象本身无法被垃圾回收器回收
    private static Set<SoftReference<SoftObject>> cache = new HashSet<>(_100K);
    // 解决方案：注册一个引用队列，将要移除的对象从中删除
    private static ReferenceQueue<SoftObject> queue = new ReferenceQueue<>();
    // 记录清空次数
    private static int removeReferenceIndex = 0;

    public static void main(String[] args) {
        for (int i = 0; i < _100K; i++) {
            SoftObject obj = new SoftObject();
            cache.add(new SoftReference(obj, queue));
            // 清除掉软引用
            removeSoft();
            if (i * 10000 == 0) {
                System.out.println("cache size is " + cache.size());
            }
        }
        System.out.println("END removeReferenceIndex: " + removeReferenceIndex);
    }

    private static void removeSoft() {
        Reference<? extends SoftObject> poll = queue.poll();
        while (poll != null) {
            if (cache.remove(poll)) {
                removeReferenceIndex++;
            }
            poll = queue.poll();
        }
    }
}

// 打印结果：
cache size is 1
END removeReferenceIndex: 101745

作者：沅兮
来源：https://juejin.cn/post/7037330678731505672

直接调用就能收起键盘，无需调用其他方法    

    UIApplication.shared.sendAction(#selector(UIResponder.resignFirstResponder), to: nil, from: nil, for: nil)

iOS 底层原理探索 之 alloc

写在前面： iOS底层原理探究是本人在平时的开发和学习中不断积累的一段进阶之

路的。 记录我的不断探索之旅，希望能有帮助到各位读者朋友。

    SMPerson *p1 = [SMPerson alloc];

    SMPerson *p2 = [p1 init];

    SMPerson *p3 = [p1 init];

    

    NSLog(@"%@-%p-%p", p1, p1, &p1);

    NSLog(@"%@-%p-%p", p2, p2, &p2);

    NSLog(@"%@-%p-%p", p3, p3, &p3);

    <SMPerson: 0x600000710400>-0x600000710400-0x7ffee6f15088

    <SMPerson: 0x600000710400>-0x600000710400-0x7ffee6f15080

    <SMPerson: 0x600000710400>-0x600000710400-0x7ffee6f15078

    // 计算出开辟内存空间大小

    size = cls->instanceSize(extraBytes);

static inline size_t align16(size_t x) {

    return (x + size_t(15)) & ~size_t(15);

}

    (8 + 15) & ~15;

    

    0000 0000 0000 1000     8

    0000 0000 0000 1111     15  

    

=   0000 0000 0001 0111     23

    1111 1111 1111 0000     ~15

    

=   0000 0000 0001 0000     16

    ///向系统申请开辟内存空间，返回地址指针；

    obj = (id)calloc(1, size);

    /// 将类和指针做绑定

    obj->initInstanceIsa(cls, hasCxxDtor);

背景

iOS 业界研发模式多为 CocoaPods + Xcode + Git 的多仓组件化开发模型。为追求极致的研发体验、提升研发效率，对该研发模式进行了大量优化，但目前遇到了以下瓶颈，亟需突破：

• pod install 时间长：编译优化绝大部分任务放在了 CocoaPods 上，CocoaPods 承担了更多工作，执行时间因此变长。

• 编译时间长：虽然现阶段绝大部分工程已经从源码编译转型成二进制编译，但编译耗时依旧在十分钟左右，且现有工程基础上已无更好优化手段。

• 超大型工程通病：Xcode Index 慢、爆内存、甚至卡死，链接时间长。

如何处理这些问题？

究其本质，产生这些问题的原因在于工程规模庞大。据此我们停下了对传统模式各节点的优化工作，以"缩小工程规模"为切入点，探索新型研发模式——动态研发模式 ARK。

ARK[1] 是全链路覆盖的动态研发模式，旨在保证工程体验的前提下缩小工程规模：通过基线构建的方式，提供线下研发所需物料；同时通过实时的动态库转化技术，保证本地研发仅需下载和编译开发仓库。

Show Case

动态研发模式本地研发流程图如下。接下来就以抖音产品为例，阐述如何使用 ARK 做一次本地开发。
演示基于字节跳动本地研发工具 MBox[2] 。

1. 仓库下载

ARK 研发模式下，本地研发不再拉取主仓代码，取而代之的是 ARK 仓库。ARK 仓库含有与主仓对应的所有配置，一次适配接入后期不需要持续维护。

相较传统 APP 仓库动辄几个 GB 的大小，ARK 仓库贯彻了缩减代码规模这一概念。仓库仅有应用配置信息，不包含任何组件代码。ARK 仓库大小仅 2 MB，在 1 s 内可以完成仓库下载 。

在 MBox 中的使用仅需几步点击操作。首先选择要开发的产品，然后勾选 ark 模式，选择开发分支，最后点击 Create 便可以数秒完成仓库下载。

1. 开发组件

CocoaPods 下进行组件开发一般是将组件仓库下载到本地，修改 Podfile 对应组件 A 为本地引用 pod A, :path =>'./A' ，之后进行本地开发。而在 MBox 和 ARK 的研发流程中，仅需选择要开发的组件点击 Add 便可进行本地开发。

动态研发模式 ARK 通过解析 Podfile.lock 支持了 Checkout From Commit 功能，该功能根据宿主的组件依赖信息自动拉取相应的组件版本到本地，带来便捷性的同时也保证了编译成功率。

1. pod install

传统研发模式下 pod install 必须要经历 解析 Podfile 依赖、下载依赖、创建 Pods.xcodeproj 工程、集成 workspace 四个步骤，其中依赖解析和下载依赖两个步骤尤为耗时。

ARK 研发模式下 Podfile 中没有组件，因此依赖解析、下载依赖这两个环节耗时几乎为零。其次由于工程中仅需开发组件步骤中添加的组件，在创建 Pods 工程、集成工程这两个环节中代码规模的降低，对提升集成速度的效果非常显著。

没有依赖信息，编译、链接阶段显然不能成功。ARK 解决方案通过自研 cocoapods-ark 及配套工具链来保证编译、链接、运行的成功，其原理后续会在系列文章中介绍。

1. 开发组件编译&调试

和传统模式一样通过 Xcode 打开工程的 xcworkspace ，即可正常开发、调试完整的应用。

工程中仅保留开发组件，但是依然有变量、函数、头文件跳转能力；参与 Index、编译的规模变小，Xcode 几乎不存在 loading 状态，大型工程也可以秒开；编译速度大幅提升。在整个动态研发流程中，通过工具链将组件从静态库转化成动态库，链接时间明显缩短。

1. 查看全源码

ARK 工程下默认只有开发组件的源码，查看全源码是开发中的刚需。动态研发流程提供了 pod doc 异步命令实现该能力，此命令可以在开发时执行，命令执行完成后重启工程即可通过 Document Target 查看工程中其他组件源码。

pod doc 优点：

• 支持异步和同步，执行过程中不影响本地开发。

• 执行指令时跳过依赖解析环节，从服务端获取依赖信息，下载源码。

• 通过 xcodegen 异步生成 Document 工程，大幅降低 pod install 时间。

• 仅复用 pod installer 中的资源下载、缓存模块。

• 支持仓库统一鉴权，自动跳过无权限组件仓库。
  

收益

体验上： 与传统模式开发流程一致，零成本切换动态研发模式。

工具上： 站在巨人的肩膀上，CocoaPods 工具链相关优化在 ARK 同样生效。

时间上： 传统研发模式中，历经各项优化后虽然能将全链路开发时间控制在 20 分钟左右，但这样的研发体验依旧不够友好。开发非常容易在这个时间间隔内被其他事情打断，良好的研发体验应该是连贯的。结合本地开发体验我们认为，一次连贯的开发体验应该将工程集成时间控制在分钟级，当前研发模式成功做到了这一点，将全链路开发时间控制在 5 分钟以内。

成功率： 成功率一直是研发效率中容易被忽视的一个指标。据不完全数据统计，集团内应用的本地全量编译成功率不足五成。一半的同学会在首次编译后执行重试。显然，对于工程新手来说就是噩梦，这意味着很长时间将在这一环节中浪费。而 ARK 从平台基线到本地工具链贯彻 Sandbox 的理念，整体上提高编译成功率。

写在最后

ARK 当前已经在字节跳动内部多业务落地使用。从初期技术方案的探索到实际落地应用，遇到了很多技术难点，也对研发模式有了新的思考。

相关技术文章将陆续分享，敬请期待。

扩展阅读

[1] ARK: https://github.com/kuperxu/KwaiTechnologyCommunication/blob/master/5.WWDC-ARK.pdf
[2] MBox: https://mp.weixin.qq.com/s/5_IlQPWnCug_f3SDrnImCw

作者：字节跳动终端技术——徐纪光
来源：https://blog.csdn.net/YZcoder/article/details/121374743

手把手带你，优化一个滚动时流畅的TableView

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {

    

    ImageTableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"cell"];

    cell.index = indexPath;

    

    NSMutableDictionary *info = [self.dataSource objectAtIndex:cell.index.row];



    NSString *url = [info objectForKey: @"img" ];

    NSData *iData = [NSData dataWithContentsOfURL:[NSURL URLWithString: url ]];

    cell.img.image = [UIImage imageWithData:iData];

    cell.typeL.text = [NSString stringWithFormat:@"%ld-%ld", cell.index.section, cell.index.row];



    return cell;

}

#pragma mark load Images

- (void)loadSeeImage {



    //记录本次加载的几张图片

    NSInteger loadC = 0;

    

    // 用户可以看见的cells

    NSArray *cells = [self.imageTableView visibleCells];

    

    // 调度组

    dispatch_group_t group = dispatch_group_create();

    

    for (int i = 0; i < cells.count; i++) {

        

        ImageTableViewCell *cell = [cells objectAtIndex:i];

        

        NSMutableDictionary *info = [self.dataSource objectAtIndex:cell.index.row];

        NSString *url = [info objectForKey: @"img" ];

        

        NSString *data = [info objectForKey:@"data"];

        

        if ([data isKindOfClass:[NSData class]]) {

            

            

        }else {

            

            // 添加调度则到我们的串行队列中去

            dispatch_group_async(group, self.loadQueue, ^{

                

                NSData *iData = [NSData dataWithContentsOfURL:[NSURL URLWithString: url ]];

                NSLog(@" load image %ld-%ld ", cell.index.section, cell.index.row);

                if (iData) {

                // 缓存

                    [info setValue:@"1" forKey:@"isload"];

                    [info setValue:iData forKey:@"data"];

                }

                NSString *isload = [info objectForKey:@"isload"];

                

                if ([isload isEqualToString:@"0"]) {

                    

                    dispatch_async(dispatch_get_main_queue(), ^{



                        cell.img.image = [UIImage imageNamed:@""];

                    });                }else {

                    

                    if (iData) {

                      

                        dispatch_async(dispatch_get_main_queue(), ^{

                     //显示加载后的图片       

                            cell.img.image = [UIImage imageWithData:iData];

                        });

                    }

                }

                

            });

 

            if (i == cells.count - 1) {



                dispatch_group_notify(group, dispatch_get_main_queue(), ^{

                    // 全部加载完毕的通知

                    NSLog(@"load finished");

                });

            }

            

            loadC += 1;

        }

    }

  

    NSLog(@"本次加载了 %ld 张图片", loadC);

}

- (void)scrollViewDidEndDecelerating:(UIScrollView *)scrollView   {  

    

    [self loadSeeImage];

}



- (void)scrollViewDidEndDragging:(UIScrollView *)scrollView willDecelerate:(BOOL)decelerate {

    

    if (scrollView.isDragging || scrollView.isDecelerating || scrollView.isTracking) {

        return;

    }

    [self loadSeeImage];

}

最近元宇宙的概念火遍互联网，自 Facebook 改名 Meta 以来，国内外越来越多的企业纷纷加入到布局元宇宙的行列。元宇宙之所以强势进入人们视野，与其底层技术的进步有着莫大的关系，包括AR/VR、云计算、物联网、5G、人工智能、数字孪生等等。其中，5G作为重要的连接基础，是元宇宙场景得以实现的关键。元宇宙将汇集游戏引擎、AR可穿戴设备、VR、现实世界数据集和不断发展的物联网。

物联网（英语：InternetofThings，简称 IoT）是一种计算设备、机器、数码机器之间相互联系的系统，它拥有一种统一的统一识别代码（UID），并且能够在网络上传送数据，不需要人与人、或人与设备之间的交互。

作为一个前端工程师（JavaScript工程师），似乎觉得这一切有点模式，其实不然，现代 JavaScript 的可以使用的场景越来越多，包括物联网，在本文中，将介绍可以在 JavaScript 代码中用于连接设备的 5 个脚本库。

1. Cylon.js

官方网站： https://cylonjs.com/

Cylon.js 是用于机器人、物理计算和物联网 (IoT) 的流行 JavaScript 框架之一。不仅仅是一个“物联网”库，它还是一个完整的机器人框架，支持超过 43 个不同的平台，这是与机器连接的 43 种不同的地方或方式，目前支持的机器人和物理计算系统及软件平台有Arduino、Beaglebone Black、BLE、Disispark、Intel Galileo and Edison、Intel IoT Analytics、OpenCV、Octobl、Raspberry Pi、Salesforce等。

可以使用 Cylon.js 连接到关键字并侦听它或 Arduino 板发送的事件，或者提供一个 HTTP API 接口并通过那里获取数据（它们也支持 socket.io 和 MQTT）。想通过 JavaScript 控制无人机吗？这并非不可以，首先需要安装：

npm install cylon cylon-firmata cylon-gpio cylon-i2c

然后运行一个这样的小脚本， 参考文章：

npm install cylon cylon-ardrone

然后运行脚本：

const Cylon = require("cylon");

Cylon.robot({
    connections: {
        ardrone: { adaptor: "ardrone", port: "192.168.1.1" },
    },

    devices: {
        drone: { driver: "ardrone" },
    },

    work: function (my) {
        my.drone.takeoff();
        after((10).seconds(), function () {
            my.drone.land();
        });
        after((15).seconds(), function () {
            my.drone.stop();
        });
    },
}).start();

如果有设备可以试试。 Cylon.js 的工作方式是允许其他人通过插件的方式提供连接器，这意味着这个库提供的功能没有限制。最重要的是，文档本身非常详细，写得很好，完整的代码示例。

2. IoT.js

官方网站： https://iotjs.net/

IoT.js 是一个用 JavaScript 编写的物联网 (IoT) 框架。它旨在基于网络技术在物联网世界中提供一个可互操作的服务平台。

如果希望在一个连接的设备中执行一些物联网（而不是在一个强大的、充满资源的服务器中的接收端），那么可能需要针对该环境进行优化。这个 IoT 框架运行在 JerryScript 引擎之上， JerryScript 引擎是一个针对小型设备优化的 JavaScript 运行时。这意味着，虽然无法使用最先进的 JS 的全部功能，但确实可以使用：

• 完全支持 ECMAScript 5.1 语法。

• 低内存消耗优化

• 能够将 JS 代码预编译为字节码

但是，兼容平台的数量没有 Cylon.js 多，而 IoT.js 只兼容：

关于他们的文档，这应该是衡量一个库有多好的标准之一。他们有一些基本的例子和入门指南。但可能就是这样了。考虑到 IoT.js 是一个底层的硬件接口，现在看起来它希望开发人员已经有使用其他产品的经验，而不是针对JS开发人员寻求进入物联网。

3. Johnny-Five

官方网站： http://johnny-five.io/

Johnny Five 是流行的 JavaScript 机器人和物联网平台之一。由 Bocoup 于 2012 年开发的 Johnny Five 一个开源的、基于 Firmata 协议的物联网和机器人编程框架，是 JavaScript 开发人员可用的最古老的机器人和物联网平台之一，从那时起，它的功能和兼容性都在不断增长。

Johnny Five 支持 Arduino（所有型号）、Electric Imp、Beagle Bone、Intel Galileo & Edison、Raspberry Pi 等。该平台可轻松与流行的应用程序库（如 Express.js 和 Socket.io）以及物联网框架（如 Octoblu）结合使用。

他们的文档非常详细，充满了关于硬件连接的示例和图表，这是一个很好的学习资源。

4. NodeRed

官方网站： https://nodered.org/

NodeRed 是建立在 Node.js 之上，是一个基于流的编程工具，最初由 IBM 的新兴技术服务团队开发，现在是 JS 基金会的一部分。该平台允许在部署之前从浏览器以图形方式设置数据流和工作流。在理想的情况下，不需要编写任何代码，也许设置一些平台凭据。 NodeRed 还充当和其他人共享他们创建的流程的中心化平台，这是防止每次都重新创建轮子的好方法，即使没有真正编写代码。

5. Zetta

官方网站： https://www.zettajs.org/

ZettaJS 是一个基于 Node.js 构建的开源平台，用于创建跨地理分布式计算机和云运行的物联网服务器。是另一种通过 JavaScript 与远程设备交互的方式。这里的主要区别在于 ZettaJS 的目标是将每个设备都变成一个 API，这是将 IoT 泛化为一个通用概念的好方法。如今，设备及其接口的数量正在爆炸增长，但没有对其进行规范控制。 ZettaJS 正试图在这方面进行改进，通过非常直观的编码方式，可以简单地为设备安装驱动程序，并在其中启用公共接口，并通过代码与它们交互。

6. 总结

通过上面介绍，JavaScript 不仅限于浏览器，甚至不限于基于 API 的后端开发，还可以随心所欲地从设备中提取数据或从设备中提取数据，并使用几乎完全相同的语言来控制它。

作者：天行无忌
来源：https://blog.51cto.com/devpoint/4762760

作者：LBJ
链接：https://juejin.cn/post/7036266588227502093

今天准备爬取某某点评店铺信息时，遇到了『字体』反爬。比如这样的：

还有这样的：

可以看到这些字体已经被加密（反爬）

竟然遇到这种情况，那辰哥就带大家如何去解决这类反爬（字体反爬类）

01 网页分析

在开始分析反爬之前，先简单的介绍一下背景（爬取的网页）

辰哥爬取的某某点评的店铺信息。一开始查看网页源码是这样的

这种什么也看不到，咱们换另一种方式：通过程序直接把整个网页源代码保存下来

获取到的网页源码如下：

比如这里看到评论数（4位数）都有对应着一个编号（相同的数字编号相同），应该是对应着网站的字体库。

下一步，我们需要找到这个网站的字体库。

02 获取字体库

这里的字体库建议在目标网站里面去获取，因为不同的网站的字体库是不一样，导致解码还原的字体也会不一样。

1、抓包获取字体库

在浏览器network里面可以看到一共有三种字体库。（三种字体库各有不同的妙用，后面会有解释）

把字体库链接复制在浏览器里面打开，就可以把字体库下载到本地。

2、查看字体库

这里使用FontCreator的工具查看字体库。

下载地址：

https://www.high-logic.com/font-editor/fontcreator/download

这里需要注册，邮箱验证才能下载，不过辰哥已经下载了，可以在公众号回复：FC，获取安装包。

安装之后，把刚刚下载的字体库在FontCreator中打开

可以看到字体的内容以及对应的编号。

比如数字7对应F399、数字8对应F572 ，咱们在原网页和源码对比，是否如此？？？

可以看到，真是一模一样对应着解码就可以还原字体。

3、为什么会有三个字体库

在查看加密字体的CSS样式时，方式有css内容是这样的

字体库1：d35c3812.woff 对应解码class为 shopNum

字体库2：084c9fff.woff 对应解码class为 reviewTag和address

字体库3：73f5e6f3.woff 对应解码class为 tagName

也就是说，字体所属的不同class标签，对应的解密字体库是不一样的，辰哥这里不得不说一句：太鸡贼了

咱们这里获取的评论数，clas为shopNum，需要用到字体库d35c3812.woff

03 代码实现解密

1、加载字体库

既然我们已经知道了字体反爬的原理，那么我们就可以开始编程实现解密还原。

加载字体库的Python库包是：fontTools ，安装命令如下：

pip install fontTools

将字体库的内容对应关系保存为xml格式

code和name是一一对应关系

可以看到网页源码中的编号后四位对应着字体库的编号。

因此我们可以建立应该字体对应集合

建立好映射关系好，到网页源码中去进行替换

这样我们就成功的将字体反爬处理完毕。后面提取内容大家基本都没问题。

2、完整代码

输出结果：

可以看到加密的数字全部都还原了。

04 小结

辰哥在本文中主要讲解了如此处理字体反爬问题，并以某某点评为例去实战演示分析。辰哥在文中处理的数字类型，大家可以尝试去试试中文如何解决。

作者：Python研究者
来源：https://juejin.cn/post/6970933428145356831

先看效果图

实现原理

借助宽高等比例放大的两张图片，结合js中鼠标偏移量、元素偏移量、元素自身宽高等属性完成；左侧遮罩移动Xpx,右侧大图移动X*倍数px；其余部分就是用小学数学算一下就OK了。

HTML和CSS

 <div class="wrap">
    
    <div id="small">
      <img src="img/1.jpg" alt="" >
      <div id="mark">div>
    div>
    
    <div id="big">
      <img src="img/2.jpg" alt="" id="bigimg">
    div>
  div>
  * {
      margin: 0;
      padding: 0;
    }
    .wrap {
      width: 1500px;
      margin: 100px auto;
    }

    #small {
      width: 432px;
      height: 768px;
      float: left;
      position: relative;
    }

    #big {
      /* background-color: seagreen; */
      width: 768px;
      height: 768px;
      float: left;
      /* 超出取景框的部分隐藏 */
      overflow: hidden;
      margin-left: 20px;
      position: relative;
      display: none;
    }

    #bigimg {
      /* width: 864px; */
      position: absolute;
      left: 0;
      top: 0;
    }

    #mark {
      width: 220px;
      height: 220px;
      background-color: #fff;
      opacity: .5;
      position: absolute;
      left: 0;
      top: 0;
      /* 鼠标箭头样式 */
      cursor: move;
      display: none;
    }

JS

 // 获取小图和遮罩、大图、大盒子
    var small = document.getElementById("small")
    var mark = document.getElementById("mark")
    var big = document.getElementById("big")
    var bigimg = document.getElementById("bigimg")
    // 在小图区域内获取鼠标移动事件;遮罩跟随鼠标移动
    small.onmousemove = function (e) {
      // 得到遮罩相对于小图的偏移量(鼠标所在坐标-小图相对于body的偏移-遮罩本身宽度或高度的一半)
      var s_left = e.pageX - mark.offsetWidth / 2 - small.offsetLeft
      var s_top = e.pageY - mark.offsetHeight / 2 - small.offsetTop
      // 遮罩仅可以在小图内移动，所以需要计算遮罩偏移量的临界值（相对于小图的值）
      var max_left = small.offsetWidth - mark.offsetWidth;
      var max_top = small.offsetHeight - mark.offsetHeight;
      // 遮罩移动右侧大图也跟随移动（遮罩每移动1px，图片需要向相反对的方向移动n倍的距离）
      var n = big.offsetWidth / mark.offsetWidth
      // 遮罩跟随鼠标移动前判断：遮罩相对于小图的偏移量不能超出范围，超出范围要重新赋值（临界值在上边已经计算完成：max_left和max_top）
      // 判断水平边界
      if (s_left < 0) {
        s_left = 0
      } else if (s_left > max_left) {
        s_left = max_left
      }
      //判断垂直边界
      if (s_top < 0) {
        s_top = 0
      } else if (s_top > max_top) {
        s_top = max_top
      }
      // 给遮罩left和top赋值（动态的？因为e.pageX和e.pageY为变化的量），动起来！
      mark.style.left = s_left + "px";
      mark.style.top = s_top + "px";
      // 计算大图移动的距离
      var levelx = -n * s_left;
      var verticaly = -n * s_top;
      // 让图片动起来
      bigimg.style.left = levelx + "px";
      bigimg.style.top = verticaly + "px";
    }
    // 鼠标移入小图内才会显示遮罩和跟随移动样式，移出小图后消失
    small.onmouseenter = function () {
      mark.style.display = "block"
      big.style.display= "block"
    }
    small.onmouseleave = function () {
      mark.style.display = "none"
      big.style.display= "none"
    }

总结

• 鼠标焦点一旦动起来，它的偏移量就是动态的；父元素和子元素加上定位后，通过动态改变某个元素的left和top值来实现“动”的效果。

• 大图/小图=放大镜（遮罩）/取景框

• 两张图片一定要等比例缩放

作者：Onion韩
来源：https://juejin.cn/post/7030963292818374670

网上很流行的一行代码，据说是谷歌工程师写的，它的作用是给页面所有元素增加一个随机颜色的外边框。

[].forEach.call($$("*"),function(a){a.style.outline="1px solid #"+(~~(Math.random()*(1<<24))).toString(16)})

运行效果如下图：

这个代码虽然只有一行，但是包含的知识点不少，网上有很多解析。我也说下自己的理解，然后最后推荐在实务中使用TreeWalker对象进行遍历。

我的理解其中主要包含如下4个知识点：

1. [].forEach.call
2. $$("*")
3. a.style.outline
4. (~~(Math.random()*(1<<24))).toString(16)

1 [].forEach.call

1.1 [].forEach

forEach是数组遍历的一个方法，接收一个函数参数用来处理每一个遍历的元素，常规的使用姿势是：

let arr = [3, 5, 8];
arr.forEach((item) => {
    console.log(item);
})
// 控制台输出：
//  3
//  5
//  8