之前的博客中，已经介绍了图像拼接主要可以分为4个阶段：特征提取、特征匹配、图像配准、图像融合，其中特征提取阶段有SURF、SIFT、ORB、Harris等算法。于是我写了一个Web系统，用于使用不同的特征提取算法进行图像拼接，并且比较之间的效率和质量。

项目为前后端分离项目，前端代码仓库地址：https://github.com/bodhisatan/stitch-frontend ；后端代码仓库地址：https://github.com/bodhisatan/stitch-backend

系统设计

算法选取

在图像拼接领域中，主要流行的有三种特征提取算法：SIFT、SURF、ORB，这三种都在OpenCV里有实现（SURF因为专利原因已经从OpenCV里下掉），SURF是SIFT的加强版，运算效率比SIFT高一个数量级，ORB基于FAST，运算效率比SIFT高两个数量级，但是鲁棒性不及SIFT和SURF。因此在算法的选取上，选择了OpenCV已经实现的SIFT和ORB，在运算效率和鲁棒性方面都有明显的比较。除此之外，我自己也实现了一个Harris方案，Harris是一种角点匹配方法，对尺度很敏感，不具有尺度不变性，需要先将图片转为灰度图再进行运算。

比较参数选取

对于算法的比较，主要从三方面考虑：

• 待拼接图像的相似度（前置条件角度）
• 输出图像的质量（输出质量角度）
• 运行时间（运行效率角度）

  输入图像相似度

  有些特征提取、匹配算法要求待匹配图像相似度较高，于是我记录了相似度参数。相似度采用两方面指标：
• 三通道直方图相似度: 比较常见的衡量相似度的指标，先得到图像像素值的直方图，再计算直方图的相似度，这种计算方案有个缺陷，它仅反映图像像素值的数量，不能反映图像纹理结构，很明显该方法存在很多误判，比如纹理结构相同，但明暗不同的图像，应该相似度很高，但实际结果是相似度很低，而纹理结构不同，但明暗相近的图像，相似度却很高。
• SSIM: 为了弥补直方图相似度的缺陷，我又采取了SSIM指标。SSIM是结构化相似度，是一种全参考的图像质量评价指标，它分别从亮度、对比度、结构三方面度量图像相似性，能够弥补直方图相似度误判的缺陷。（在之前的博文中也有详细介绍）

输出图像质量

拼接的输出图像的品质，一般从有没有裂缝、有没有鬼影、有没有正确拼接等角度，但没有一个具体客观的指标。我看了相关的论文之后，发现有一篇论文通过PSNR指标作为输出图像质量的参考。

PSNR(Peak Signal to Noise Ratio): 峰值信噪比，主要是为了衡量经过处理后的影像品质，PSNR指标越高，代表输出图像的失真越少，质量越高

其中，MAXI是表示图像点颜色的最大数值，如果每个采样点用 8 位表示，那么就是 255。

运行时间

运行时间记录两个时间：

• 特征提取阶段运算耗时（主要比较的算法耗时）
• 图像拼接运算总耗时

系统实现

技术选型

前端采用Vue.js和webpack技术实现前后端分离，组件采用elementUI和ECharts，与后端通信采用axios，后端框架从易用性角度考虑采用Flask，数据库从方便扩展的角度考虑采用MongoDB

实现结果

基于成品app的包体积监控

所谓基于成品app，也就是app提测甚至是发版之后，对于app的包体积进行监控。这种比较适用于竞品包体积比对这方面。包体积又分为两种，一种是下载大小，一种是安装大小。

下载大小

下载大小，也就是用户在应用商店看到的app大小。这个会影响用户的下载意愿，但是，我们在页面上看到的下载大小到底是什么？为什么不同手机不同系统看到的下载大小不一样？

对于iOS来说，app的下载大小是：

1. .app 文件（.app也就是.ipa解压之后的产物）
2. 的二进制部分被加壳后
3. 再经过 app slicing的结果

加壳对app包体积有影响，但影响不大，关键在于瘦身这一步。我们在给iOS app打包的时候可以通过指定瘦身的版本来模拟app slicing的效果得到数据。

对于Android来说，如果经过了app bundle，那就类似于iOS的app slicing，对于这种的话，可以通过UI自动化，解析应用商店的下载页面获取下载大小。

安装大小

安装大小，就是app解压安装到手机上后占据磁盘的空间。对于iOS来说，可以粗略的认为，ipa解压后的.app文件，大小近似于安装大小。对于Android来说，可以通过在手机里捞取安装包的方式获取安装大小。apk的安装流程如下：

1. 复制APK到/data/app目录下，解压并扫描安装包。
2. 资源管理器解析APK里的资源文件。
3. 解析AndroidManifest文件，并在/data/data/目录下创建对应的应用数据目录。
4. 然后对dex文件进行优化，并保存在dalvik-cache目录下。
5. 将AndroidManifest文件解析出的四大组件信息注册到PackageManagerService中。
6. 安装完成后，发送广播

那么，就可以通过root手机，访问/data/app目录下的对应应用文件夹来获取安装大小。

基于代码提交的包体积监控

包大小前置检查，是包大小监控中一种重要方式，其做法是对合入代码所产生的包大小增量进行监控。如果采用定时对主分支打包做包大小检查或者提测的时候再做包检查，会产生一些bad case：

• case 1：在一次检查中我们发现了抖音包体积涨了1M多，能看到是有多个so文件大小变大了，但是不知道具体是由哪个业务线、哪个需求、哪个RD引入的，无法对症下药。
• case 2：某次提交中C同学引入了一些无用资源会造成包大小不必要的增加，但是代码合进去了才发现问题，后期要进行跟踪和优化都比较困难，C同学对包大小优化的意识也会弱化。
• case 3：在某个版本开发中，A同学做了直播模块的包大小压缩，优化了900KB，而B同学写了个需求使包大小增加了600KB，如果仅对主分支的包做检查，此类问题将不能暴露出来。

由此可见，在代码合入之后做检查，带来的问题是等到发现包大小增加超过预期时，回退代码或进行修复往往比较困难，后续的优化工作也没能支持。比较好的做法是，我们在每次代码合入前检查包体积的大小变化。选择在每个MR的粒度上对包大小变化进行监控，目的是更早、更快地发现和定位包大小增加/减少的引入源，同时能够关联到对应的业务线及代码提交者。

那么就引入了一个很重要的问题：如何选取基准包？

之前的博客里也提到过，我们组采取的方案是，rd合入代码进某分支之后，对这条分支进行打包，打包结果和这条分支的上一次打包结果做比较。这样简单粗暴的选取基准包测试结果不准，偶尔还会引起误报警。学习了抖音的监控方案之后，发现他们基准包节点是选取的当前提交分支与目标分支最近的一个公共节点，当监听到代码merge操作之后，会回溯找到这个基准包节点，如果该节点没打过包，则先打基准包再进行比较。

关于最近的一个公共节点，考虑两种case：一是从develop拉出分支feature/author_name/xxx进行开发，那么拉出来的那个commit节点就是它们最近的公共节点；二是如果在之后的开发中又merge了develop分支，则这个最近的公共节点变为merge时候develop分支上的commit节点。

附录：iOS对安装包大小的限制

苹果对于开发者提供的安装包存在2个方面的限制:

安装包大小限制：

• 安装包总大小限制：完整的.app文件未压缩情况下大小不得超过4GB
• 下载大小限制（OTA）：用户在 App Store 可以使用流量下载的大小为200MB

这个限制简称 OTA 限制 （Cellular Over-the-Air App Download Limit）主要是为了防止用户在下载应用程序时无意间使用大量数据 变更历史:

• 2019年6月1日， OTA 限制从150M提高到200M
• 2017年9月19日，OTA 限制从100M提高到150M
• 2013年9月18日，OTA 限制从50M提高到100M

  _TEXT段大小限制：

• 低于iOS 7 ：可执行文件所有架构_TEXT段总大小不得超过80M
• iOS 7.x 和iOS 8.X：可执行文件单架构_TEXT段大小不得超过60M
• iOS 9.x 以及更高版本：可执行文件所有架构_TEXT段总大小不得超过500M

（上边的限制均以 1000 为进位单位而不是 1024：1MB=1000KB）

iOS系统的两个口径：Download Size和Install Size

在前文说下载大小这一概念的时候，关于iOS的部分说的不是很精确，在这里补充说明一下。

在 itunes connect 后台，开发者可以看到当前版本针对不同机型的大小。

这里的大小分为两个口径： Download Size 和 Install Size。

根据网页上的说明： Install Size 是这个 app 安装后，会占用的磁盘大小； Download Size 是 app 经过压缩后的大小。

根据经验，用户在 app store 上看到的大小，就是 itunes connect 后台中显示的 Install Size。（注意：不是Download Size！！！）

而令开发者在意的，“超过 200 MB 的 app 必须连接至无线局域网才能下载”的规则中的 200 MB，指的其实是 Download Size。

所以与上文结合可以知道，.ipa文件解压之后的.app文件，大小和install size更为接近。

不会前端，即使你有想法有逻辑，还是不能实现出一个完整的产品出来，这次借着看组里自动化平台前端源码的机会，入门了一下vue.js，在写demo的时候，碰到了一个=>函数的写法，了解了一下之后发现它类似Java里的lambda表达式，但在js里也有一些细节需要注意，在此记录一下。

箭头函数的概念

JS的箭头函数（lambda表达式），其主要意图是定义轻量级的内联回调函数

• 回调函数：这个在之前的博文里写过
• 内联函数：函数调用的过程，是调用栈入栈出栈的过程，这是比较耗时的。内联（inline）也就是内嵌，也就意味着就像C语言#define一样，当编译器发现某段代码在调用一个内联函数时，它不是去调用该函数，而是将该函数的代码，整段内嵌到当前位置。这样做的好处是省去了调用的过程，加快程序运行速度，缺点就是会消耗空间。

1

x => x * x

上面的箭头函数相当于：

1
2
3

function (x) {
    return x * x;
}

不同场景箭头函数的用法

箭头函数简化了函数定义，相当于只需指定一个参数到结果的映射。箭头函数有两种格式，一种像上面的，只包含一个表达式，连{ … }和return都省略掉了。还有一种可以包含多条语句，这时候就不能省略{ … }和return：

1
2
3
4
5
6
7
8

x => {
    if (x > 0) {
        return x * x;
    }
    else {
        return - x * x;
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// 两个参数:
(x, y) => x * x + y * y

// 无参数:
() => 3.14

// 可变参数:
(x, y, ...rest) => {
    var i, sum = x + y;
    for (i=0; i<rest.length; i++) {
        sum += rest[i];
    }
    return sum;
}

如果要返回一个对象，因为和函数体的{ … }有语法冲突，所以要改为：

1

x => ({ foo: x })

JS中箭头函数与匿名函数的区别（this）

在之前讲闭包的博文中，也提到了匿名函数的概念，JS中箭头函数与匿名函数最大的区别是箭头函数内部的this是词法作用域（lexically scoped），由上下文确定。个人感觉这里的词法作用域，和闭包里引用环境的概念非常像。

在匿名函数里，由于JavaScript函数对this绑定的错误处理，下面的例子无法得到预期结果，需要用点hack的方法，比如let that = this：

1
2
3
4
5
6
7
8
9
10

var obj = {
    birth: 1990,
    getAge: function () {
        var b = this.birth; // 1990
        var fn = function () {
            return new Date().getFullYear() - this.birth; // this指向window或undefined
        };
        return fn();
    }
};

现在，箭头函数完全修复了this的指向，this总是指向词法作用域，也就是外层调用者obj：

1
2
3
4
5
6
7
8
9

var obj = {
    birth: 1990,
    getAge: function (year) {
        var b = this.birth; // 1990
        var fn = (y) => y - this.birth; // this.birth仍是1990
        return fn.call({birth:2000}, year);
    }
};
obj.getAge(2015); // 25

这一年发生了很多事，因为疫情原因在出租屋里吃了一个月的泡面，因为不返校而得以一直实习，先是在百度，然后是在字节，还认识了一个我坚定地觉得可以相伴一生的人。一年前的我只有后端开发的经验，对测试领域一无所知，误打误撞进了客户端测试的领域，并且一直做了下来，经历了很多，也算是有所思考和沉淀吧。下面就谈一谈我经过一年的工作，对于客户端自动化测试手段的思考。

UI自动化

UI自动化，这几乎是每一个客户端方向的测试工程师在学习或者团队内发展自动化测试的时候的第一个方向。大家提到自动化测试，一般而言，如果是客户端领域，指的就是UI自动化。在我刚入职百度的时候，我的方向就是双端的UI自动化。

什么是UI自动化

UI自动化，就是将用户的行为通过“自动化测试框架”进行模拟，例如模拟划动、模拟点击，将一些测试场景抽象出来进行自动化测试，以此达到节约人力的作用。目前市面上的自动化测试框架非常多，例如appium、totoro、QTA、uia、uia2等。一些大厂基于不同的侧重点也会进行自己的自动化框架的研发，比如携程基于行为驱动（BDD）的自动化测试，网易提出的用图片就能编写case的Airtest，腾讯从稳定性和多端支持角度提出的QTA等。不同的框架出发点不一样，有的是为了稳定性，有的是为了编写时上手的简单性，有的是为了可扩展性，但是框架的原理大同小异，可以认为一个完整的UI自动化框架一般由两部分组成：UI驱动和设备驱动。

UI驱动用来执行对元素的操作，比如查找元素、点击元素，设备驱动用来执行对设备的操作，比如冷启app、关机等。设备驱动的话安卓端的开源方案有adb，iOS端的开源方案有facebook的wda和idb，一些公司也会进行自己的设备驱动的开发，比如字节自研的BDC。UI驱动的话，主要思路有两种，一种是注入式，一种是非注入式。像上手最简单的Appium采用的就是非注入式方案，查找和操作UI是从App进程外对App进行操作的。非注入式的UI驱动有：安卓端的UIA，iOS端的Instrumentation、XCUITest等。腾讯的QTA和字节的Shoots采用的就是注入式方案，对app进行重打包，往包里注入一个server，在app启动的时候，启动一个对应的网络服务，通过这个网络服务提供测试接口。

因此，从UI驱动这个角度出发，可以将自动化框架分成两大类：注入式、非注入式，那么这两种各有什么优劣势呢？最大的不同点在于稳定性和性能：

• 稳定性：记得刚用Appium的时候，测试机是一台vivo低端机，case编写好之后运行的时候，稳定性非常差，首先是定位元素很慢（这和设备性能也有关系），然后是经常跑着跑着，从一个case开始，后面的全部case都失败了，然后查了日志才发现，vivo魔改OS，把耗电高的进程——也就是测试服务的进程给杀了。但是如果UI驱动是注入式的，那么测试服务和App本身就会“同生共死”，只要App进程不死，测试进程也不会死，同时注入式的UI驱动也会极大增大元素定位的速度
• 性能：因为测试服务是注入进App进程里的，所以或多或少都会影响App本身运行的速度，所以做性能评测时，要么保证框架对性能的影响有限，要么采用非注入式框架

UI自动化的用处

UI自动化不光光是UI自动化，可以以UI自动化为入手点，将客户端测试的很多方面通过自动化落地，比如埋点自动化测试、性能自动化测试等。

• 功能回归测试：这是UI自动化最基础的用途，因为一般新功能的话手工回归更稳妥，所以重复性高的回归case采用自动化测试更为合适，可以将功能回归测试放在持续集成流程里，每出一个新包/每监听到一个新push就执行一遍，保证新增代码不影响旧功能或者核心功能

• 埋点测试：埋点上报的本质是发送http请求，埋点测试也是进入到某个App场景后进行埋点数据校验，那么可以利用一些技术手段，劫持App发送的埋点数据，然后通过json schema进行自动化校验。json schema可以自己编写，也可以在录制case的时候进行生成

• 性能测试：有时候需要把自己产品的一些核心场景与竞品横向对比，做性能评测。性能主要有以下几个指标：耗时、cpu、fps等。如果不用自动化手段，需要手动录屏，然后手动拆帧获得耗时数据，安卓端通过adb命令获得cpu、fps等数据，iOS则更为复杂。用自动化可以实现自动录屏，自动分帧，自动选取开始帧结束帧计算耗时，还可以集成一些工具，自动获取cpu、fps等信息。

• 服务端接口防劣化：假如有这样一个场景——一个服务端接口因为种种原因挂了，导致线上功能异常或者页面白屏，此时一般只能通过用户反馈或者服务端报警才能知道接口出了问题，这个通过UI自动化也可以无人值守的监控：每隔一定时间跑一遍核心接口相关的UI自动化，同时用一些cv工具对页面进行白屏检测，那么如果出现问题，就能及时报警

UI自动化的挑战

UI自动化是否合理，在每一个测试团队推行UI自动化的时候都会遇到这样的争议。团队leader会觉得，自动化收益不明显、反而更耗费人力，业务测试peer会觉得，这是给自己工作增负，而且落地的好也只不过是给他人做嫁衣。这些矛盾的关键点在于：UI自动化能否真正给团队带来效益？

UI自动化其实难度很大，有一张很经典的三角形示意图，最底层面积最大的是Unit Test，cost最小，收益最大，最顶端面积最小的就是UI Test，cost最大，收益最小。做UI自动化，不光要求对框架的原理、app的代码都有所了解，还要求对产品和业务非常了解。不清楚自动化框架的原理，case出了问题无法排查。UI自动化本质上也算是一种白盒测试，不了解客户端的知识也很难下手，比如不清楚iOS的证书体系，就无法为app注入代码执行case，不了解安卓UI，就会不理解为什么QTA对UI层的抽象设计。假设这些都了解了，也需要很熟悉产品业务。例如哪些场景有ab test，ab test如何解决，如何尽量减少对线上数据的影响等。同时，如何让编写的case稳定性更好、维护性更好也很有学问，避免使用坐标点击、考虑不同分辨率设备的UI界面、将case提取出公共场景解耦等等…

这些是对开发者的要求，从对框架的要求来看，什么算是“优秀的自动化框架”呢？我认为主要有以下几点：

• 稳定性：尽量不出现因为框架不稳定导致case失败的情况
• 易维护性：将case提取出一步一步的路径节点进行解耦复用
• 易扩展性：例如通过sdk或者注入得到一个统一格式的ui tree，框架层进行元素查找，再调用对应driver进行操作，不管以后接入什么终端，只要提供sdk和driver，框架层不需要作出任何修改
• 易编写性：我个人看法是“去IDE化”，有些框架会提供本地IDE给开发者编写case，但是环境的包袱太重，可以采用云IDE，在云端利用云真机编写/录制生成case，也不需要开发者在本地配置各种冗杂的环境，同时利用mapping文件云端解混淆，也可以做到对混淆无感知
• 可分布式执行、并发执行：可以将case打到设备集群上并发执行，减少测试时长，也能增大机型/系统覆盖率

UI自动化2.0

从百度一路走来，在UI自动化方面踩了很多坑，刚写case的时候，没有注意case的解耦、复用，导致维护起来非常消耗人力，于是后来进字节之后，将case提取出公共场景进行复用，比如评论和买车都需要登录，就把登录场景单独拎出来给评论case、买车case复用，这样如果以后登录case页面做出改动，也只要修改一个case就行。字节自研了一个自动化框架，叫“Shoots”，采用PageObject设计模式，框架设计和稳定性都很不错。但是编写这个case的上手门槛非常高，要求QA很熟悉python和客户端环境，虽然它提供了一个本地IDE，但是case还是需要自己新建类自己写，非常不适合代码能力没那么高的业务同学用，于是我和师兄开发了一个测试平台，设计了一套类似uia2的脚本语法，将生成的脚本用jinjia模版翻译成Shoots的代码，这样就曲线救国实现了case的自动生成。云真机的前端渲染是开发app的SDK提供截图+ui树（Native控件使用原生代码获取ui树，webview界面通过向webview注入js获取ui树），发给服务端生成预览。

UI自动化的2.0，意味着要放宽思路，很多技术都可以应用于UI自动化中。例如通过hook，对一些没有id的控件自动生成id（https://github.com/yulingtianxia/TBUIAutoTest ），降低元素定位难度。例如将一些cv算法用于UI自动化测试过程中判断界面是否存在花屏/白屏，图像对比、模版匹配算法对比两幅图像是否一致，可以用于性能测试时获取开始帧、结束帧，也可以判断ui自动化测试的结果是否符合预期。还可以结合fuzz test，利用UI自动化访问特定接口进行接口健壮性测试。还可以从很多角度优化自动化脚本编写的体验和效率，比如元素id变了之后自动修复脚本、提供历史截图和控件树实现不需要连手机就能编写case。

客户端自动化的未来：AI Test

现在很多公司都在AI Test方面进行探索，客户端的话主要是自动测试生成（Automated Testing Generation）技术，编写case不再需要工程师，而是可以自动生成和维护case，目前在稳定性测试方面落地得比较好（https://github.com/bytedance/Fastbot_Android ）。case生成主要有两种思路，一种是提取出界面的控件，对Activity/ViewController进行bfs/dfs/A*搜索，还有一种是利用线上用户的行为提取行为链进行case生成。我在我们组负责过一个AI Test工具的落地，crash召回率有40%左右，收益还是挺不错的。

梳理了一下步骤流程，首先获取到飞书的cookie，然后在字节的“轻服务”平台上线一个服务，用来利用cookie更新飞书签名，接着在开发机部署一个定时任务，定时在丁香园爬取北京的风险地区，然后将数据post到刚刚上线的轻服务上，数据打过去之后，轻服务就能更新签名了。至于为什么用轻服务而不在开发机走完整个流程，因为cookie里的信息比较重要，放在开发机不够安全。

获取cookie

登录飞书网页版，对任意飞书api请求均可，复制cookie

在轻服务平台创建轻函数并上线

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

module.exports = async function(params, context) {

  const request = axios.create({
    baseURL: 'https://internal-api-lark-api.feishu.cn',
    headers: {
      'content-type': 'text/plain;charset=UTF-8',
      'cookie':[]
    }
  });

  await request.put('/passport/users/details/',
    {"description": params.data, "descriptionType": 0} )
  .then(res => {
    console.log(res.data)
  })
  .catch(error => {
    console.log(error)
  })

}

在开发机部署定时爬虫任务

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

import json
import re
import traceback
import requests
import datetime
import time


def crawl_dxy_data():
    """爬取丁香园实时统计数据，发送到字节轻服务，更新lark签名
    """
    response = requests.get('https://ncov.dxy.cn/ncovh5/view/pneumonia')  # 发送get请求
    print(response.status_code)  # 打印状态码

    try:
        today = datetime.datetime.now().strftime('%Y-%m-%d %H:%M')
        url_text = response.content.decode()  # 获取响应的html页面
        # re.search()用于扫描字符串以查找正则表达式模式产生匹配项的第一个位置，然后返回相应的match对象
        # 在字符串a中，包含换行符\n，这种情况下：如果不适用re.S参数，则只在每一行内进行匹配，如果一行没有，就换下一行重新开始匹配
        url_content = re.search(r'window.getAreaStat = (.*?)}]}catch',
                                url_text, re.S)
        texts = url_content.group()  # 获取匹配正则表达式的整体结果
        content = texts.replace('window.getAreaStat = ', '').replace('}catch', '')  # 去除多余字符
        json_data = json.loads(content)
        string_danger_areas = "【" + today + "自动更新北京疫情风险地区】"
        num_of_high = 0
        num_of_mid = 0
        danger_areas = []
        for _json in json_data:
            if _json["provinceShortName"] == "北京":
                danger_areas = _json["dangerAreas"]
                break
        for danger_area in danger_areas:
            if danger_area['dangerLevel'] == 1:
                num_of_high += 1
            elif danger_area['dangerLevel'] == 2:
                num_of_mid += 1
        if num_of_high > 0:
            string_danger_areas += "高风险："
            for danger_area in danger_areas:
                if danger_area['dangerLevel'] == 1:
                    string_danger_areas += danger_area['cityName'] + danger_area['areaName'] + ";"
        if num_of_mid > 0:
            string_danger_areas += "中风险："
            for danger_area in danger_areas:
                if danger_area['dangerLevel'] == 2:
                    string_danger_areas += danger_area['cityName'] + danger_area['areaName'] + ";"

        url = "轻服务url"
        post_data = {"data": string_danger_areas}
        # 字符串格式
        res = requests.post(url=url, json=post_data)
        print(res.status_code)
        print(string_danger_areas)

    except:
        print(traceback.format_exc())


if __name__ == '__main__':
    while (True):
        crawl_dxy_data()
        time.sleep(300)

在后台不挂起执行

1

$nohup python3 crawl.py &

最终效果

图像拼接是指将拍摄到的具有重叠区域的的若干图像拼接成一张无缝全景图, 以获得更大的视角和分辨率的图像。例如：

输入下面一组有重叠区域的图片：

得到下面这张拼接大图：

图像拼接流程和涉及的算法

图像拼接的完整流程如上所示，首先对输入图像提取鲁棒的特征点，并根据特征描述子完成特征点的匹配，然后根据已经匹配的特征点对得到相邻图像的位置关系从而进行图像配准，由于直接进行图像配准会破坏视场的一致性，因而一般先将图像投影在球面或者柱面上，最后计算相邻图像的拼缝并完成重叠区域的融合，得到最终的全景图像。

第一步：图像特征点提取

特征点指的是图像灰度值发生剧烈变化的点或者在图像边缘上曲率较大的点，用直白的话来说就是指，从不同的角度对同一个场景进行拍照，在每一幅照片中都能鲁棒的提取的图像的点。一个好的特征点提取算法需要具有以下的特征：数量多，在不同场景下都能提取得到足够数量的特征点；独特性好，从而便于对特征点进行匹配；抗旋转，抗亮度变化，抗尺度缩放等。特征是要匹配的两个输入图像中的元素，它们是在图像块的内部，这些图像块是图像中的像素组，对输入图像进行Patch匹配。目前比较流行的特征检索算法有：

• Harris：检测角点
• SIFT（Scale Invariant Feature Transform ）：检测斑点
• SURF（Speeded Up Robust Features）：检测斑点
• FAST（Features from Accelerated Segments Test）：检测角点
• BRIEF（Binary Robust Independent Elementary Features）：检测斑点
• ORB（Oriented Fast and Rotated Brief）：带方向的FAST算法和具有旋转不变性的BRIEF算法

  第二步：图像特征点匹配

  在特征点被检索出来之后，提取出其特征描述子，然后用SSD、NCC、BBF、KNN或brute-force等算法对不同图片中提取到的相同的特征点进行特征匹配。

  第三步：图像配准

  在得到了匹配对之后，需要根据这些匹配对得到图像的相对位置，从而把多幅图像融合成为一幅图像，该步骤的计算思路是计算两幅图像的单应性矩阵（homography matrix），从而得到一幅图像相对于另一幅图像的位置。而匹配点对是有噪声的，需要对匹配点对进行筛选，在这一步，用到的筛选算法有Lowe’s算法或RANSAC算法。得到初始单应矩阵之后，也可以运用L-M算法对初始单应矩阵加以改进,获得准确性较高的单应矩阵,从而实现图像的准确配准。

  第四步：图像融合

  在最后图像融合阶段，也可以进行寻找最佳拼接缝（常见方法：逐点法，动态规划法和图割法）和融合处理（常见算法：羽化融合和拉普拉斯融合），消除拼接图像中的“裂缝”和“鬼影”。

拼接系统拟实现方案

1. 特征提取阶段改进

   在图像特征点提取配准阶段，传统算法存在运算时间长、对输入图像相似度要求高的问题，打算采用深度学习提取ROI的方式提取图像特征，这样降低了图像配准的时间，且使得图像的变换更符合所关注的区域。

2. 在拼接系统实现算法间的对比

   • 采用B/S架构，前端使用vue.js，后端使用Python为主语言
   • 图片上传后，先使用SSIM算法计算图像相似度
   • 将自己实现的特征提取方案，与SIFT、SURF、ORB、Harris等传统算法进行运行效率对比、拼接质量对比，拼接质量采用PSNR指标
   • 对比数据使用MongoDB数据库进行落库

Matrix-ApkChecker 作为 Matrix 系统的一部分，是针对 android 安装包的分析检测工具，根据一系列设定好的规则检测 apk 是否存在特定的问题。但微信没有对其开源，它是以一个jar包的形式提供使用，可以用在持续集成系统里面用于分析排查问题并输出较为详细的检测结果报告。下面记录一下这个工具是从哪些角度分析/哪些技术手段分析问题的。

分析apk包的角度

1. 读取 manifest 的信息
   • 从 AndroidManifest.xml 文件中读取 apk 的全局信息，如 packageName、versionCode 等
2. 按文件大小排序列出 apk 中包含的文件
   • 列出超过一定大小的文件，可按文件后缀过滤，并且按文件大小排序，这样作展示会更直观
3. 统计方法数
   • 统计 dex 包含的方法数， 并将输出结果按照类名 (class) 或者包名 (package) 来分组
4. 检查是否经过了资源混淆
   • 检查 apk 是否经过了资源混淆，微信团队认为，混淆可以缩减包体积（其实混淆本身对包体积影响微乎其微，但混淆工具一般会自带压缩功能，可以了解一下微信团队的混淆工具AndResGuard）
5. 搜索不含 alpha 通道的 png 文件
   • alpha通道是用于图像透明/半透明显示的，如果png图片不含alpha通道，则不需要使用png，用jpg更节约空间
6. 检查是否包含多个ABI版本的动态库
   • so 文件的大小可能会在 apk 文件大小中占很大的比例，可以考虑在 apk 中只包含一个 ABI 版本的动态库
7. 搜索未经压缩的文件类型
   • 没有压缩的文件当然要考虑压缩～
8. 统计apk中包含的R类以及R类中的 field count
   • 编译之后，代码中对资源的引用都会优化成 int 常量，除了 R.styleable 之外，其他的 R 类其实都可以删除
9. 搜索冗余的文件
   • 对于两个内容完全相同的文件，应该去冗余
10. 检查是否有多个动态库静态链接了 STL
    • 如果有多个动态库都依赖了 STL ，应该采用动态链接的方式而非多个动态库都去静态链接 STL
11. 搜索 apk 中包含的无用资源
    • apk 中未经使用到的资源，应该予以删除
12. 搜索apk中包含的无用 assets 文件
    • apk 中未经使用的 assets 文件，应该予以删除（注：assets也是资源文件夹，相对于res来说，它不会生成R文件索引）
13. 搜索 apk 中未经裁剪的动态库文件
    • 动态库经过裁剪之后，文件大小通常会减小很多，一般来讲可以从几个方面考虑，不需要的字体/语言，或者可以裁剪的图片资源等，比如说字节有些sdk/so团队会为了适配海外app而加入多语言支持，但是如果自己的业务线不需要支持海外业务完全可以把语言部分裁掉

对应技术选型与实现

1. ManifestAnalyzeTask 用于读取 AndroidManifest.xml 中的信息，如：packageName、verisonCode、clientVersion 等。

   • 实现方法：利用 ApkTool 中的 AXmlResourceParser 来解析二进制的 AndroidManifest.xml 文件，并且可以反混淆出 AndroidManifest.xml 中引用的资源名称。

2. ShowFileSizeTask 根据文件大小以及文件后缀名来过滤出超过指定大小的文件，并按照升序或降序排列结果。

   • 实现方法：直接利用 UnzipTask 中统计的文件大小来过滤输出结果。

3. MethodCountTask 可以统计出各个 Dex 中的方法数，并按照类名或者包名来分组输出结果。

   • 实现方法：利用 google 开源的 com.android.dexdeps 类库来读取 dex 文件，统计方法数。

4. ResProguardCheckTask 可以判断 apk 是否经过了资源混淆

   • 实现方法：资源混淆之后的 res 文件夹会重命名成 r ，直接判断是否存在文件夹 r 即可判断是否经过了资源混淆。

5. FindNonAlphaPngTask 可以检测出 apk 中非透明的 png 文件

   • 实现方法：通过 java.awt.BufferedImage 类读取png文件并判断是否有 alpha 通道。

6. MultiLibCheckTask 可以判断 apk 中是否有针对多个 ABI 的 so

   • 实现方法：直接判断 lib 文件夹下是否包含多个目录。

7. CheckMultiSTLTask 可以检测 apk 中的 so 是否静态链接 STL

   • 实现方法：通过 nm 工具来读取 so 的符号表，如果出现 std:: 即表示 so 静态链接了 STL 。

8. CountRTask 可以统计 R 类以及 R 类的中的 field 数目

   • 实现方法：同样是利用 com.android.dexdeps 类库来读取 dex 文件，找出 R 类以及 field 数目。

9. UncompressedFileTask 可以检测出未经压缩的文件类型

   • 实现方法：直接利用 UnzipTask 中统计的各个文件的压缩前和压缩后的大小，判断压缩前和压缩后大小是否相等。

10. DuplicatedFileTask 可以检测出冗余的文件

    • 实现方法：通过比较文件的 MD5 是否相等来判断文件内容是否相同。

11. UnusedResourceTask 可以检测出 apk 中未使用的资源，对于 getIdentifier 获取的资源可以加入白名单

    • 实现方法：
    1. 过读取 R.txt 获取 apk 中声明的所有资源得到 declareResourceSet ；
    2. 通过读取 smali 文件中引用资源的指令（包括通过 reference 和直接通过资源 id 引用资源）得出 class 中引用的资源 classRefResourceSet ；
    3. 通过 ApkTool 解析 res 目录下的 xml 文件、AndroidManifest.xml 以及 resource.arsc 得出资源之间的引用关系；
    4. 根据上述几步得到的中间数据即可确定出 apk 中未使用到的资源。

我在包体积监控实践中的一些思考

之前在百度实习的时候，曾经用过手百团队的一个包体积分析脚本，python代码部署在流水线上，对打包完的产物进行分析并输出一个html文件，百度的流水线平台可以展示指定的html文件，所以查看分析结果还算方便。但是这个代码分析包的耗时太久了，如果想做成一个分析平台会很不方便（毕竟在前端上传一个安装包之后需要等待好久才能拿到生成的html文件并渲染出来），所以一直在找更好的解决方案，于是找到了这个微信团队的。微信的这套解决方案虽然并行的处理各个分析任务，但也还是有一定耗时，可能分析的粒度和效率很难两全吧。但是https://github.com/pengchenglin/ApkChecker_new 这个方案从前端的角度，也算是避免了上传apk后用户干等的尴尬场景。包体积分析其实算是一种静态代码分析，可以不光局限于包体积这个角度，debug开关检查等静态检查也可以放进这个流程。如果流程较多的话，也完全可以当成一个“小流水线”串行执行，每处理完一个子任务就传输数据到前端进行动态渲染，也是比单纯生成一个html页面更灵活一些。

来字节之后，也做过一个基于代码提交的包体积监控报警工具，将jenkins与gitlab绑定，每次rd git push都会触发jenkins打包，如果当前包大小与该分支上一次打包结果相比高于一个阈值，那么就触发报警。同时在前端也有基于不同分支的包体积上升折线图，方便定位是哪个分支的哪次push导致了发版包的增量。看似很天衣无缝，实则由于git的复杂性，该系统做好之后也遇到很多问题最后也不了了之了，从此也能看到一个平台开发前事先调研工作的重要性。

OOM

OutOfMemory，Android平台上主要有三类：Java OOM，虚拟内存OOM，物理内存OOM，Java OOM指Java堆内存耗尽。

物理内存即RAM，虚拟内存主要是为了满足操作系统和应用程序对物理内存的需求。虚拟内存有几个重要特点，第一个是按需分配，当分配虚拟内存时，内核先分配一个空闲地址区间，当cpu访问这个地址时，才分配实际物理页（真正使用的内存远小于实际分配的内存）。当cpu访问一个地址时，若发现当前地址未分配物理页，会触发page fault异常，在page fault异常处理中会给当前地址分配物理页，同时加载对应数据。第二个特点是按页分配，内核会以每次4kb为单位分配物理内存（内存页），为了减少内存分配的浪费。第三个特点是页表转换，在内存的申请/释放过程后，物理内存中会存在内存碎片，页表转换可以将不连续的物理内存映射到连续的虚拟内存地址。

虚拟内存不涉及实际物理内存分配，所以理论上虚拟内存应该是无限的，但是地址空间又受限于cpu的寻址能力，32位cpu寻址范围最大4G，所以32位设备虚拟内存上限也是4GB左右。虚拟内存不足会引发App OOM，进而引发App崩溃。而物理内存是内核管理的，当物理内存无法满足内存申请时，内核会进行内存回收动作，具体有释放缓存、压缩内存、后台杀进程等。内核在回收内存时会持有内存的大锁，所以如page fault等操作会卡住，导致整个用户空间的执行会非常缓慢，具体表现就是app卡顿/anr/闪退，但一般不会导致OOM，因为应用程序的内存需求是按页分配的，这算是一种最低的要求，内存总能满足，如果内存连一个物理页也提供不了，就表明系统其它重要的流程也无法执行了，就会触发内核的OOM，具体的表现就是手机的重启。

内存表示

PSS越高 越容易在内核回收时被选中杀掉

内存的申请

1
2
3
4
5
6

void* mmap(void* start, //起始地址，可以是空，也可以指定地址
           size_t length, //内存长度
           int prot, //访问属性 可读（r）可写（w）可执行（x）
           int falgs, //MAP_ANONYMOUS/MAP_FIXED/MAP_PRIVATE/MAP_SHARED
           int fd, //被映射文件的句柄，flags设置MAP_ANONYMOUS时忽略
           off_t offset); //被映射文件的偏移，必须是page size整数倍

• 文件映射
  • flags未设置MAP_ANONYMOUS
  • fd指向一个已经打开的文件
    • 设备文件：dev
    • 普通文件：system/data/vendor/sdcard
  • 内存段名是文件路径
    • 设备文件可以通过ioctl(ctl: control)修改内存段名
• 匿名映射
  • flags设置MAP_ANONYMOUS
  • fd一般为-1
  • 内存段名默认为空
    • 可通过prctl设置成anon:xxx(Android10以后webview就是这样)
• 其他映射函数：mremap/munmap/mprotect/ioctl/prctl

内存分类分布与对应优化

内存分类与分布

案例分析：32位设备运行32位app，总虚拟内存3G左右，从zygote到OOM这个过程中各阶段虚拟内存增量情况

注：

• zygoat：所有应用进程的父进程，app进程都由这个进程孵化而来）
• dalvik：dalvik虚拟机所占据内存

具体内存段的对应优化方案

虚拟机内存段

可以看出，内存消耗大头是mainspace、large object space和Bitmap，mainspace为什么有两个呢？这是虚拟机在内存碎片整理的时候所用（之前的博客里提到过），所以对应优化可以从这两块内存下手：

• Java堆裁剪：屏蔽内存碎片整理这个过程，将一块mainspace空间释放
• LargeObjectSpace
• Bitmap：Android8以上Bitmap在Native堆里分配内存，而不再在Java堆里分配内存，所以这也导致了Java OOM减少，而Native OOM增多

unnamed内存段

• webview：为了保证webview启动效率，Google在zygote阶段就给webview预留了一部分空间，但这部分空间不一定会被用到，而且现在很多公司自研浏览器内核，那这部分空间就是可以释放的（Android10 webview空间已经被命名了）
• 线程：一个线程占据1M，但通常用不到1M，可以hook Java线程创建函数然后裁剪Java线程栈，同时线程栈也会存在泄漏问题可以治理。

  anon（已命名匿名内存段）

• libc_malloc：malloc/new申请的Native堆（占内存最多）
  • 系统问题：jemalloc优化
  • APP问题：堆内存泄漏监控（下文第三部分）
• .bss：so和dex文件的bss段
• thread*：栈保护页，信号栈

  data内存段（文件映射）

  和system区分，data是app自己的而system是系统的。

data目录下分data/app/和data/data，app目录下是so（动态库）、odex（字节码转换文件）等，优化空间较小，data目录下有plugins（插件）、webview等，如果下发插件比较多，plugins也占据很大。

system内存段（目录文件映射）

system目录下由四部分，so（动态库），ttf（字库），dat和other，其中字库占据内存但有可能利用率极低，也可以释放一部分。

ashmen内存段

Google为了解决多进程的内存共享而做的Linux里的驱动，路径信息基本无效，调用链都是系统库函数，很难对应具体业务，解决方案：hook（命名or记录），收集更多业务相关信息进行治理

other

一般是设备文件

堆内存泄漏检测原理

上一篇博客已经讲了内存泄漏检测的简单原理，这篇从代码角度加以阐述
系统malloc函数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// @binoc/libc/binoc/malloc_debug_common.cpp
#define Malloc(function) je_ ## function

static const MallocDebug __libc_malloc_default_dispatch =  {
    Malloc(calloc),
    Malloc(free),
    Malloc(mallinfo),
    Malloc(malloc),
    Malloc(malloc_usable_size),
    Malloc(memalign),
    ...
};
static const MallocDebug* __libc_malloc_dispatch = &__libc_malloc_default_dispatch;
extern "C" void* malloc(size_t bytes) {
    return __libc_malloc_dispatch->malloc(bytes);
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

#define Proxy(function) proxy_ ## function

static const MallocDebug s_proxy_dispatch = {
    Proxy(calloc),
    Proxy(free),
    Proxy(mallinfo),
    Proxy(malloc),
    Proxy(malloc_usable_size),
    Proxy(memalign),
    ...
}
static const MallocDebug* sDefaultDispatch = NULL;

void do_hook_malloc() {
    void* handle = npth_dlopen("libc.so");
    void* libc_malloc_dispatch = npth_dlsym_symtab(handle, "__libc_malloc_dispatch");
    npth_dlclose(handle);

    sDefaultDispatch = *(static const MallocDebug **)lib_malloc_dispatch;
    *(static const MallocDebug **)libc_malloc_dispatch = &s_proxy_dispatch;
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

static void* proxy_malloc(size_t size) 
{
    void* raddr = __builtin_return_address(0);
    void* faddr = __builtin_frame_address(0);

    void* ptr = sDefaultDispatch->malloc(size); // 执行原malloc

    push_mem(ptr, size, raddr, faddr); // 保存信息

    return ptr;
}

static void* proxy_free(void* ptr)
{
    pop_mem(ptr); //删除信息

    sDefaultDispatch->free(ptr); // 执行原free
}

Native内存的基本概念

• 物理内存（PSS）硬件概念
  • RAM硬件
• 虚拟内存（VSS）操作系统概念，为了解决物理内存不足的问题
  • 内存分页
  • 缺页中断
  • 页面置换
• 安卓应用内存使用（均在用户空间内 user space：相对于kernel space的概念）
  • Java使用内存
    • Java heap size * 2
    • Android oat/art文件
  • Native可用内存
    • 除Java之外的用户空间
• App & Device运行时 用户空间虚拟内存上限（Native OOM的本质：用户空间虚拟内存耗尽）
  • 32位App & 32位Device：最大3G左右
  • 32位App & 64位Device：最大4G左右
  • 64位App & 64位Device：最大512G左右（是不是超大？所以64位app几乎不会有native OOM问题，支持64位app也是治理OOM途径之一）

Native内存的分配方式

无论是*alloc还是mmap都不能直接分配物理内存，只能分配虚拟内存，但是*alloc系函数分配小块内存可能直接映射到物理内存。Thread、Webview、Flutter、显存内存分配基本都是走mmap虚拟内存

PSS

• 不能直接被分配 只能被映射
• malloc/calloc/realloc/memalign
• free
• posix_memalign
• aligned_alloc
• malloc_usable_size
• pvalloc/valloc

VSS

• 当*alloc函数分配内存 >=128k 时，底层调用mmap
• mmap/mmap64
• munmap
• mremap

Native内存不足的表现

• Java Crash（pthread_create OOM）
• Native Crash
• 黑屏（底层做了异常处理，可能以黑屏方式体现）

栈回溯

• 由调用栈栈顶向栈底推到调用链的过程
• 通常用在打印crash堆栈（例如Java层的printStackTrace()）

Native内存泄漏工具

目的：找出用户虚拟内存空间被哪些业务逻辑耗尽（不光聚焦虚拟内存，还需聚焦物理内存，提高虚拟内存使用率，即找出虚拟内存中申请但未在物理内存中分配的内存，另外随着64位app的普及，在虚拟内存耗尽之前，物理内存会先耗尽并产生ANR/重启等后果）

Native内存泄漏原理

Why：与Java层不同，Java层相当于在Native层上又做了一次抽象，可以比较容易理清内存块的属性和依赖关系，所以Native内存不能像Java那样进行静态分析，只能渗透到内存分配的过程监控内存分配/释放过程
How：类似于筛子模型，过滤出分配了但没释放的内存

• Native内存泄漏监控原理
  • 通过代理拦截内存分配的地址和大小
  • 通过回溯调用栈获取内存分配的调用链（相比Java是通过依赖关系获取引用链，然后通过引用链获得调用链）
  • 通过缓存crud过滤出未释放的内存
• Native内存泄漏监控组成
  • 代理
  • 栈回溯
  • 缓存管理

已有工具/解决方案

• Malloc Debug：AOSP原生支持，难堪大用
  • 稳定性问题：存在栈回溯crash
  • 性能问题：性能损失十倍以上
• LeakTracer：依赖LD_PRELOAD机制和系统栈回溯实现
• MTrace：仅支持malloc/realloc等 不支持new/new[]等
• MemWatch
• Valgrind-memcheck
• TCMalloc
• LeakSanitizer
• 高德系统化解决方案

代理方案/栈回溯方案/缓存管理方案对比

代理方案

• Malloc hook：Android7以上，debug包，wrap.sh
• LD_PRELOAD：依赖Android版本 debug包 wrap.sh
• PLT/GOT hook：xHook
• Inline hook：Android inline hook

栈回溯方案

• libunwind_llvm：LLVM内置unwind库，libunwind llvm编年史
• libunwind_nongnu：第三方unwind实现
• libgcc_s：GCC内置unwind库
• libbacktrace：AOSP内置
• libunwindstack：Android9.0新方案
• libudf：MTK实现

缓存管理方案

• Malloc Debug：全局锁，hash散列，栈聚合，动态申请缓存空间
• LeakTracer：全局锁，大缓存，hash散列，缓存满之后动态申请缓存空间

详细的命令机器怎么（How）去处理一件事情以达到你想要的结果（What）

例子：我晚上打车回家，司机不认识路，我需要一步一步告诉司机每个路口怎么走

1
2
3
4
5
6
7

var user
for(var i=0; i < user.length; i++) {
    if(user.user_name == "Ben") {
         print("find");
         break;
    }
}

声明式编程（ Declarative programming）

只告诉你想要的结果（What），机器自己摸索过程（How）

例子：我晚上打车回家，只需要告诉司机我家在哪里即可

1
2

SELECT * from user
WHERE user_name = LiXiang

响应式编程（Reactive programming）

是使用异步数据流进行编程。本质上是对数据流或某种变化所作出的反应，但是这个变化什么时候发生是未知的，所以是基于异步、回调的方式在处理问题。
例子：我晚上打车回家，在滴滴上面下了订单发出信号，我可以在等待的时候随便做什么，不会干等着。（异步调用不阻塞）
司机接单，给我一个信号，那我就可以等司机到上车。（信号回调）
整个过程是异步回调的方式来进行的。这样我和司机都不用一直干等着，效率比较高。
代码例子可以参考RxJava/RxJS https://zhuanlan.zhihu.com/p/27678951 这篇文章里面有很详细的介绍

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Disposable subscribe = Observable.just(url)
                    .subscribeOn(Schedulers.io())
                    .map(s -> {
                        ArrayList<BasicNameValuePair> params = new ArrayList<BasicNameValuePair>();
                        params.add(new BasicNameValuePair("email", getEmail()));
                        params.add(new BasicNameValuePair("host_ip", getHostIp()));
                        params.add(new BasicNameValuePair("host_port", "10086"));
                        params.add(new BasicNameValuePair("package", getCurrentActivity().getPackageName()));
                        String executeGet = NetworkUtils.executePost(200 * 1024, s, params);
                        JSONObject object = new JSONObject(executeGet);
                        return object;
                    })
                    .observeOn(AndroidSchedulers.mainThread())
                    .subscribe(object -> {
                        ToastUtils.showLongToast(getCurrentActivity(), "配置成功");
                    });

函数式编程（Functional programming）

函数式的代码是对映射的描述,在函数式语言中，函数作为一等公民，可以在任何地方定义，在函数内或函数外，可以作为函数的参数和返回值，可以对函数进行组合。

好处：首先，最直观的角度来说，函数式风格的代码可以写得很精简，其次，函数式的代码是“对映射的描述”，它不仅可以描述二叉树这样的数据结构之间的对应关系，任何能在计算机中体现的东西之间的对应关系都可以描述——比如函数和函数之间的映射；比如外部操作到 GUI 之间的映射（就是现在前端热炒的所谓 FRP）。它的抽象程度可以很高，这就意味着函数式的代码可以更方便的复用。

最后，可以很好的写出并行代码
代码例子(翻转二叉树):

1
2
3
4
5
6

data Tree a = Nil | Node a (Tree a) (Tree a)
    deriving (Show, Eq)
    
invert :: Tree a -> Tree a
invert Nil = Nil
invert (Node v l r) = Node v (invert r) (invert l)

函数式编程和声明式编程有所关联，因为他们思想是一致的：即只关注做什么而不是怎么做。但函数式编程不仅仅局限于声明式编程。

引用计数法

具体方法是，在对象中添加一个引用计数器，每当有一个地方引用它时，计数器+1，当引用失效时，计数器-1，如果计数器为零，就说明没有地方在引用它。这个方法看似原理很简单，效率也高，但其实需要很多额外的考虑才能保证这个判定过程正确执行，比如单纯的引用计数很难解决对象间的循环引用的问题，举个例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public class ReferenceCountingGC {

private Object instance=null;
private static final int _1MB=1024*1024;
private byte[] bigSize=new byte[1024*1024];//1MB的堆空间
 
public static void main(String[] args) {
ReferenceCountingGC objA=new ReferenceCountingGC(); // step1
ReferenceCountingGC objB=new ReferenceCountingGC(); // step2
objA.instance=objB; // step3
objB.instance=objA; // step4
objA=null; // step5
objB=null; // step6
}
 
}

可达性分析法

可达性分析法就是通过一系列的GC Root根对象作为起始节点，用类似二叉树遍历的方法向下搜索，如果GC Root到某个对象不可达，这时的对象就是不可能再被引用的，会被回收掉。

可作为GC Root的对象包含下面几种：

• 虚拟机栈本地变量表中引用的对象
• 方法区中常量引用的对象、静态属性引用的变量
• 本地方法区中JNI引用的变量
• Java虚拟机内部的引用，比如异常对象NullPointerException
• 所有被同步锁（synchronized关键字）持有的对象
• 反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码的缓存等…

除了这些固定的对象之外，根据垃圾收集的区域不同，还可以有其他对象临时加入，因为根据虚拟机自己的实现细节，某个区域里的对象完全有可能被其他区域对象所引用

对象的引用分类（强度依次递减）

• 强引用：例如Object a = new Object()只要强引用关系存在，对象就不会被回收
• 软引用：还有用，但非必须的对象，这部分对象会在系统将要内存溢出前进行回收
• 弱引用：一旦发起垃圾回收，就会回收弱引用的对象
• 虚引用：“形同虚设”，一个对象是否有虚引用，完全不影响它的生命周期。虚引用与软引用和弱引用的一个区别在于：虚引用必须和引用队列（ReferenceQueue）联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。

finalize()方法

要真正宣告一个对象的死亡，至少要经过两次标记过程：第一次是可达性分析后发现不可达，被第一次标记；第二次是一次筛选，筛选条件是此对象是否有必要执行finalize()方法，如果对象未覆盖finalize()方法，或者finalize()方法已经被对象调用过，那就没必要执行，假如被判定为有必要执行，那么该对象会被放在一个名为F-Queue的队列中，稍后由一条虚拟机自动建立的、低调度优先级的Finalize()线程执行队列中对象的finalize()方法。执行是指仅仅触发，并不会等待一个对象执行完，因为假如一个对象的finalize()方法运行缓慢，如果等待的话会影响其他对象的回收。

finalize()有点类似C/C++的析构函数，这个语法当初就是为了迎合C/C++程序员而做的一项妥协，但这个语法不合适当成析构函数用，因为它运行代价高昂，不确定性大，无法保证各个对象的调用顺序，已经被官方声明为不推荐的语法。

finalize()方法是对象最后的抢救机会，假如对象在此方法中又与GC Root建立了联系，那么这个对象实例就会逃过这次GC，但一个实例的finalize方法只会被执行一次，所以在下一次GC发起时，这个对象不会再因为finalize方法而再逃一次。

方法区的回收

方法区的垃圾回收收益远不及堆区，所以一般不要求虚拟机在方法区中实现垃圾收集，但有些情况下，方法区也会有一些较大的内存压力，那么方法区如何垃圾回收呢？

从上一篇博客我们知道，方法区主要有两部分数据，类型信息和常量池，常量池中常量的回收比较简单，类似于对象，但判断一个类型是否属于不再被使用的类条件就比较苛刻了，需要同时满足下面三个条件：

• 该类所有实例已经被回收，堆中不存在该类或者任何派生类的实例
• 加载该类的类加载器已经被回收
• 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射获取这个类的方法

如果同时满足了上述三个条件，那么该类型便允许被回收，而并不是像对象那样，必然被回收

垃圾收集算法

上文说，对象判活有两种算法，引用计数和可达性分析，从这两个算法出发，垃圾收集算法可以分为引用计数式垃圾收集和追踪式垃圾收集。主流的是追踪式垃圾收集。

分代收集理论

在垃圾回收时，虚拟机要关注的对象体量是非常庞大的，假如每次都要遍历一边，无疑会造成很多性能上的损失，于是提出了分代收集理论，将Java堆划分出不同区域，然后将对象按照年龄（年龄即熬过垃圾收集过程的次数）分配到不同区域中，这个理论是建立在两个分代假说之上：

1. 弱分代假说：绝大多数对象都是朝生夕灭
2. 强分代假说：熬过越多次垃圾收集的对象越难消亡

根据这两个假说，大部分虚拟机将Java堆划分成新生代和老年代，新生代中存放朝生夕灭的对象，每次垃圾回收时都有大批量对象死去，而每次回收后存活的少量对象，将晋升到老年代中存放，老年代对象因为很难消亡，所以只需很低的频次对这块区域进行回收即可，这样就比原先每次遍历整个堆效率提升了很多。

但仔细思考一下，分代收集真的只是划分一下区域这么简单吗？这里其实存在一个问题，对象不是孤立的，而是存在跨代引用。假如现在要进行一次只针对新生代的收集（Minor GC），但新生代中的对象完全有可能被老年代中对象引用，这样的话，GC Root就得再加上老年代对象，来进行可达性分析，这种方案理论可行，但也会为内存增大很大负担，所以垃圾分代理论有了第三条经验法则：

1. 跨代引用假说：跨代引用相对于同代引用来说仅占极少数

有了这条假说，我们就不必为了少量的跨代引用去扫描整个老年代，只需要在新生代上建立一个记忆集（Remember Set），这个结构作用是将老年代划分成若干小块，标示出哪一块会存在跨代引用，此后每次进行Minor GC时，只需将跨代引用的那一小块加入GC Root中，这个做法会增加一些运行时常数复杂度的开销，但相比于扫描整个老年代仍是划算的。

三种垃圾收集算法

标记-清除算法

扫描一遍对象之后，标记出哪些可回收哪些不可回收，接着保留不可回收的，清除可回收的，这个算法最为简单，也是后面两个算法的基础，它有几个显而易见的缺点：

• 执行效率不稳定，假如Java堆中对象数量很大，并且大部分都是需要回收的，那么要进行大量的标记清除工作，执行效率就会降低
• 直接原地清除的话会产生大量不连续的内存碎片，如果内存碎片太多，程序运行也需要分配较大对象的话，可能会出现无法找到足够的连续内存而提前出发GC

标记-复制算法

为了解决标记-清除算法面对大量可回收对象时执行效率低的问题，有人提出了半区复制算法，将可用内存划为大小相等的两块，当一块内存用完时，将存活的对象复制到另一块空间上，并将自身已经使用的内存空间一次性清理掉。如果内存中大量的对象都是存活的，那么这个算法将产生大量的复制开销，但如果大多数内存都是可回收的，那么算法每次复制的就是少量的存活对象，并且这种算法也不会出现空间碎片的情况。但这个算法还有点不足，内存缩小为原先的二分之一，空间浪费太大。

因为这种算法适用大多数内存可回收的情况，所以很多商用JVM用这个算法来回收新生代，根据新生代朝生夕灭的特点，有人对这个算法做了改进，弥补了空间浪费这个缺点，被称为Appel式回收。

Appel式回收的具体做法是将新生代划为一块较大的Eden区，两块较小的survivor区，内存大小比例是8:1:1，每次分配内存只在Eden区和一块survivor区上进行，发生垃圾收集时，将Eden区和survivor区上的存活对象复制到另一块survivor区上，然后对Eden区和已用的survivor区清理内存，这样的话，每次新生代的空间利用率可以达到90%，假如存活对象太多，一块survivor区不足以承载怎么办呢？Appel式回收提供了一个逃生门的设计，如果survivor区空间不够，就会依赖别的内存区域（多数是老年代）进行内存担保，借一块内存。

标记-整理算法

这种算法是针对老年代的特点提出的，其标记过程仍与“标记-清除”算法一样，但后续步骤不是对对象进行清理，而是将所有存活对象都向内存空间一端移动，然后直接清除掉边界外的内存。因为老年代中存活的对象很多，所以移动对象并更新对象引用是一个极为负重的操作，并且对象的移动操作必须要全程暂停用户应用线程才能进行，这无疑是增加延迟的。但如果和标记-清除算法一样不考虑移动整理存活对象的话，空间碎片化问题只能依赖更为复杂的内存分配器/内存访问器解决（比如像计算机硬盘存储大文件那样），两者均有利弊，那到底是整理内存还是不整理呢？从整个程序的吞吐量来看，因为内存分配和访问相比于垃圾收集频率要大得多，所以权衡利弊，应该用垃圾收集时的短暂延迟换取内存分配访问所耗费的时间复杂度。

另外，也可以两者兼顾，让虚拟机平时多数时间采用标记-清除算法，当内存碎片化程度高于一定阈值时，再采用标记-整理算法收集一次，换取规整的内存空间。

程序计数器（线程私有）

执行字节码的行号指示器

虚拟机栈（线程私有）

Java方法执行的本地线程模型：每个方法被执行的时候，Java虚拟机同步创建一个栈帧，里面存放局部变量表，操作数栈，动态链接，方法出口等信息。每个方法从被调用到执行完毕，对应着一个栈桢在虚拟机栈中出栈到入栈的过程。很多人将JVM数据区笼统划分为堆内存和栈内存，栈内存通常就是指虚拟机栈，或者虚拟机栈中局部变量表部分。

局部变量表里存放两种类型数据，一种是基本类型，一种是引用类型。基本类型有三种，数值类型，布尔类型和returnAddress类型，数值类型和引用类型构成了8大基本数据类型，returnAddress类型指向一条字节码指令的地址，这是干什么用的呢？对于JVM来说，程序是存储在方法区的字节码指令，Java中每个线程私有一个程序计数器，程序计数器的值就是当前指令的地址，该值的类型就是returnAddress

本地方法栈（线程私有）

和虚拟机栈类似，差别是本地方法栈执行本地方法，虚拟机栈执行Java方法

堆（线程共有）

数据区中最大的一部分，JVM启动的时候被创建，用于存放几乎所有对象实例。这也是GC的区域，所以也叫GC堆

方法区（线程共有）

用于存储已被虚拟机加载的类型信息（类的完整名称、类的直接父类的完整名称、类的直接实现接口的有序列表、类型标志（类类型还是接口类型）类的修饰符）、常量池、静态变量、即时编译器编译后的代码缓存等数据，在JDK8之前，很多人将方法区称为永久代，这是因为hotspot虚拟机用永久代实现了方法区，因为永久代经常会溢出，到了jdk8之后，取消了永久代的概念，将方法区移到了元空间中，将字符串常量移到了堆内存中

运行时常量池

class文件中除了有类的版本、字段、方法、接口等信息之外，还有一个常量池表，用于存放编译器生成的字面量和符号引用，这个常量池表在类加载后存放到方法区的运行时常量池中。

• 字面量：

1
2

int a = 1; // 1是字面量
String s = "a"; // a是字面量

• 符号引用：和直接引用相对，在代码编译阶段，编译器并不知道所引用的类的地址，就会用一个符号来代替，在JVM解析class阶段，会将符号引用解析为直接引用（指针/偏移量/句柄）

hotspot虚拟机与对象

虚拟机中对象的创建

1. Java虚拟机遇到一条字节码new的指令时，先检查这个指令的参数能否在运行时常量池中找到对应的符号引用，并检查这个符号引用有没有被解析加载，如果没有，必须要先进行解析加载操作
2. 虚拟机在堆内存中为该对象实例划分内存空间，这里有两种，一种是连续内存，连续内存里一段是已经使用的内存，一段是空闲内存，之间由一个指针指向分界点，这种划分内存就是让这个指针向空闲内存偏移一段地址，称为指针碰撞，另一种是非连续的内存，这种就需要维护一个list，记录哪段内存被占用了哪段没有，这种分配方法称为空闲列表。在这一个阶段中，假如是并发状态，分配空间的操作不一定是线程安全的，这时也有两种方案，一种是CAS加锁，另一种是让每个线程在虚拟机中预先分配一块内存，称为本地线程分配缓冲（Thread Local Allocation Buffer, TLAB）
3. 内存分配完成之后，将这块内存空间都初始化为零值，这就保证了对象实例在Java代码中不赋初始值就能直接使用
4. 对对象进行必要的设置，这些设置信息存放在对象头中

虚拟机中对象的布局（hotspot为例）

在JVM中，一个对象在堆内存中的存储布局由三部分组成，对象头，实例数据，对齐填充

1. 对象头：对象头中存储两个方面的数据，运行时数据和类型指针。运行时数据主要有，GC分代年龄，锁信息，hashcode等，在32位系统中，运行时数据占32个比特，在64位系统中，运行时数据占64个比特，类型指针是一个指向对象的元类型数据的指针（也就是指向存在方法区的类型数据），虚拟机通过这个判断该对象是哪个类的实例。
2. 实例数据：就是对象中存储的有效信息，也就是从父类继承的字段和自己定义的字段信息，这些字段会被按序分配内存
3. 对齐填充：为了提高垃圾回收时指针扫描的效率，hotspot自动内存管理系统要求对象起始指针必须是8字节的整数倍，对象头占内存要么是8字节的一倍（32比特），要么是8字节两倍（64比特），如果实例数据不满足内存长度的要求，就会有对齐填充，起到对齐数据的作用

虚拟机中对象的访问定位

主要有两种方式：句柄定位，直接指针定位

1. 句柄定位：上文我们提到，在虚拟机虚拟机栈的局部变量表中，有一个“reference”引用类型，如果是句柄定位的话，reference类型就指向堆内存中句柄池里的一个句柄，这个句柄包含两方面信息（指针），对象实例信息，对象类型信息，一个指针指向堆内存中实例池里的对象实例，一个指针指向方法区的对象类型数据。这个的优点是，如果对象实例被移动（比如垃圾回收时），只会改变句柄中的对应地址，而reference地址是稳定的
2. 直接指针定位（hotspot主要使用这个方法）：reference存储的就是堆内存里对象的地址，这样只需要一步就能直接访问到对象的实例数据，由上文对象的布局我们也可以知道，对象头里有一个类型指针，这个类型指针也会和句柄定位一样，指向方法区的类型数据

在Java中，我们可以通过throw、try{}catch{}finally{}进行方便的异常处理，在C++中稍微复杂一些，没有finally语法，因此在遇到程序发生异常但需要关闭资源的时候，在C++中通常两种做法，第一种也是最常用的一种是使用RAII，即Resource Aquisition Is Initialization就是将资源封装成一个类，将资源的初始化封装在构造函数里，释放封装在析构函数里。要在局部使用资源的时候，就实例化一个local object。在抛出异常的时候，由于local object脱离了作用域，自动调用析构函数，这样就保证资源被释放。例如：

1
2
3
4
5
6
7

try {
   File f("xxx.ttt");
    //other file operation
}//File pointer is released here
catch {
    //exception process
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

int main(){
    int a = 0;
    int b = 0;
    printf("请输入两个值:\n");
    printf("a = ");
    scanf("%d",&a);
    printf("b = ");
    scanf("%d",&b);
    if(b==0){
        goto Error;
    }
    printf("a/b = %d\n",a/b);
    return 0;
Error:
    printf("除数不能为0,程序异常退出!\n");
    exit(-1);
}

defer

defer就相当于finally，defer的特性是，不管会不会发生异常，在函数返回之前，先调用defer函数，如果有多个defer语句，按照先进后出的方式进行执行，需要注意的是，defer语句中的变量，在defer声明时就决定了。

例如使用defer时的一个坑：

1
2
3
4
5

func main() {
a := 1
defer fmt.Print(a) // 因为在defer声明的时候，变量已经确定，所以还是输出1
a++
}

上面我们说到，defer会在函数返回之前被调用，但这并不意味着defer是在return之前被执行，是这样吗？看下面的例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

package main

import "fmt"

func test() (res int) {
res = 1
defer func() {
res++
}()
return 0
}

func main() {
fmt.Print(test()) // output: 1
}

1. 给返回值赋值；
2. 调用RET返回指令并传入返回值，而RET则会检查defer是否存在，若存在就先逆序插播defer语句，最后RET携带返回值退出函数。

在这个例子中的话，res = 1 -> res = 0 -> res++，所以res返回值最终是1

panic和recover

panic，恐慌，也就是抛出异常；

recover，恢复，也就是从异常中恢复状态；

在go里，panic和recover是抛异常和捕获异常的解决方案，panic相当于throw Exception，recover和defer结合起来相当于try…catch…

先看一个手动引起异常的例子：

1
2
3
4
5
6
7

func main() {
a := []int{1, 2, 3}
panic("触发异常")
fmt.Print(a[2])
}
-----output-----
panic: 触发异常

要注意的是, F函数中的defered函数会正常执行, 按照上面defer的规则。

同时引起panic除了我们主动调用panic之外, 其他的任何运行时错误, 例如数组越界都会造成panic，比如：

1
2
3
4
5
6

func main() {
a := []int{1, 2, 3}
fmt.Print(a[3])
}
-----output-----
panic: runtime error: index out of range [3] with length 3

不过需要注意的是：

• recover如果想起作用的话， 必须在defered函数中使用。
• 在正常函数执行过程中，调用recover没有任何作用, 他会返回nil。如这样：fmt.Println(recover()) 。（当然了，没捕获到异常肯定是nil了==）
• 如果当前的goroutine panic了，那么recover将会捕获这个panic的值，并且让程序正常执行下去。不会让程序crash。
  看一个正常的捕获异常的例子：

  1 2 3 4 5 6

  defer func() { if r := recover(); r != nil { log.Printf("Runtime error caught: %v", r) } }() foo()

  无论foo()是否触发了错误处理流程，defer函数都会在函数退出时得到执行，如果没抛出异常，那么r就是nil，如果抛出了异常，recover就能捕获它、处理它。

传值：函数传递的是参数的一个副本，将传入的变量在内存中复制一份进行操作，本质上是存储在不同内存地址的不同变量

传引用：传引用是指函数通过内存地址将函数取出进行操作，本质上是存储在相同内存地址的相同变量

C

C语言的传参没有传引用，只有传值。那C语言是如何做到通过调用函数修改函数体外的实参的呢？答案是传址调用。经常有人把C语言的传值调用和传址调用并列比较，在我看来，传址调用只不过是传值调用的子集。当传的值是地址的时候，传值调用就是传址调用了。

传值调用的时候，函数会给形参a单独分配一个内存，实参a会把值复制到形参a的内存中，对形参的操作是在形参对应的内存里操作，这是完全独立于实参的。如果参数是一个地址的话，这里举一个例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

#include <stdio.h>
void modify(int* a)
{
    printf("address of pointer is:%p\n", &a);
    *a = 2;
}

int main() 
{
    int a = 1;
    int* p = &a;
    printf("address of pointer is:%p\n", &p);
    modify(p);
    printf("%d", a);
    return 0;
}

1
2
3

address of pointer is:0x7ffee9cdb490
address of pointer is:0x7ffee9cdb468
2

Go

go的函数传参和C类似（毕竟是增强版C语言嘛），是绝对的传值，当指针作为函数参数时，调用过程和C也一样，也是临时申请一个空间存放指针的值，然后通过这个指针修改实参。但Go有三种自带的数据类型map，chan，和slice，他们可以认为是一种引用类型，虽然调用的时候不需要加&符号，但实际上也是一种传址。

map

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

package main

import "fmt"

func testMap(m map[string]int) {
fmt.Printf("inner: %v, %p\n", m, m)
m["a"] = 11
fmt.Printf("inner: %v, %p\n", m, m)
}

func main() {
m := map[string]int{
"a": 1,
"b": 2,
"c": 3,
}
fmt.Printf("Outer: %v %p\n", m, m)
testMap(m)
fmt.Printf("Outer: %v %p\n", m, m)
}

输出：

1
2
3
4

Outer: map[a:1 b:2 c:3] 0xc000064180
inner: map[a:1 b:2 c:3], 0xc000064180
inner: map[a:11 b:2 c:3], 0xc000064180
Outer: map[a:11 b:2 c:3] 0xc000064180

1
2
3
4
5

func makemap(t *maptype, hint int, h *hmap) *hmap {
    if hint < 0 || hint > int(maxSliceCap(t.bucket.size)) {
        hint = 0
    }
    ...

chan

chan类型和map类型类似，看一下makechan源码：

1
2
3

func makechan(t *chantype, size int) *hchan {
    elem := t.elem
  ...

slice

slice和map/chan略有区别，先看一个例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

package main

import "fmt"

func main() {

sl := []string{
"a",
"b",
"c",
}

fmt.Printf("%v, %p\n", sl, sl)
test_slice(sl)
fmt.Printf("%v, %p\n", sl, sl)
}

func test_slice(sl []string) {
fmt.Printf("%v, %p\n", sl, sl)
    sl[0] = "aa"
    fmt.Printf("%v, %p\n", sl, sl)
sl = append(sl, "d")
fmt.Printf("%v, %p\n", sl, sl)
}

1
2
3
4
5

[a b c], 0xc000090180
[a b c], 0xc000090180
[aa b c], 0xc000090180
[aa b c d], 0xc0000b0120
[aa b c], 0xc000090180

1
2
3
4
5

type slice struct {
    array unsafe.Pointer
    len   int
    cap   int
}

也就是说，slice还是以值的形式传入函数中的，函数对slice实参进行拷贝得到了一个slice形参，在对slice形参修改的过程中，因为array部分是指针，所以能修改到实参里的array，而len和cap是int类型，所以只能修改副本。那既然形参是实参的拷贝，为什么打印出来的地址值是一样的呢？这就是printf的实现细节了，继续看源码：

1
2
3
4
5
6
7
8
9
10
11
12
13

func (v Value) Pointer() uintptr {
    // TODO: deprecate
    k := v.kind()
    switch k {
    case Chan, Map, Ptr, UnsafePointer:
        return uintptr(v.pointer())
    case Func:
        ...
    case Slice:
        return (*SliceHeader)(v.ptr).Data
    }
    ...
}

总结

Go只能传值，指针的传值类似C语言，map和chan因为底层就是指针，所以看上去像传引用，实际上只不过传的是经过封装的指针，而slice，底层是结构体（类），在传参过程中，妥妥的传值、拷贝，但是由于成员变量array是地址，所以能影响到实参，又因为fmt打印地址的时候，输出的是array的地址，所以看似形参实参地址相同

是不是Go里没有引用呢？

在之前讲闭包的时候，提到过一个引用环境的概念，引用环境就是对自由变量的引用，例如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

package main

import "fmt"

func swap_(fn func()) {
fn()
}

func main() {
a := 0
b := 1
fmt.Println("a: ", a)
swap := func() {
a, b = b, a
}
swap_(swap)
fmt.Println("a: ", a)
swap_(swap)
fmt.Println("a: ", a)
}

1
2
3

a:  0
a:  1
a:  0

C++

C++在C传值/传地址的基础上，还有一个传引用的特性，看一个例子

1
2
3
4
5
6
7
8
9
10
11
12
13

#include <stdio.h>
void modify(int& a)
{
    a = 2;
}

int main() 
{
    int a = 1;
    modify(a);
    printf("%d", a); // 输出2
    return 0;
}

Java

先得解释一下Java的一些术语

1. 基本数据类型、引用类型定义
   • 基本数据类：Java 中有八种基本数据类型“byte、short、int、long、float、double、char、boolean”
   • 引用类型：new 创建的实体类、对象、及数组
2. 基本数据类型、引用类型在内存中的存储方式
   • 基本数据类型：存放在栈内存中。用完就消失。
   • 引用类型：在栈内存中存放引用堆内存的地址，在堆内存中存储类、对象、数组等。当没用引用指向堆内存中的类、对象、数组时，由 GC回收机制不定期自动清理。

Java这里也很类似Go，Java也是只有值传递。Java没有指针，和Go里传入参数是指针（引用类型）的情况相似，当Java传入引用类型时，会先给形参一个与实参相同的地址(此处与 C++ 的不同之处是，C++ 是别名，没有在内存中给形参开辟空间，而 Java 给形参开辟了一个栈内存空间，存放与实参相同的引用地址)。Java在进行方法调用修改了引用类型形参后，会影响到实参的值，这和Go的结果也是一样的。

但是Java有一点要注意的是，一些特殊的类，比如String，包装类，虽然是引用类型，但是它们每次赋值的时候会重新创建对象，也就是说，它们身为引用类型的特性已经被破坏了，修改形参是不能对实参构成影响的。

Python

python目前还不熟悉，待填坑～

函数是什么

函数，是内存里一段可执行代码。

源码链接：https://github.com/bodhisatan/LearnSSIM/blob/master/test_ssim.cpp

友链：https://wangwei1237.github.io/2020/02/15/how-to-calculate-the-SSIM-in-FFMpeg/

代码前面叭叭叭说了一大堆，有用的只有两句，一是告诉了我们输入格式：两个YV12（YUV420P）格式视频文件，二是告诉我们为了提升速度，代码没有用论文里的高斯卷积核作加权平均，而是用了8x8有重叠的像素块求和的方法。

读源码，先从main函数读起

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

FILE *f[2];
uint8_t *buf[2], *plane[2][3];
   int *temp;
   uint64_t ssd[3] = {0, 0, 0};
   double ssim[3] = {0, 0, 0};
   int frame_size, w, h;
   int frames, seek;
   int i;

   if (argc < 4 || 2 != sscanf(argv[3], "%dx%d", &w, &h))
   {
       printf("tiny_ssim <file1.yuv> <file2.yuv> <width>x<height> [<seek>]\n");
       return -1;
   }

   f[0] = fopen(argv[1], "rb");
   f[1] = fopen(argv[2], "rb");
   sscanf(argv[3], "%dx%d", &w, &h);

   if (w <= 0 || h <= 0 || w * (int64_t)h >= INT_MAX / 3 || 2LL * w + 12 >= INT_MAX / sizeof(*temp))
   {
       fprintf(stderr, "Dimensions are too large, or invalid\n");
       return -2;
   }

先进行了变量定义和初始化，规定了程序运行格式，读入了两个文件f[0]和f[1]，以及视频长宽w，h。

1
2
3
4
5
6
7
8

frame_size = w * h * 3LL / 2;
for (i = 0; i < 2; i++)
{
        buf[i] = (uint8_t *)malloc(frame_size);
        plane[i][0] = buf[i];
        plane[i][1] = plane[i][0] + w * h;
        plane[i][2] = plane[i][1] + w * h / 4;
}

这句话就要联系我上篇wiki中关于YUV420P的知识，视频文件在计算机中被读取/计算的时候，数据是以字节流的形式存储的，frame_size就是一帧视频占内存的大小。Y占w*h字节，U和V都是占1/4*w*h个字节，合起来就是1.5*w*h个字节。

一帧数据读进内存之后，分离出Y，U，V三个分量。因为YUV420P是planar格式存储的，先Y然后U最后V，所以只需要读取的时候加一个内存偏移量就能分别读到这三个分量。plane[i][0]存储Y分量信息，plane[i][1]存储U分量信息，plane[i][2]存储V分量信息。i取0和1，这是用来区分两个输入文件的。

接下来就开始了逐帧计算：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

for (frames = 0;; frames++)
{
    uint64_t ssd_one[3]; 
    double ssim_one[3]; 
    if (fread(buf[0], frame_size, 1, f[0]) != 1)
        break;
    if (fread(buf[1], frame_size, 1, f[1]) != 1)
        break;
    for (i = 0; i < 3; i++)
    {
        ssd_one[i] = ssd_plane(plane[0][i], plane[1][i], w * h >> 2 * !!i);
        ssim_one[i] = ssim_plane(plane[0][i], w >> !!i,
                                 plane[1][i], w >> !!i,
                                 w >> !!i, h >> !!i, temp, NULL);
        ssd[i] += ssd_one[i];
        ssim[i] += ssim_one[i];
    }

    printf("Frame %d | ", frames);
    print_results(ssd_one, ssim_one, 1, w, h);
    printf("                \r");
    fflush(stdout);
}

ssd_one和ssime_one代表一帧数据的ssd与ssim结果，ssd的含义在前一篇wiki中也解释过了。他们都是大小为3的数组，因为Y，U，V三个数据分量需要分别计算存储。接下来两行fread，读取数据送入buf中，但因为前文的代码里Y分量的起始存储位置就是从buf开始的，所以plane数组就自动的获得了数据。不得不感叹代码的精妙！

接下来是一个i从0到3的循环，i=0时比较Y，i=1时比较U，i=2时比较V，ssd_plane是按plane计算ssd，ssim_plane是按照plane计算ssim，ssd_plane代码如下：

1
2
3
4
5
6
7
8
9
10
11

uint64_t ssd_plane(const uint8_t *pix1, const uint8_t *pix2, int size)
{
    uint64_t ssd = 0;
    int i;
    for (i = 0; i < size; i++)
    {
        int d = pix1[i] - pix2[i];
        ssd += d * d;
    }
    return ssd;
}

先分析上文调用的语句ssd_one[i] = ssd_plane(plane[0][i], plane[1][i], w * h >> 2 * !!i); plane[0][i]表示原视频的像素信息起始地址，plane[1][i]表示重建后视频的像素信息起始地址，w*h >> 2*!!i表示这段信息的大小，这里的!!i就有点让人费解，仔细一想，再次不得不叹服这段代码的巧妙。!!i在i=0时值是0，大于0时值是1，所以这就巧妙地得到了Y向量信息占内存的大小（wh），U/V向量占内存的大小（w \h >> 2）。

ssd的计算分析完了，现在开始分析ssim的计算，先看一下所调函数ssim_plane的代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

float ssim_plane(
    pixel *pix1, intptr_t stride1,
    pixel *pix2, intptr_t stride2,
    int width, int height, void *buf, int *cnt)
{
    int z = 0;
    int x, y;
    float ssim = 0.0;
    
    int(*sum0)[4] = (int(*)[4])buf; 
    int(*sum1)[4] = sum0 + (width >> 2) + 3;
    width >>= 2;
    height >>= 2; 
    for (y = 1; y < height; y++)
    {
        for (; z <= y; z++)
        {
            // FFSWAP( (int (*)[4]), sum0, sum1 );
            int(*tmp)[4] = sum0;
            sum0 = sum1;
            sum1 = tmp;

            for (x = 0; x < width; x += 2)
                ssim_4x4x2_core(&pix1[4 * (x + z * stride1)], stride1, &pix2[4 * (x + z * stride2)], stride2, &sum0[x]);
        }
        for (x = 0; x < width - 1; x += 4)
            ssim += ssim_end4(sum0 + x, sum1 + x, FFMIN(4, width - x - 1));
    }
    //     *cnt = (height-1) * (width-1);
    return ssim / ((height - 1) * (width - 1));
}

上文调用它的语句是ssim_one[i] = ssim_plane(plane[0][i], w >> !!i, plane[1][i], w >> !!i, w >> !!i, h >> !!i, temp, NULL);对于U和V向量来说，他们的内存占比是四分之一w*h，那么在填写width和height参数的时候就要分别取w和h的二分之一。

然后看ssim_plane函数体，这个函数是按照4x4的块对像素进行处理的，使用sum1保存上一行块的“信息”，sum0保存当前一行块的“信息”。sum0、sum1是一个数组指针，其中存储了一个4元素数组的地址，换句话说，sum0、sum1中每一个元素对应一个4x4块的信息（该信息包含4个元素）。4个元素中，[0]代表原始像素之和，[1]代表重建像素之和，[2]代表原始像素平方之和+重建像素平方之和，[3]代表原始像素*重建像素的值的和。然后width和height分别右移两位（÷4），因为这一步的计算是以44的像素块为基本单位的。然后进入循环，看到这句话，for (; z <= y; z++)在这个函数开头，定义了z=0，也就意味着这个循环体里的语句在第一次执行时会执行两次，其他时候就会执行一次（妙啊），为什么要执行两次呢？因为sum0存储的是一行里4x4块的信息，sum1里存着上一行里的4x4块的信息，在下文的ssim_4x4x2_core运算中，是要将这两行合起来，计算*有重叠8x8像素块的信息。在这一步循环中for (x = 0; x < width; x += 2)，x每次加2，也就是每次前进两个像素，然后在ssim_4x4x2_core中计算两个4x4的像素块，也就是说，在一行中，这些4x4的像素块都是两两重叠的。

接下来进入这个循环：for (x = 0; x < width - 1; x += 4)，x每次+4，步长为4，每次跳过4*4个int，进入ssim_end4:

1
2
3
4
5
6
7
8
9
10
11
12

static float ssim_end4(int sum0[5][4], int sum1[5][4], int width)
{
    float ssim = 0.0;
    int i;

    for (i = 0; i < width; i++)
        ssim += ssim_end1(sum0[i][0] + sum0[i + 1][0] + sum1[i][0] + sum1[i + 1][0],
                          sum0[i][1] + sum0[i + 1][1] + sum1[i][1] + sum1[i + 1][1],
                          sum0[i][2] + sum0[i + 1][2] + sum1[i][2] + sum1[i + 1][2],
                          sum0[i][3] + sum0[i + 1][3] + sum1[i][3] + sum1[i + 1][3]);
    return ssim;
}

一开始的时候，我因为指针不熟悉，有这样一个疑问，在ssim_4x4x2_core中，每次计算的是sums[0][0~3]和sums[1][0~3]，每次都计算一样的值吗，循环变量x的变化又体现在哪里呢？以及，在ssim_end4中，参与运算的是sum0[0~width][0~3]啊，在ssim_4x4x2_core里，只计算了sum[0~1][0~3]啊，很多在这步需要参与运算的值，在之前都没计算过啊。一番查资料，才知道：

ssim_4x4x2_core里的sums和ssim_end4里的sum意义并不完全相同，和ssim_plane里的sum意义也不相同。sum0和sum1是一个int[*][4]，也就是指向int[4]数组的指针，C/C++里，二位数组在传参的时候，第一个维度是可以不写的（写是为了起提示作用），也就是说，ssim_4x4x2_core里的int sums[2][4]和ssim_end4里的int sum0[5][4], int sum1[5][4]在数据类型上并没有什么不同，都是int[*][4]，在for语句中，循环变量x第一次+2，第二次+4，因为x变了，指针的首地址也就变了，所以每次在ssim_4x4x2_core里计算的sums虽然看似每次都是计算sums[0~1][0~3]，实际上每次计算的都是不同的4x4块的信息。理解了这个，对应的ssim_end4里的变量sum0/sum1也就可以理解了。

然后，就到了最终汇总结果，通过sums求ssim的部分：ssim_end1:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

static float ssim_end1(int s1, int s2, int ss, int s12)
{
/* Maximum value for 10-bit is: ss*64 = (2^10-1)^2*16*4*64 = 4286582784, which will overflow in some cases.
 * s1*s1, s2*s2, and s1*s2 also obtain this value for edge cases: ((2^10-1)*16*4)^2 = 4286582784.
 * Maximum value for 9-bit is: ss*64 = (2^9-1)^2*16*4*64 = 1069551616, which will not overflow. */
#if BIT_DEPTH > 9
    typedef float type;
    static const float ssim_c1 = .01 * .01 * PIXEL_MAX * PIXEL_MAX * 64;
    static const float ssim_c2 = .03 * .03 * PIXEL_MAX * PIXEL_MAX * 64 * 63;
#else
    typedef int type;
    // k1=0.01, k2=0.03
    static const int ssim_c1 = (int)(.01 * .01 * PIXEL_MAX * PIXEL_MAX * 64 + .5);
    static const int ssim_c2 = (int)(.03 * .03 * PIXEL_MAX * PIXEL_MAX * 64 * 63 + .5);
#endif
    type fs1 = s1;
    type fs2 = s2;
    type fss = ss;
    type fs12 = s12;
    type vars = fss * 64 - fs1 * fs1 - fs2 * fs2;
    type covar = fs12 * 64 - fs1 * fs2;
    return (float)(2 * fs1 * fs2 + ssim_c1) * (float)(2 * covar + ssim_c2) / ((float)(fs1 * fs1 + fs2 * fs2 + ssim_c1) * (float)(vars + ssim_c2));
}

由上文分析我们可以得知：

而我们从上篇Wiki可以知道SSIM的化简公式：

需要将这个表达式用fs1,fs2,fss,fs12变量表示。先计算均值，方差，协方差：

带入SSIM公式中，分子分母左边的项约去1/(64*64)，右边的项约去1/(63*64)：

这就是代码里的：

1

(float)(2 * fs1 * fs2 + ssim_c1) * (float)(2 * covar + ssim_c2) / ((float)(fs1 * fs1 + fs2 * fs2 + ssim_c1) * (float)(vars + ssim_c2));

不过，在这段代码中，ssim_c1理应等于0.01 * 0.01 * 255 * 255 * 64 * 64 + 0.5作者似乎少乘一个64。

以上，就是FFmpeg对SSIM的实现，读前人的代码，一开始读不懂，但越读越有深意，越读越能感受到作者的智慧与推敲的匠心。

在图像重建，压缩领域，有很多算法可以计算输出图像与原图的差距，在SSIM算法出现之前，最长用的是MSE(Mean Square Error loss)算法，他的公式很简单：

也就是计算重建后图像与输入图像的像素值差的平方和，然后在全图上求平均

但这个计算方法明显是有问题的，例如两张图片假如只是亮度不同，MSE可能很大，而一张模糊处理后的图与原图，可能MSE就很小。于是有人在Image Quality Assessment: From Error Visibility to Structural Similarity这篇论文里提出了SSIM算法。

人类在衡量两幅图的差距时，更偏重于两幅图的结构相似性，而不是像MSE那样，逐像素计算差距，SSIM就是一种基于结构相似度的度量。有两幅图x，y，他们的相似度按三个维度进行比较：亮度（luminance）l(x,y)，对比度（contrast）c(x,y)，和结构（structure）s(x,y)，最终x与y的相似度为这三者的函数：

作者设计了三个公式定量计算这三者的相似性，公式的设计遵循三个原则：

对称性：s(x,y)=s(y,x)

有界性：s(x,y)≤1

极限值唯一：s(x,y)=1 当且仅当 x = y

首先研究亮度。如果一幅图有 N 个像素点，每个像素点的像素值为xi，那么该图像的平均亮度为：

亮度相似度为：

C1是为了防止分母为零的情况，且

K1默认0.01，L是灰度动态范围，根据像素位深决定，8位的话，L=2^8-1=255

然后研究对比度，所谓对比度，就是像素值的标准差：

对比度的相似度计算公式：

其中，

第三步，通过归一化向量的关系，研究结构相似度

两个归一化向量: (x-μx)/σx和(y-μy)/σy

他们的余弦相似度：

结构相似度计算公式：

C3一般取C2/2

最后，SSIM公式：

yuv格式

在FFmpeg实现好的tiny_ssim里，视频文件是以yuv格式读入的

yuv类似于rgb，Y代表明亮度，U代表色度，V代表浓度，通常UV一起描述影像色彩和饱和度，用于指定像素的颜色。如果只有Y分量而没有UV分量，则图像就是黑白电视机里的那样。

人眼对色彩的敏感度低于对亮度的敏感度，即使适当降低色彩的采样人眼并不会有明显的感觉。所以并不是每个像素点都需要包含了 Y、U、V 三个分量，根据不同的采样格式，可以每个 Y 分量都对应自己的 UV 分量，也可以几个 Y 分量共用 UV 分量。相比 RGB，能够节约不少存储空间。

YUV图像的主流采样方式主要有三种：

• YUV 4:4:4采样
• YUV 4:2:2 采样
• YUV 4:2:0 采样

一个分量信息占8bit，也就是一个字节，假如采用444采样，则一个像素信息占3个字节。为什么叫4:4:4 , 意思就是每4个像素里的数据有4个Y， 4个U, 4个V。

在tiny_ssim中输入的yuv格式视频文件，是YUV420格式，YUV 4:2:0 并不意味着不采样 V 分量。它指的是对每条扫描线来说，只有一种色度分量以 2:1 的采样率存储，相邻的扫描行存储不同的色度分量。也就是说，如果第一行是 4:2:0，下一行就是 4:0:2，在下一行就是 4:2:0，以此类推。

YUV 数据有两种存储格式：平面格式（planar format）和打包格式（packed format）。

• planar format：先连续存储所有像素点的 Y，紧接着存储所有像素点的 U，随后是所有像素点的 V。
• packed format：每个像素点的 Y、U、V 是连续交错存储的。

YUV420有两种小类，YUV420P与YUV420SP：

• YUV420P 是基于 planar 平面模式进行存储，先存储所有的 Y 分量，然后存储所有的 U 分量或者 V 分量。

• YUV420SP 也是基于planar 平面模式存储，与 YUV420P 的区别在于它的 U、V 分量是按照 UV 或者 VU 交替顺序进行存储。

在tiny_ssim中负责输入的YUV格式，就是YUV420P的格式（也叫YV12）

FFmpeg代码里的术语

• ssd

  Sum of Squared Differences 估算值与估算对象差的平方和

• PSNR

  Peak Signal-to-Noise Ratio 峰值信噪比

  $$PSNR=10*log_{10}(\frac{MAX_I^2}{MSE})\\MAX_I=2^{bit-width}-1=255$$

• plane

  平面/分量，指Y，U，V

• stride （间距，跨距）

  • stride为什么会出现

    这个参数看起来似乎没什么用，因为它的值和图像的宽度一样。但是那是大多数情况下，一旦遇到它和宽度不一样的时候，如果你不了解它的含义，那么程序肯定要出问题。可是为什么有时候它等于宽度，有时候又不等于呢？这就和它的含义有关了。
    我们都知道现在计算机的cpu都是32位或者64位的cpu，他们一次最少读取4、8个字节，如果少于这些，反而要做一些额外的工作，会花更长的时间。所有会有一个概念叫做内存对齐，将结构体的长度设为4、8的倍数。
    间距也是因为同样的理由出现的。因为图像的操作通常按行操作的，如果图像的所有数据都紧密排列，那么会发生非常多次的读取非对齐内存。会影响效率。而图像的处理本就是一个分秒必争的操作，所以为了性能的提高就引入了间距这个概念。

  • stride的含义

    间距就是指图像中的一行图像数据所占的存储空间的长度，它是一个大于等于图像宽度的内存对齐的长度。这样每次以行为基准读取数据的时候就能内存对齐，虽然可能会有一点内存浪费，但是在内存充裕的今天已经无所谓了。

  • stride的值

    所以如果图像的宽度如果是内存对齐长度的整数倍，那么间距就会等于宽度，而现在的cpu通常一次读取都是4个字节，而我们通常见到的分辨率都是4的整数倍，所以我们通常发现间距和图像的宽度一样（这里通常指rgb32格式或者以通道表示的yuv420p格式的y通道）。但是如果遇到一些少见的分辨率时间距和图像的宽度就不一样。

变量是存储值的地方，而指针的值就是变量的地址。不是所有值都有地址，但是所有变量都有地址。通过使用指针，就可以在无需知道变量名字的情况下，间接读取/更新变量的值。

在C语言和Go中，有两个特别重要又非常容易搞混的相关运算符，一个是&，一个是*

取址运算符&

• 格式：&变量名
• 含义：取出存放变量的地址

间接运算符*

• 格式：*指针名
• 含义：取出存放在此地址中的值

举个例子：

1
2
3
4
5

x := 1
p := &x // p是整形指针，指向x
fmt.Println(*p) // "1"
*p = 2 // 等价于 x = 2
fmt.Println(x) // 结果 "2"

1
2
3
4
5
6
7
8
9
10
11
12
13
14

int main()
{
    int a = 10, *pa = &a;
    char c = '@', *pc = &c;
    pa++; // 地址值+4，因为int占4个字节
    pc++; // 地址值+1，因为char占一个字节
}
其实，也正是因为C++的指针计算功能过于强大，导致在C++中支持GC变成一个很困难的工作，假如C++支持垃圾收集，下面的代码在运行时将会变成一个严峻的考验：
```c++
int* p = new int;
p += 10; // 指针发生偏移，因此那块内存不再被引用
// 这里可能发生针对那块内存的垃圾收集
p -= 10; // 又偏移回原来位置
*p = 2; // 如果有垃圾收集，这里就无法保证正常运行

1
2
3
4
5
6

## 关于空指针
在Go语言里，指针类型的零值是nil，相当于C语言里的NULL和C++11里的nullptr，说到这里，不妨顺带谈一谈C/C++里的空指针。
在C语言里，我们使用NULL来表示空指针，如下：
```c
int *i = NULL;
foo_t *f = NULL;

1

#define NULL ((void *)0)

1
2
3
4
5

#ifdef __cplusplus
#define NULL 0
#else
#define NULL ((void *)0)
#endif

1
2
3
4
5
6
7
8
9
10
11
12

void test(void* p)
{
    cout << "pointer" << endl;
}
void test(int num) 
{
    cout << "number" << endl;
}
int main()
{
    test(NULL);
}

Go中指针与函数/方法结合

Go语言中没有类这一概念，但是可以给结构体定义方法。

在Go中，方法是一种带有接收者参数的特殊的函数。方法接收者在它的参数列表内，位于func关键字和方法名之间，例如下面这个代码，Abs方法拥有一个类型为Vertex的接收者：

1
2
3

func (v Vertex) Abs() float64 {
return math.Sqrt(v.X*v.X + v.Y*v.Y)
}

1
2
3
4
5
6

func (f int) Abs() float64 {
if f < 0 {
return float64(-f)
}
return float64(f)
}

• 方法能够修改其接收者指向的值
• 避免在每次调用方法时复制该值，较为高效

最后，关于指针和方法在使用上还有一点要注意的。

• 参数是指针的函数必须接受一个指针

  1 2 3 4 5 6 7 8

  func ScaleFunc(v *Vertex, f float64) { v.X = v.X * f v.Y = v.Y * f } var v Vertex ScaleFunc(v, 5) // 编译错误！ ScaleFunc(&v, 5) // OK

• 以指针为接收者的方法被调用时，接收者既能为值也能为指针，此时用值用指针效果一样

  1 2 3 4 5 6 7 8

  func (v *Vertex) Scale(f float64) { v.X = v.X * f v.Y = v.Y * f } var v Vertex v.Scale(5) // OK，v改变，因为Go会将语句 v.Scale(5) 解释为 (&v).Scale(5) p := &v p.Scale(10) // OK，v改变

• 参数是值的函数必须接受一个值

  1 2 3 4 5 6 7

  func AbsFunc(v Vertex) float64 { return math.Sqrt(v.X*v.X + v.Y*v.Y) } var v Vertex fmt.Println(AbsFunc(v)) // OK fmt.Println(AbsFunc(&v)) // 编译错误

• 以值为接收者的方法被调用时，接收者既能为值又能为指针，此时用值用指针效果一样

  1 2 3 4 5 6 7 8

  func (v Vertex) Abs() float64 { return math.Sqrt(v.X*v.X + v.Y*v.Y) } var v Vertex fmt.Println(v.Abs()) // OK p := &v fmt.Println(p.Abs()) // OK，这种情况下，方法调用 p.Abs() 会被解释为 (*p).Abs()

在很多高级语言中，都有“闭包”这一概念，闭包（Closure）是词法闭包（Lexical Closure）的简称。官方一点的定义是，闭包是由函数和与其相关的引用环境组合而成的实体。

闭包，严格意义上来说，只是形式上像函数，但其实不是函数。函数是一些可执行代码，这些代码在函数被定义后就已经被确定了，不会在执行时发生变化，所以一个函数只有一个实例。而闭包不同，不同的引用环境和相同的函数组合可以产生不同的实例，所以闭包在运行时可以有多个实例。所谓的引用环境，是指在程序执行中的某个点，所有处于活跃状态的约束所组成的集合。听起来复杂，通俗一点的话说，约束就是一个变量的名字和其所代表的对象时间的联系。通过闭包，函数就可以访问函数体之外的自由变量。

举个例子：

1
2
3
4
5
6
7
8
9
10
11
12

def outer_func():
    string = []
    def inner_func(s):
        string.append(s)
        print string
    return inner_func

f1 = outer_func()
f1("a")
f1("b")
f2 = outer_func()
f2("a")

也就是说，假如没有闭包，如果按照作用域规则在执行时确定一个函数的引用环境，那么这个引用环境可能和函数定义时不同，想要让这个函数正常运行，一个简单的方法就是在函数定义时捕获当时的引用环境，并与函数本体代码组成一个整体，而这个“整体”，就是闭包。可以用C语言的全局变量，Java的static变量帮助理解。

借用一个非常好的说法来做个总结：对象是附有行为的数据，而闭包是附有数据的行为。

关于自由变量和匿名函数

上文的python代码，执行结果是：

1
2
3

['a']
['a', 'b']
['a']

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

package main

import "fmt"

// 返回一个“返回int的函数”
func fibonacci() func() int {
a := 0
b := 1
return func() int {
tmp := a
a, b = b, a + b
return tmp
}
}

func main() {
f := fibonacci()
for i := 0; i < 10; i++ {
fmt.Println(f())
}
}

闭包对于编程语言特性的要求

• 函数是一阶值/一等公民（First-class value），即函数可以作为另一个函数的返回值或参数，还可以作为一个变量的值；
• 函数可以嵌套定义，即在一个函数内部可以定义另一个函数；
• 可以捕获引用环境，并把引用环境和函数代码组成一个可调用的实体；
• 允许定义匿名函数；

这些条件并不是必要的，但具备这些条件能说明一个编程语言对闭包的支持较为完善。

闭包和回调函数的区别

回调函数就是一个通过函数指针调用的函数。如果你把函数的指针（地址）作为参数传递给另一个函数，当这个指针被用来调用其所指向的函数时，我们就说这是回调函数。回调函数不是由该函数的实现方直接调用，而是在特定的事件或条件发生时由另外的一方调用的，用于对该事件或条件进行响应。简单来说，就是将一个方法对象 a 传递给另一个方法对象 b，让后者在适当的时候执行 a。

其实，回调也是闭包的一种实现形式，前面两段代码是以函数作为返回值的闭包，还可以将函数作为参数传入另一个函数实现闭包，例如下面的代码，同样是求斐波那契，但换了一种闭包形式：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

package main

import "fmt"

// 返回一个“返回int的函数”
func fibonacci(fn func()) {
for i := 0; i < 10; i++ {
fn()
}
}

func main() {
a := 0
b := 1
swap := func() {
tmp := a
a, b = b, b + tmp
fmt.Println(tmp)
}
fibonacci(swap)
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

public class Fib {
    private int a = 0;
    private int b = 1;

    private class Inner {
        void print() {
            int tmp = a;
            a = b;
            b = tmp + a;
            System.out.println(tmp);
        }
    }

    Inner getInnerInstance() {
        return new Inner();
    }

    public static void main(String[] args) {
        Fib t = new Fib();
        Inner inner = t.getInnerInstance();
        for (int i = 0; i < 10; i++) {
            inner.print();
        }
    }
}

闭包的作用和缺点

• 对于不同的闭包实例，可以进行数据的隔离，同时减少对全局变量的污染
• 闭包可以认为是附带数据的行为，这使得闭包具有较好抽象能力，可以用闭包模拟面向对象编程
• 程序语言会识别出自由变量，并将其从函数的栈内存调整到堆内存，这会给内存和GC带来压力