01.整体概述介绍

1.1 项目背景

• 通讯安全是App安全检测过程中非常重要的一项

  • 针对该项的主要检测手段就是使用中间人代理机制对网络传输数据进行抓包、拦截和篡改，以检验App在核心链路上是否有安全漏洞。

• 保证数据安全

  • 通过charles等工具可以对app的网络请求进行抓包，这样这些信息就会被清除的提取出来，会被不法分子进行利用。

• 不想被竞争对手逆向抓包

  • 不想自身App的数据被别人轻而易举地抓包获取到，从而进行类似业务或数据分析、爬虫或网络攻击等破坏性行为。

1.2 思考问题

• 开发项目的时候，都需要抓包，很多情况下即使是Https也能正常抓包正常。那么问题来了：

  • 抓包的原理是？任何Https的 app 都能抓的到吗？如果不能，哪些情况下可以抓取，哪些情况下抓取不到？

• 什么叫做中间人攻击？

  • 使用HTTPS协议进行通信时，客户端需要对服务器身份进行完整性校验，以确认服务器是真实合法的目标服务器。

  • 如果没有校验，客户端可能与仿冒的服务器建立通信链接，即“中间人攻击”。

1.3 设计目标

• 防止App被各种方式抓包

  • 做好各种防抓包安全措施，避免各种黑科技抓包。

• 沉淀为技术库复用

  • 目前只是针对App端有需要做防抓包措施，后期其他业务线可能也有这个需要。因此下沉为工具库，傻瓜式调用很有必要。

• 该库终极设计目标如下所示

  • 第一点：必须是低入侵性，对原有代码改动少，最简单的加入是一行代码设置即可。完全解耦合。

  • 第二点：可以动态灵活配置，支持配置禁止代理，支持配置是否证书校验，支持配置域名合法性过滤，支持拦截器加解密数据。

  • 第三点：可以检测App是否在双开，挂载，Xposed攻击环境

  • 第四点：可以灵活设置加解密的key，可以灵活替换加解密方式，比如目前采用RC4，另一个项目想用DES，可以灵活更换。

1.4 收益分析

• 抓包库收益

  • 提高产品App的数据安全，必须对数据传输做好安全保护措施和完整性校验，以防止自身数据在网络传输中裸奔，甚至是被三方恶意利用或攻击。

• 技能的收益

  • 下沉为功能基础库，可以方便各个产品线使用，提高开发的效率。避免跟业务解耦合。傻瓜式调用，低成本接入！

02.市面抓包的分析

2.1 Https三要素

• 要清楚HTTPS抓包的原理，首先需要先说清楚 HTTPS 实现数据安全传输的工作原理，主要分为三要素和三阶段。

• Http传输数据目前存在的问题

  • 1.通信使用明文，内容可能被窃听；2.不验证通信方的身份，因此可能遭遇伪装；3.无法证明报文的完整性，所以有可能遭到篡改。

  • 
    

• Https三要素分别是：

  • 1.加密：通过对称加密算法实现。

  • 2.认证：通过数字签名实现。（因为私钥只有 “合法的发送方” 持有，其他人伪造的数字签名无法通过验证）

  • 3.报文完整性：通过数字签名实现。（因为数字签名中使用了消息摘要，其他人篡改的消息无法通过验证）

• Https三阶段分别是：

  • 1.CA 证书校验：CA 证书校验发生在 TLS 的前两次握手，客户端和服务端通过报文获得服务端 CA 证书，客户端验证 CA 证书合法性，从而确认 CA 证书中的公钥合法性（大多数场景不会做双向认证，即服务端不会认证客户端合法性，这里先不考虑）。

  • 2.密钥协商：密钥协商发生在 TLS 的后两次握手，客户端和服务端分别基于公钥和私钥进行非对称加密通信，协商获得 Master Secret 对称加密私钥（不同算法的协商过程细节略有不同）。

  • 3.数据传输：数据传输发生在 TLS 握手之后，客户端和服务端基于协商的对称密钥进行对称加密通信。

• Https流程图如下

  • 
    

2.2 抓包核心原理

• HTTPS抓包原理

  • Fiddler、Charles等抓包工具，其实都是采用了中间人攻击的方案： 将客户端的网络流量代理到MITM(中间人)主机，再通过一系列的面板或工具将网络请求结构化地呈现出来。

• 抓包Https有两个突破点

  • CA证书校验是否合法；数据传递过程中的加密和解密。如果是要抓包，则需要突破这两点的技术，无非就是MITM(中间人)伪造证书和使用自己的加解密方式。

• 抓包的工作流程如下

  • 中间人截获客户端向发起的HTTPS请求，佯装客户端，向真实的服务器发起请求；

  • 中间人截获真实服务器的返回，佯装真实服务器，向客户端发送数据；

  • 中间人获取了用来加密服务器公钥的非对称秘钥和用来加密数据的对称秘钥，处理数据加解密。

2.3 搞定CA证书

• Https抓包核心CA证书

  • HTTPS抓包的原理还是挺简单的，简单来说，就是Charles作为“中间人代理”，拿到了服务器证书公钥和HTTPS连接的对称密钥。

  • 前提是客户端选择信任并安装Charles的CA证书，否则客户端就会“报警”并中止连接。这样看来，HTTPS还是很安全的。

• 安装CA证书到手机中必须洗白

  • 抓包应用内置的 CA 证书要洗白，必须安装到系统中。而 Android 系统将 CA 证书又分为两种：用户 CA 证书和系统 CA 证书(必要Root权限)。

• Android从7.0开始限制CA证书

  • 只有系统(system)证书才会被信任。用户(user)导入的Charles根证书是不被信任的。相当于可以理解Android系统增加了安全校验！

• 如何绕过CA证书这种限制呢？已知有以下四种方式

  • 第一种方式：AndroidManifest 中配置 networkSecurityConfig，App 信任用户 CA 证书，让系统对用户 CA 证书的校验给予通过。

  • 第二种方式：调低 targetSdkVersion < 24，不过这种方式谷歌市场有限制，意味着抓 HTTPS 的包越来越难操作。

  • 第三种方式：挂载App抓包，VirtualApp 这种多开应用可以作为宿主系统来运行其它应用，利用xposed避开CA证书校验。

  • 第四种方式：Root手机，把 CA 证书安装到系统 CA 证书目录中，那这个假 CA 证书就是真正洗白了，难度较大。

2.4 突破CA证书校验

• App版本如何让证书校验安全

  • 1.设置targetSdkVersion大于24，去掉清单文件中networkSecurityConfig文件中的system和user配置，设置不信任用户证书。

  • 2.公钥证书固定。指 Client 端内置 Server 端真正的公钥证书。在 HTTPS 请求时，Server 端发给客户端的公钥证书必须与 Client 端内置的公钥证书一致，请求才会成功。

    • 证书固定的一般做法是，将公钥证书（.crt 或者 .cer 等格式）内置到 App 中，然后创建 TrustManager 时将公钥证书加进去。

• 那么如何突破CA证书校验

  • 第一种：JustTrustMe 破解证书固定。Xposed 和 Magisk 都有相应的模块，用来破解证书固定，实现正常抓包。破解的原理大致是，Hook 创建 SSLContext 等涉及 TrustManager 相关的方法，将固定的证书移除。

  • 第二种：基于 VirtualApp 的 Hook 机制破解证书固定。在 VirtualApp 中加入 Hook 代码，然后利用 VirtualApp 打开目标应用进行抓包。具体看:VirtualHook

2.5 如何搞定加解密

• 目前使用对称加密和解密请求和响应数据

  • 加密和解密都是用相同密钥。只有一把密钥，如果密钥暴露，内容就会暴露。但是这一块逆向破解有些难度。而破解解密方式就是用密钥逆向解密，或者中间人冒充使用自己的加解密方式！

• 加密后数据镇兼顾了安全性吗

  • 不一定安全。中间人伪造自己的公钥和私钥，然后拦截信息，进行篡改。

2.6 Charles原理

• Charles类似代理服务器

  • Charles 通过将软件本身设置成系统的网络访问代理服务器，使得所有的网络请求都会走一遍 Charles 代理，从而 Charles 可以截取经过它的请求，然后我们就可以对其进行网络包的分析。

• 截取设备网络封包数据

  • Charles对应设置：将代理功能打开，并设置一个固定的端口。默认情况下，端口号为：8888 。

  • 移动设备设置：在手机上设置 WIFI 的 HTTP 代理。注意这里的前提是，Phone 和 Charles 代理设备链接的是同一网络(同一个ip地址和端口号)。

• 截取Https的网络封包

  • 正常情况下，Charles 是不能截取Https的网络包的，这涉及到 Https 的证书问题。

2.7 抓包原理图

• Charles抓包原理图

  • 
    

• Android上的网络抓包原来是这样工作的

  • Charles抓包

2.8 抓包核心流程

• 抓包核心流程关键节点

  • 第一步，客户端向服务器发起HTTPS请求，charles截获客户端发送给服务器的HTTPS请求，charles伪装成客户端向服务器发送请求进行握手 。

  • 第二步，服务器发回相应，charles获取到服务器的CA证书，用根证书（这里的根证书是CA认证中心给自己颁发的证书）公钥进行解密，验证服务器数据签名，获取到服务器CA证书公钥。然后charles伪造自己的CA证书（这里的CA证书，也是根证书，只不过是charles伪造的根证书），冒充服务器证书传递给客户端浏览器。

  • 第三步，与普通过程中客户端的操作相同，客户端根据返回的数据进行证书校验、生成密码Pre_master、用charles伪造的证书公钥加密，并生成HTTPS通信用的对称密钥enc_key。

  • 第四步，客户端将重要信息传递给服务器，又被charles截获。charles将截获的密文用自己伪造证书的私钥解开，获得并计算得到HTTPS通信用的对称密钥enc_key。charles将对称密钥用服务器证书公钥加密传递给服务器。

  • 第五步，与普通过程中服务器端的操作相同，服务器用私钥解开后建立信任，然后再发送加密的握手消息给客户端。

  • 第六步，charles截获服务器发送的密文，用对称密钥解开，再用自己伪造证书的私钥加密传给客户端。

  • 第七步，客户端拿到加密信息后，用公钥解开，验证HASH。握手过程正式完成，客户端与服务器端就这样建立了”信任“。

• 在之后的正常加密通信过程中，charles如何在服务器与客户端之间充当第三者呢？

  • 服务器—>客户端：charles接收到服务器发送的密文，用对称密钥解开，获得服务器发送的明文。再次加密， 发送给客户端。

  • 客户端—>服务端：客户端用对称密钥加密，被charles截获后，解密获得明文。再次加密，发送给服务器端。由于charles一直拥有通信用对称密钥enc_key，所以在整个HTTPS通信过程中信息对其透明。

03.防止抓包思路

3.1 先看如何抓包

• 使用Charles需要做哪些操作

  • 1.电脑上需要安装证书。这个主要是让Charles充当中间人，颁布自己的CA证书。

  • 2.手机上需要安装证书。这个是访问Charles获取手机证书，然后安装即可。

  • 3.Android项目代码设置兼容。Google 推出更加严格的安全机制，应用默认不信任用户证书（手机里自己安装证书），自己的app可以通过配置解决，相当于信任证书的一种操作！

• 尤其可知抓包的突破口集中以下几点

  • 第一点：必须链接代理，且跟Charles要具有相同ip。思路：客户端是否可以判断网络是否被代理了。

  • 第二点：CA证书，这一块避免使用黑科技hook证书校验代码，或者拥有修改CA证书权限。思路：集中在可以判断是否挂载。

  • 第三点：冒充中间人CA证书，在客户端client和服务端server之间篡改拦截数据。思路：可以做CA证书校验。

  • 第四点：为了可以在7.0上抓包，App往往配置清单文件networkSecurityConfig。思路：线上环境去掉该配置。

3.2 设置配置文件

• 一个是CA证书配置文件

  • debug包为了能够抓包，需要配置networkSecurityConfig清单文件的system和user权限，只有这样才会信任用户证书。

• 一个是检验证书配置

  • 不论是权威机构颁发的证书还是自签名的，打包一份到 app 内部，比如存放在 asset 里。然后用这个KeyStore去引导生成的TrustManager来提供证书验证。

• 一个是检验域名合法性

  • Android允许开发者重定义证书验证方法，使用HostnameVerifier类检查证书中的主机名与使用该证书的服务器的主机名是否一致。

  • 如果重写的HostnameVerifier不对服务器的主机名进行验证，即验证失败时也继续与服务器建立通信链接，存在发生“中间人攻击”的风险。

• 如何查看CA证书的数据

  • 证书验证网站 ；SSL配置检查网站

3.3 数据加密处理

• 网络数据加密的需求

  • 为了项目数据安全性，对请求体和响应体加密，那肯定要知道请求体或响应体在哪里，然后才能加密，其实都一样不论是加密url里面的query内容还是加密body体里面的都一样。

• 对数据哪里进行加密和解密

  • 目前对数据返回的data进行加解密。那么如何做数据加密呢？目前项目中采用RC4加密和解密数据。

• 抓取到的内容为乱码

  • 有的APP为了防止抓取，在返回的内容上做了层加密，所以从Charles上看到的内容是乱码。这种情况下也只能反编译APP，研究其加密解密算法进行解密。难度极大！

3.4 避免黑科技抓包

• 基于Xposed(或者)黑科技破解证书校验

  • 这种方式可以检查是否有Xposed环境，大概的思路是使用ClassLoader去加载固定包名的xp类，或者手动抛出异常然后捕获去判断是否包含Xposed环境。

• 基于VirtualApp挂载App突破证书访问权限

  • 这个VirtualApp相当于是一个宿主App(可以把它想像成桌面级App)，它突破证书校验。然后再实现挂载App的抓包。判断是否是双开环境！

04.防抓包实践开发

4.1 App安全配置

• 添加配置文件

  • android:networkSecurityConfig="@xml/network_security_config"

• 配置networkSecurityConfig抓包说明

  • 中间人代理之所有能够获取到加密密钥就是因为我们手机上安装并信任了其代理证书，这类证书安装后都会被归结到用户证书一类，而不是系统证书。

  • 那我们可以选择只信任系统内置的系统证书，而屏蔽掉用户证书（Android7.0以后就默认是只信任系统证书了），就可以防止数据被解密了。

• 实现App防抓包安全配置方式有两种：

  • 一种是Android官方提供的网络安全配置；另一种也可以通过设置网络框架实现（以okhttp为例）。

  • 第一种：具体可以看清单配置文件，相当于base-config标签下去掉 这组标签。

  • 第二种：需要给okhttpClient配置 X509TrustManager 来监听校验服务端证书有效性。遍历设备上信任的证书，通过证书别名将用户证书（别名中含有user字段）过滤掉，只将系统证书添加到验证列表中。

• 该方案优点和缺点分析说明

  • 优点：network_security_config配置简单，对整个app网络生效，无需修改代码；代码实现对通过该网络框架请求的生效，能兼容7.0以前系统。

  • 缺陷：network_security_config配置方式，7.0以前的系统配置不生效，依然可以通过代理工具进行抓包。okhttp配置的方式只能对使用该网络框架进行数据传输的接口生效，并不能对整个app生效。

  • 破解：将手机进行root，然后将代理证书放置到系统证书列表内，就可以绕过代码或配置检查了。

4.2 关闭代理

• charles 和 fiddler 都使用代理来进行抓包，对网络客户端使用无代理模式即可防止抓包，如

  OkHttpClient.Builder()
      .proxy(Proxy.NO_PROXY)
      .build()

• no_proxy实际上就是type属性为direct的一个proxy对象，这个type有三种

  • direct，http，socks。这样因为是直连，所以不走代理。所以charles等工具就抓不到包了，这样一定程度上保证了数据的安全，这种方式只是通过代理抓不到包。

• 通常情况下上述的办法有用，但是无法防住使用 VPN 导流进行的抓包

  • 使用VPN抓包的原理是，先将手机请求导到VPN，再对VPN的网络进行Charles的代理，绕过了对App的代理。

• 该方案优点和缺点分析说明

  • 优点：实现简单方便，无系统版本兼容问题。

  • 缺陷：该方案比较粗暴，将一切代理都切断了，对于有合理诉求需要使用网络代理的场景无法满足。

  • 破解：使用ProxyDroid全局代理工具通过iptables对请求进行强制转发，可以有效绕过代理检测。

4.3 证书校验(单向认证)

• 下载服务器端公钥证书

  • 为了防止上面方案可能导致的“中间人攻击”，可以下载服务器端公钥证书，然后将公钥证书编译到Android应用中一般在assets文件夹保存，由应用在交互过程中去验证证书的合法性。

• 如何设置证书校验

  • 通过OkHttp的API方法 sslSocketFactory(sslSocketFactory,trustManager) 设置SSL证书校验。

• 如何设置域名合法性校验

  • 通过OkHttp的API方法 hostnameVerifier(hostnameVerifier) 设置域名合法性校验。

• 证书校验的原理分析

  • 按CA证书去验证的，若不是CA可信任的证书，则无法通过验证。

• 单向认证流程图

  • 
    

• 该方案优点和缺点分析说明

  • 优点：安全性比较高，单向认证校验证书在代码中是方便的，安全性相对较高。

  • 缺陷：CA证书存在过期的问题，证书升级。

  • 破解：证书锁定破解比较复杂，比如老牌的JustTrustMe插件，通过hook各网络框架的证书校验方法，替换原有逻辑，使校验失效。

4.4 双向认证

• 什么叫做双向认证

  • SSL/TLS 协议提供了双向认证的功能，即除了 Client 需要校验 Server 的真实性，Server 也需要校验 Client 的真实性。

• 双向认证的原理

  • 双向认证需要 Server 支持，Client 必须内置一套公钥证书 + 私钥。在 SSL/TLS 握手过程中，Server 端会向 Client 端请求证书，Client 端必须将内置的公钥证书发给 Server，Server 验证公钥证书的真实性。

  • 用于双向认证的公钥证书和私钥代表了 Client 端身份，所以其是隐秘的，一般都是用 .p12 或者 .bks 文件 + 密钥进行存放。

• 代码层面如何做双向认证

  • 双向校验就是自定义生成客户端证书，保存在服务端和客户端，当客户端发起请求时在服务端也校验客户端的证书合法性，如果不是可信任的客户端发送的请求，则拒绝响应。

  • 服务端根据自身使用语言和网络框架配置相应证书校验机制即可。

• 双向认证流程图

  • 
    

• 该方案优点和缺点分析说明

  • 优点：安全性非常高，使用三方工具不易破解。

  • 缺陷：服务端需要存储客户端证书，一般服务端会对应多个客户端，就需要分别存储和校验客户端证书，增加校验成本，降低响应速度。该方案比较适合对安全等级要求比较高的业务（如金融类业务）。

  • 破解：由于在服务端也做校验，在服务端安全的情况下很难被攻破。

4.5 防止挂载抓包

• Xposed是一个牛逼的黑科技

  • Xposed + JustTrustMe 可以破解绕过校验CA证书。那么这样CA证书的校验就形同虚设了，对App的危险性也很大。

• App多开运行在多个环境上

  • 多开App的原理类似，都是以新进程运行被多开的App，并hook各类系统函数，使被多开的App认为自己是一个正常的App在运行。

  • 一种是从多开App中直接加载被多开的App，如平行空间、VirtualApp等，另一种是让用户新安装一个App，但这个App本质上就是一个壳，用来加载被多开的App。

• VirtualApp是一个牛逼的黑科技

  • 它破坏了Android 系统本身的隔离措施，可以进行免root hook和其他黑科技操作，你可以用这个做很多在原来APP里做不到事情，于此同时Virtual App的安全威胁也不言而喻。

• 如何判断是否具有Xposed环境

  • 第一种方式：获取当前设备所有运行的APP，根据安装包名对应用进行检测判断是否有Xposed环境。

  • 第二种方式：通过自造异常来检测堆栈信息，判断异常堆栈中是否包含Xposed等字符串。

  • 第三种方式：通过ClassLoader检查是否已经加载了XposedBridge类和XposedHelpers类来检测。

  • 第四种方式：获取DEX加载列表，判断其中是否包含XposedBridge.jar等字符串。

  • 第五种方式：检测Xposed相关文件，通过读取/proc/self/maps文件，查找Xposed相关jar或者so文件来检测。

• 如何判断是否是双开环境

  • 第一种方式：通过检测app私有目录，多开后的应用路径会包含多开软件的包名。还有一种思路遍历应用列表如果出现同样的包名，则被认为双开了。

  • 第二种方式：如果同一uid下有两个进程对应的包名，在"/data/data"下有两个私有目录，则该应用被多开了。

• 判断了具有xposed或者多开环境怎么处理App

  • 目前使用VirtualApp挂载，或者Xposed黑科技去hook，前期可以先用埋点统计。测试学而思App发现挂载在VA上是推出App。

4.5 数据加解密

• 针对数据加解密入口

  • 目前在网络请求类里添加拦截器，然后在拦截器中处理request请求和response响应数据的加密和解密操作。

• 主要是加密什么数据

  • 在request请求数据阶段，如果是get请求加密url数据，如果是post请求则加密url数据和requestBody数据。

  • 在response响应数据阶段，

• 如何进行加密：发起请求(加密)

  • 第一步：获取请求的数据。主要是获取请求url和requestBody，这一块需要对数据一块处理。

  • 第二步：对请求数据进行加密。采用RC4加密数据

  • 第三步：根据不同的请求方式构造新的request。使用 key 和 result 生成新的 RequestBody 发起网络请求

• 如何进行解密：接收返回(解密)

  • 第一步：常规解析得到 result ，然后使用RC4工具，传入key去解密数据得到解密后的字符串

  • 第二步：将解密的字符串组装成ResponseBody数据传入到body对象中

  • 第三步：利用response对象去构造新的response，然后最后返回给App

4.7 证书锁定

• 证书锁定是Google官方比较推荐的一种校验方式

  • 原理是在客户端中预先设置好证书信息，握手时与服务端返回的证书进行比较，以确保证书的真实性和有效性。

• 如何实现证书锁定

  • 有两种实现方式：一种通过network_security_config.xml配置，另一种通过代码设置；

    //第一种方式：配置文件 api.zuoyebang.cn 38JpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhK90= 9k1a0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM90K=

    //第二种方式：代码设置 fun sslPinning(): OkHttpClient { val builder = OkHttpClient.Builder() val pinners = CertificatePinner.Builder() .add("api.zuoyebang.cn", "sha256//89KpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRh00L=") .add("api.zuoyebang.com", "sha256//a8za0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1o=09") .build() builder.apply { certificatePinner(pinners) } return builder.build() }

• 该方案优点和缺点分析说明

  • 优点：安全性高，配置方式也比较简单，并能实现动态更新配置。

  • 缺陷：网络安全配置无法实现证书证书的动态更新，另外该配置也受Android系统影响，对7.0以前的系统不支持。代码配置相对灵活些。

  • 破解：证书锁定破解比较复杂，比如老牌的JustTrustMe插件，通过hook各网络框架的证书校验方法，替换原有逻辑，使校验失效

4.8 Sign签名

• 先说一下背景和问题

  • api.test.com/getbanner?k…

  • 这种方式简单粗暴，通过调用getbanner方法即可获取轮播图列表信息，但是这样的方式会存在很严重的安全性问题，没有进行任何的验证，大家都可以通过这个方法获取到数据，导致产品信息泄露。

• 在写开放的API接口时是如何保证数据的安全性的？

  • 请求来源(身份)是否合法？请求参数被篡改？请求的唯一性(不可复制)？

• 问题的解决方案设想

  • 解决方案：为了保证数据在通信时的安全性，我们可以采用参数签名的方式来进行相关验证。

• 最终决定的解决方案

  • 调用接口之前需要验证签名和有效时间，要生成一个sign签名。先拼接-后转码-再加密-再发请求！

• sign签名校验实践

  • 需要对请求参数进行签名验证，签名方式如下：key1=value1&key2=value2&key3=value3&secret=yc 。对这个字符串进行md5一下。

  • 然后被sign后的接口就变成了：api.test.com/getbanner?k…

  • 为什么在获取sign的时候建议使用secret参数？secret仅作加密使用，添加在参数中主要是md5，为了保证数据安全请不要在请求参数中使用。

• 服务端对sign校验

  • 这样请求的时候就需要合法正确签名sign才可以获取数据。这样就解决了身份验证和防止参数篡改问题，如果请求参数被人拿走，没事，他们永远也拿不到secret，因为secret是不传递的。再也无法伪造合法的请求。

• 如何保证请求的唯一性

  • api.test.com/getbanner?k…

  • 通过stamp时间戳用来验证请求是否过期。这样就算被人拿走完整的请求链接也是无效的。

• Sign签名安全性分析：

  • 通过上面的案例，安全的关键在于参与签名的secret，整个过程中secret是不参与通信的，所以只要保证secret不泄露，请求就不会被伪造。

05.架构设计说明

5.1 整体架构设计

• 如下所示

  • 
    

5.2 关键流程图

5.3 稳定性设计

• 对于请求和响应的数据加解密要注意

  • 在网络上交换数据(网络请求数据)时，可能会遇到不可见字符，不同的设备对字符的处理方式有一些不同。

  • Base64对数据内容进行编码来适合传输。准确说是把一些二进制数转成普通字符用于网络传输。统统变成可见字符，这样出错的可能性就大降低了。

5.4 降级设计

• 可以一键配置AB测试开关

  .setMonitorToggle(object : IMonitorToggle {
      override fun isOpen(): Boolean {
          //todo 是否降级，如果降级，则不使用该功能。留给AB测试开关
         return false
      }
  })

5.5 异常设计说明

• base64加密和解密导致错误问题

  • Android 有自带的Base64实现，flag要选Base64.NO_WRAP，不然末尾会有换行影响服务端解码。导致解码失败。

5.6 Api文档

• 关于初始化配置

  NotCaptureHelper.getInstance().config = CaptureConfig.builder()
          //设置debug模式
      .setDebug(true)
          //设置是否禁用代理
      .setProxy(false)
          //设置是否进行数据加密和解密，
      .setEncrypt(true)
          //设置cer证书路径
      .setCerPath("")
          //设置是否进行CA证书校验
      .setCaVerify(false)
          //设置加密和解密key
      .setEncryptKey(key)
          //设置参数
      .setReservedQueryParam(OkHttpBuilder.RESERVED_QUERY_PARAM_NAMES)
      .setMonitorToggle(object : IMonitorToggle {
          override fun isOpen(): Boolean {
              //todo 是否降级，如果降级，则不使用该功能。留给AB测试开关
             return false
          }
      })
      .build()

• 设置okHttp配置

  NotCaptureHelper.getInstance().setOkHttp(app,okHttpBuilder)

• 如何设置自己的加解密方式

  NotCaptureHelper.getInstance().encryptDecryptListener = object : EncryptDecryptListener {
      /**
       * 外部实现自定义加密数据
       */
      override fun encryptData(key: String, data: String): String {
          LoggerReporter.report("NotCaptureHelper", "encryptData data : $data")
          val str = data.encryptWithRC4(key) ?: ""
          LoggerReporter.report("NotCaptureHelper", "encryptData str : $str")
          return str
      }
      /**
       * 外部实现自定义解密数据
       */
      override fun decryptData(key: String, data: String): String {
          LoggerReporter.report("NotCaptureHelper", "decryptData data : $data")
          val str = data.decryptWithRC4(key) ?: ""
          LoggerReporter.report("NotCaptureHelper", "decryptData str : $str")
          return str
      }
  }

5.7 防抓包功能自测

• 网络请求测试

  • 正常请求，测试网络功能是否正常

• 抓包测试

  • 配置fiddler，charles等工具

  • 手机上设置代理

  • 手机上安装证书

  • 单向认证测试：进行网络请求，会提示SSLHandshakeException即ssl握手失败的错误提示，即表示app端的单向认证成功。

  • 数据加解密：进行网络请求，看一下请求参数和响应body数据是否加密，如果看不到实际json实体则表示加密成功。

防抓包库：github.com/yangchong21…

综合库：github.com/yangchong21…

视频播放器：github.com/yangchong21…

作者：杨充
来源：juejin.cn/post/7175325220109025339

重新认识自己

我一直对 NodeJS 工具方向比较感兴趣，今年终于有机会在公司内，开始工具项目的研发，调研并设计了整体架构、独立负责开发工作。

去年年末时，我刚刚来到字节半年，其实心态还没有完全转换过来，之前在创业公司，涉及了很多不同端的开发工作。所以我对自己的定位，还处于一个支持业务开发的状态，对技术渴望度足够，但对于技术路线有些许迷茫。只能看到一些比较聚焦度比较高的技术名词，例如 WASM、WebGL，会对这些技术存在追捧，却并没有做到脚踏实地。

相比去年的我，今年我对一些概念又有了许多新的见解，到底什么样才是出色的工程师？

当今国内工程师的问题

按照国内对工程师的区分，在各厂招聘列表中经常出现的是这几类，前端/后端/客户端工程师。

在我的工作中，经常会接触各端 SDK 的开发的同学，接触过程中，有时感觉到大家会存在一些 gap，也就是说 SDK 同学想去做一些事情，但是在他的角度他很明白底层逻辑，但对于其他端（前/后）同学，他们对底层原理其实并不了解。这就造成开发前，需要很长的时间去对齐功能的逻辑，合作同学也很难理解需求的意义与价值。

如果想摆脱这些困惑，那我认为你需要成为一名「全栈工程师」，其实说是全栈，不如是「软件工程师」，作为一名工程师，需要拥有一些闭环整体开发流程的能力。

例如，以 SDK 开发的角度来说，对于 SDK 同学，实际上最终只负责到上报这个动作，至于之后数据的流向，以及数据清洗，并不在掌控的范畴之内。这虽然降低了 SDK 侧上手的门槛，但并不利于长期的维护。

假如你是一个软件工程师，对于以下流程，你都了如指掌：

数据上报 -> 清洗 -> 存储 -> 消费

那你对于系统的整体认知就会提升，从优化上，可以给出更好的建议；在排查问题时，也可以更快速的定位问题。

何为工程师？

下面我详细谈一谈，如何成为一个有宏观视角的工程师。

首先，我目前的关注点主要在前端方向，如果你有仔细观察，你可以看到最终大部分比较厉害的前端，都是具有一些全栈能力的人。

对于服务端层面，我的建议是把 Golang 学好，这是一个还不错的方向。一个技术栈，如果有很多人关注聚焦，广泛地提出问题，那它的发展前景一定是不错的，起码不会垮掉，也就是说，开发生态是健康的。

对于前端层面，如果想去把前端学的很深入的话，那么前端工具以及工程化，必不可少。

在这一年内，我扩展一些自己原本不是很擅长的领域：

• 产品

  • 竞品调研

  • PRD 撰写

• 服务端方向

  • MySQL

  • Rust

  • Golang

• 前端方向

  • 单测/e2e：Jest、@testing-library/react、Cypress

  • 工程化：Rush.js、Pnpm、Webpack、TypeScript

  • 工具：Babel、CLI 相关的 npm 包工具

  • 插件：Chrome、VSCode

• 设计

  • Figma 学习

• 英语学习

除了开发角色，一个合格的工程师，还应该掌握技术方案设计的能力，这样可以将整体的开发流程闭环。也就是说一个人扮演，调研、方案设计、编码、测试的工作。从我的 Roadmap 中，你也可以看出来这一点。为什么要闭环呢，当一个需求，有越来越多的角色参与进来的时候，你会发现方案细节的对齐，变成了一个不简单的工作。

有时候我们经常会讲一个词，融会贯通。当你把一整套研发体系都吃下来的时候，你会发现可以顺利地解决掉项目的问题。

我的工作场景

在我的工作中，会涉及到工具链的开发。首先在开始前，需要做一些竞品调研，方案设计的工作。

开发环节，对前端来说，按照目前的趋势，我们更好的方式是以 Monorepo 的形式去做开发。这里 Pnpm 就是一个很不错的选择，但接下来你会遇到一些问题，例如如何去做这些包的发版编排？

由于在 Workspace 中会存在一些包之间的相互引用，在发版时，也要按照拓扑排序的方式进行发版，这时，我们就可以用到 Rush.js 去做拓扑发版，以及自动生成 Changelog。

工具链对于质量需要较强的把控，这时我们就要引入 Jest 做单测，但一些场景下，单测是不够的，这时我们需要引入 e2e 测试。

在 Monorepo 中，不像单仓中，可能只存在一个 tsconfig，这时会存在配置之间 extends 的关系，需要我们对 tsconfig 的配置了如指掌。

对于多种工具消费方式，例如 CLI、Chrome 插件等，实则需要公用一些方法与配置，这里就需要抽象出公用的 utils 等。

在开发中，可能会关注一些新闻，比如 Vite 4 启用了 SWC 替代 Babel做编译。那你是否有好奇过，为什么 SWC 会更快，这时候如果学过 Rust，就知道 Rust 特有的语言特性。

总结

我想说的是，作为一个工程师，不要去把自己划分为「前端/后端/ PM」这些更加细分的角色。你都可以去学习任何方面的知识。并且你学的一切知识，都是有意义的。虽然学习的道路很长，但只要坚持下去，你就会朝着优秀的工程师进发。

作者：EricLee
来源：juejin.cn/post/7181000277208760378

什么年代了还在用传统账号密码登录？没钱买手机号验证码组合？直接把鉴权和用户系统全盘托出依赖第三方（又不是不能用），省去鉴权系列 SQL 攻击、密码加密、CSRF 攻击、XSS 攻击，老板再也不用担心黑产盗号了（我们的系统根本没有号）

要实现上面的功能就得接入第三方登录，接下来就随着文章一起试试吧！

github

本章节将使用 github 作为第三方登录服务提供商

github 不愧是阿美力卡之光，极其简便的操作即可开启你的第三方登录之旅，经济又实惠，你可以通过快捷链接进入创建 OAuth 应用界面，也可以按照下面的顺序

然后填写相应的信息

生成你的密钥（Client secrets），就可以去试试第三方登录了

组合 URL

您可以在线查看本章节源代码

这里我使用的是 express-generator 去生成项目，并且前后端分离，在选项上不需要 HTML 渲染器

npx express --no-view your-project-path && cd your-project-path

前端部分简单设置一下跳转验证

<html>
  <body>
    <div>
      第三方登录
      <br />
      <button onclick="handleGithubLoginClick()">github</button>
    </div>
  </body>
  <script>
    const handleGithubLoginClick = () => {
      const state = Math.floor(Math.random() * Math.pow(10, 8));
      localStorage.setItem("state", state);
      window.open(
        `https://github.com/login/oauth/authorize?client_id=b351931efd1203b2230e&redirect_uri=http://localhost:8080&state=${state}`,
        "_blank"
      );
    };
  </script>
</html>

其中有三个比较重要的 params

1. client_id - string - “必需”。 注册时从 GitHub 收到的客户端 ID。

2. redirect_uri - string - 用户获得授权后被发送到的应用程序中的 URL。 请参阅以下有关重定向 URL 的详细信息。

3. state - string - 不可猜测的随机字符串。 它用于防止跨站请求伪造攻击。

redirect_uri 默认是注册 OAuth 应用（Register a new OAuth application）是填写的授权回调 URL（Authorization callback URL）

而对于 state 就在前端用随机字符串模拟，通常此类加密的敏感数据会再后端生成，而这里为了方便演示就采用了前端生成

详细参数请参考文档

鉴权验证

登录之后就可以进行相对应的验证，比如输入账号密码、授权、Github 客户端验证

成功鉴权后会再新弹出的页面重定向至 redirect_uri

注意要在属于用户操作的范畴下，比如点击按钮的操作，去使用 window.open(strUrl, strWindowName, [strWindowFeatures]) 这种方式去跳转鉴权，否则像 window.open("https://github.com...", "_blank") 这种常见的写法，会报错

浏览器会以为是弹窗式广告，所以我推荐使用直接在当前窗口跳转的方法，而不是选择新开窗口或者浮动窗口

window.location.href = "https://github.com/login/oauth/authorize?client_id=b351931efd1203b2230e&redirect_uri=http://localhost:8080";

处理回调

通过用户授权时，Github 的响应如下

GET redirect_uri

参数

state 参数负责安全非常重要，想要快速通关的选手可以跳过这部分

对于这里的 state 处理可以分为前端处理和后端处理

前端处理

当 redirect_uri 是前端路由时，可以将之前提交的 state 从 localStorage 或者 sessionStorage 中取出，验证是否一致，再去向后端请求并带上 state 和 code

优点

1. 无需缓存 state

缺点

1. 需要防止 XSS 的 DOM 型攻击

后端处理

当 redirect_uri 是后端时，后端需要持有 state 的缓存，具体做法可以在前端处理第三方登录时同步随机生成的 state，并在后端缓存

优点

1. 不需要防止 XSS 的 DOM 型攻击

缺点

1. 需要缓存 state

科普：早期 token 其实就是这里的 state

获取 token

第三方登录从本质上来讲就是获取到 token，在安全的拿到 code 和 state 之后，需要向 github 发送获取 token 请求，其文档如下

POST https://github.com/login/oauth/access_token

参数

响应

注意因为 client_secret 属于私钥，所以该请求必须放在后端，不能在前端请求！否则会失去登录的意义

const { default: axios } = require("axios");
const express = require("express");
const router = express.Router();

router.post("/redirect", function (req, res, next) {
  const { code } = req.body;
  axios({
    method: "POST",
    url: "https://github.com/login/oauth/access_token",
    headers: {
      "Accept": "application/json",
    },
    timeout: 60 * 1000,
    data: {
      client_id: "your_client_id",
      client_secret: "your_client_secret",
      code,
    },
  })
    .then((response) => {
      res.send(response.data);
    })
    .catch((e) => {
      res.status(404);
    });
});

module.exports = router;

注意，由于 github 的服务器在国外，所以这个请求非常容易超时或者失效，建议做好对应的处理（或者设置一个比较长的时间）

最后拿到对应的 token

总结

如果还没有了解过第三方登录的同学可以试试，毕竟不需要审核，有对应的 github 账号就行，截至写完文章的现在，我仍然没有通过微博第三方登录的审核/(ㄒoㄒ)/~~

参考资料

1. 授权 OAuth 应用 - Github Docs

2. 给你的网站添加第三方登录以及短信验证功能

作者：2分钟速写快排
来源：juejin.cn/post/7181114761394782269

当前技术社区中出现了各种下一代技术或框架，却很少有当代可以用的，于是electron-egg就出现了。

它愿景很大：希望所有开发者都能学会桌面软件开发

当前桌面软件技术有哪些？

为什么使用electron？

某某说：我们的应用要兼容多个平台，原生开发效率低，各平台研发人员不足，我们没有资源。

也许你觉得只是中小公司没有资源，no！大公司更没有资源。因为软件体量越大，所需研发人员越多。再加上需要多平台支持的话，研发人员更是指数级增长的。

我们来看看QQ团队负责人最近的回应吧：

“感谢大家对新版桌面QQ NT的使用和关注，今年QQ团队启动了QQ的架构升级计划，第一站就是解决目前桌面端迭代慢的问题，我们使用新架构从前到后对QQ代码进行了重构，而其中选择使用Electron作为新版QQ桌面端UI跨平台解决方案，是基于提升研发效率、框架成熟度、团队技术及人才积累等几个方面综合考虑的结果。”

也许electron的缺点很明显，但它的投入产出比却是最高的。

所以，对企业而言，效率永远是第一位的。不要用程序员的思维去思考产品。

哪些企业或软件在使用electron？

国内：抖音客户端、百度翻译、阿里云盘、B站客户端、迅雷、网易有道云、QQ(doing) 等

国外：vscode、Slack、Atom、Discord、Skype、WhatsApp、等

你的软件用户体量应该没有上面这些公司多吧？所以你还有什么可担心的呢？

开发者 / 决策者不要去关心性能、包体大小这些东西，当你的产品用户少时，它没意义；当你的产品用户多时，找nb的人把它优化。

聊聊electron-egg框架

EE是一个业务框架；就好比 Spring之于java，thinkphp之于php，nuxt.js之于vue；electron只提供了基础的函数和api，但你写项目的时候，业务和代码工程化是需要自己实现的，ee就提供了这个工程化能力。

特性

• 🍄 跨平台：一套代码，可以打包成windows版、Mac版、Linux版、国产UOS、Deepin、麒麟等

• 🌹 简单高效：只需学习 js 语言

• 🌱 前端独立：理论上支持任何前端技术，如：vue、react、html等等

• 🌴 工程化：可以用前端、服务端的开发思维，来编写桌面软件

• 🍁 高性能：事件驱动、非阻塞式IO

• 🌷 功能丰富：配置、通信、插件、数据库、升级、打包、工具... 应有尽有

• 🌰 安全：支持字节码加密、压缩混淆加密

• 💐 功能demo：桌面软件常见功能，框架集成或提供demo

谁可以使用electron-egg？

前端、服务端、运维、游戏等技术人员皆可使用。我相信在你的工作生涯中，或多或少都接触过js，恭喜你，可以入门了。

为什么各种技术栈的开发者都能使用electron-egg？

这与它的架构有关。

第一：前端独立

你可以用vue、react、angular等开发框架；也可用antdesign、layui、bootstrap等组件库；或者你用cococreater开发游戏也行； 框架只需要最终构建的资源（html/css/js）。

第二：工程化-MVC编程模式

如果你是java、php、python等后端开发者，不懂js那一套编程模式怎么办？

没关系，框架已经为你提供了MVC（controller/service/model/view），是不是很熟悉？官方提供了大量业务场景demo，直接开始撸代码吧。

开箱即用

编程方法、插件、通信、日志、数据库、调试、脚本工具、打包工具等开发需要的东西，框架都已经提供好了，你只需要专注于业务的实现。

十分钟体验

安装

# 下载
git clone https://gitee.com/dromara/electron-egg.git

# 安装依赖
npm install

# 启动
npm run start

效果

界面中的功能是demo，方便初学者入门。

项目案例

EE框架已经应用于医疗、学校、政务、股票交易、ERP、娱乐、视频、企业等领域客户端

以下是部分开发者使用electron-egg开发的客户端软件，请看效果

后语

仓库地址，欢迎给项目点赞！

gitee ： gitee.com/dromara/ele… 2300+

github ： github.com/dromara/ele… 500+

关于 Dromara

Dromara 是由国内顶尖的开源项目作者共同组成的开源社区。提供包括分布式事务，流行工具，企业级认证，微服务RPC，运维监控，Agent监控，分布式日志，调度编排等一系列开源产品、解决方案与咨询、技术支持与培训认证服务。技术栈全面开源共建、 保持社区中立，致力于为全球用户提供微服务云原生解决方案。让参与的每一位开源爱好者，体会到开源的快乐。

Dromara开源社区目前拥有10+GVP项目，总star数量超过十万，构建了上万人的开源社区，有成千上万的个人及团队在使用Dromara社区的开源项目。

electron-egg已加入dromara组织。

作者：哆啦好梦
来源：juejin.cn/post/7181279242628366397

无论你玩不玩贴吧，“弱智吧”的大名很多人应该听说过。

如今弱智吧的关注人数已经超过了200万。。。

不得不说，能将这么多“弱智”聚在一起，“弱智吧”撑起了后·百度贴吧时代的辉煌。。。

来一起感受下“弱智吧”的日常：

能问出这些问题，确实脑回路已经超越普通人了。。。

弱智吧的存在已经够离谱了，更离谱的是，弱智吧官方微博把这几天火出圈的ChatGPT与“弱智吧”做了连接——让ChatGPT去回答弱智吧上的问题。

真是离谱他爸给离谱开门，离谱到家了。。。

“弱智”与“弱AI”的较量，从此揭开了序幕。来，一起感受下！

弱智提问1

弱智提问2

这个回答属实有点“社交牛逼症”了。我觉得别再沉溺于图灵测试了，这已经满足不了ChatGPT了。笔者觉得有必要直接给ChatGPT测下情商

弱智提问3

这个回答，让笔者一时分不清ChatGPT是认真的还是故意的。。。

弱智提问4

弱智提问5

弱智提问6

我已经20多岁了，还能开写轮眼吗？

弱智提问7

弱智提问8

突然不知道该怎么反驳，我果然既不如弱智，也不如AI

弱智提问9

弱智提问10

弱智提问11

弱智提问12

弱智提问13

AI，这波是你输了

弱智提问14

我觉得这波AI赢了

那么问题来了，你认为是人类创造的“弱智问题”赢了？还是AI创造的“机智回答”赢了？

最后，笔者还找了一些弱智吧的牛逼问题，手里有ChatGPT账号的读者小伙伴可以在评论区分享测试结果：

开放问题1

开放问题2

开放问题3

作者：兔子酱
来源：夕小瑶的卖萌屋

前言

  本文是笔者在日常开发过程中遇到的对 CAS 、 ABA 问题以及 JUC（java.util.concurrent）中 AtomicReference 相关类的设计的一些思考记录。 对需要处理 ABA 问题，或有诸如笔者一样的设计疑问探索好奇心的读者可能会带来一些启发。

本文主体由三部分构成：

1. 首先阐述多线程场景数据同步的常用语言工具

2. 接着阐述什么是 ABA 问题，以及产生的原因和可能带来的影响

3. 再探索 JUC 中官方为解决 ABA 问题而做一些工具类设计

文章的最后会对多线程数据同步常用解决方案做了简短地经验性总结与概括。

受限于笔者的理解与知识水平，文章的一些术语表述难免可能会失偏颇，对于有理解歧义或争议的部分，欢迎大家探讨和指正。

一、异步场景常用工具

在Java中的多线程数据同步的场景，常会出现：

1. 关键字 volatile

2. 关键字 synchronized

3. 可重入锁/读写锁 java.util.concurrent.locks.*

4. 容器同步包装，如 Collections.synchronizedXxx()

5. 新的线程安全容器，如 CopyOnWriteArrayList/ConcurrentHashMap

6. 阻塞队列 java.util.concurrent.BlockingQueue

7. 原子类 java.util.concurrent.atomic.*

8. 以及 JUC 中其他工具诸如 CountDownLatch/Exchanger/FutureTask 等角色。

  其中 volatile 关键字用于刷新数据缓存，即保证在 A 线程修改某数据后，B 线程中可见，这里面涉及的线程缓存和指令重排因篇幅原因不在本文探讨范围之内。而不论是 synchronized 关键字下的对象锁，还是基于同步器 AbstractQueuedSynchronizer 的 Lock 实现者们，它们都属于悲观锁。而在同步容器包装、新的线程程安全容器和阻塞队列中都使用的是悲观锁；只是各类的内部使用不同的 Lock 实现类和 JUC 工具，另外不同容器在加锁粒度和加锁策略上分别做了处理和优化。

  这里值得一说的，也是本文聚焦的重点则是原子类，即 java.util.concurrent.atomic.* 包下的几个类库诸如 AtomicBoolean/AtomicInteger/AtomicReference

二、CAS 与 ABA 问题

  我们知道在使用悲观锁的场景中，如果有有一个线程抢先取得了锁，那么其他想要获得锁的线程就得被阻塞等待，直到占锁线程完成计算释放锁资源。而现代 CPU 提供了硬件级指令来实现同步原语，也就是说可以让线程在运行过程中检测是否有其他线程也在对同一块内存进行读写，基于此 Java 提供了使用忙循环来取代阻塞的系列工具类 AutomicXxx，这属于是一种乐观锁的实现。其常规使用方式形如：

public class Requester {
    private AtomicBoolean isRequesting = new AtomicBoolean(false)

    public void request() {
        // 修改成功时返回true；compareAndSet 方法由 Native 层调硬件指令实现
        if (!isRequesting.compareAndSet(false, true)) {
            return;
        }
        try {
            // do sth...
        } finally {
            isRequesting.set(false)
        }
    }
}

  进入到 JDK11 AtomicBoolean 的源码中，可以看到 compareAndSet 最终调用 Native 层的方式如下。其实在旧的版本中 JDK 是使用 Unsafe 类处理的，在入参数中有传入状态变量的字段偏移值，新版本则将两者封装到 VarHandle 中采用DL方式查找依赖（笔者猜测可能和JDK9模块化改造有关）：

// 旧版
public class AtomicBoolean {
    private static final sun.misc.Unsafe U = sun.misc.Unsafe.getUnsafe();
    private static final long VALUE;
    static {
        try {
            VALUE = U.objectFieldOffset
                (AtomicBoolean.class.getDeclaredField("value"));
        } catch (ReflectiveOperationException e) {
            throw new Error(e);
        }
    }

    private volatile int value;

    public final boolean compareAndSet(boolean expect, boolean update) {
        return U.compareAndSwapInt(this, VALUE, (expect ? 1 : 0), (update ? 1 : 0));
    }
}

// 新版
public class AtomicBoolean {
    private static final VarHandle VALUE;
    static {
        try {
            MethodHandles.Lookup l = MethodHandles.lookup();
            VALUE = l.findVarHandle(AtomicBoolean.class, "value", int.class);
        } catch (ReflectiveOperationException e) {
            throw new ExceptionInInitializerError(e);
        }
    }

    private volatile int value;

    public final boolean compareAndSet(boolean expectedValue, boolean newValue) {
        return VALUE.compareAndSet(this, (expectedValue ? 1 : 0), (newValue ? 1 : 0));
    }
}

  犹如入仓有 this 和 value 的偏移值，则 Native 层可根据此二者值定位到某块栈内存，这样对于基本类型没什么问题。原子类型体系中使用 AtomicReference 来引用复合类型实例，但 Java 中 Object 类型在栈中保存的只是堆中对象数据块的地址，其结构形如下图：

  而实际运行过程中，调用 AtomicReference#compareAndSet() 时，Native层只会对比栈中内存的值，而不会关注其指向的堆中数据。这样说可能有点抽象，看一段实验代码：

StringBuilder varA = new StringBuilder("abc");
StringBuilder varB = new StringBuilder("123");

AtomicReference<StringBuilder> ref = new AtomicReference<>(varA);
ref.compareAndSet(varA, varB); // (1)
System.out.println(ref.get()); // (2) varB->123
varB.append('4'); // (3) changed varB->1234
if (ref.compareAndSet(varB, varA)) { // (4)
    System.out.println("CAS succeed"); // (5) CAS succeed
}
System.out.println(ref.get()); // abc

喜欢动手的读者可以尝试自定义一个类，观察下 Compare 过程是否真的没有调用对象的 equals 方法。

  ref 在经过处理后再 (2) 处引用变量B，而在注释 (3) 处将 B 值修改了，但由于原子类不会检查堆中数据，所以还是能通过注释 (4) 处的相等比较走到注释 (5) 。这也就引入了 所谓的 ABA 问题：

1. 假设，线程 1 的任务希望将变量从 A 变为 C ，但执行到一半被线程 2 抢走 CPU

2. 线程 2 将变量从 A 改成了 B ，此时 CPU 时间片又被系统分给了线程 3

3. 线程 3 讲变量从 B 又设置成一个新的 A 。

4. 线程 1 获取时间片，检查变量发现其仍然是 A（但 A 对象内部的数据已经改变了），检查通过将变量置为 C 。

  若业务场景中，线程 1 不在意变量经过了一轮变化，也不在意 A 中数据是否有变化，则该问题无关痛痒。而若线程 1 对这两个变化敏感，则将变量置为 C 的操作就不符合预期了。用维基百科的例子来表述，其大意是:

你提着有很多现金的包去机场，这时来了个辣妹挑逗你，并趁你不注意时用一个看起来一样的空包换了你的现金包，然后她就走了；此时你检查了下发现你的包还在，于是就匆忙拿着包赶飞机去了。

换个角度看这几个关键字:

• 有现金的包：指向堆中数据的栈引用

• 辣妹挑逗：其他线程抢占 CPU

• 看起来一样空包：其他线程修改堆中数据

• 发现包还在：仅检查栈中内存的地址值是否一致

三、用 JUC 工具处理 ABA 问题

  为处理 ABA 问题，JDK 提供了另外两个工具类：AtomicMarkableReference 和 AtomicStampedReference 他们除了对比栈中对象的引用地址外，另外还保存了一个 boolean 或 int 类型的标记值，用于 CAS 比较。

StringBuilder varA = new StringBuilder("abc");
StringBuilder varB = new StringBuilder("123");

AtomicStampedReference<StringBuilder> ref = new AtomicStampedReference<>(varA, varA.toString().hashCode());
ref.compareAndSet(varA, varB, varA.toString().hashCode(), varB.toString().hashCode());
System.out.println(ref.get(new int[1]));
varB.append('4');
// CAS失败，因为Stamp值对不上
if (ref.compareAndSet(varB, varA, varB.toString().hashCode(), varA.toString().hashCode())) {
    System.out.println("compareAndSet: succeed");
}
System.out.println(ref.get(new int[1]));

注：这种设计和为快速判断文件是否相同，而比较文件摘要值（MD5、SHA值）和预期是否一致的思想倒有异曲同工之妙。

总结

  通常在多线程场景中，这些工具的应用场景具有各自的适用特征：

1. 若各线程读写数据没有竞争关系，则可考虑仅使用 volatile 关键字；

2. 若各线程对某数据的读写需要去重，则可优先考虑使用乐观锁实现，即用原子类型；

3. 若各线程有竞争关系且不去重必须按顺序抢占某资源，即必须用锁阻塞，若没有多条件队列的诉求则可先考虑使用 synchronized 添加对象锁（但需注意锁对象的不可变和私有化），否则考虑用 Lock 实现类，但特别的如需读写分锁以实现共享锁则只能用 Lock 了。

4. 若需使用线程安全容器，出于性能考虑优先考虑 java.util.concurrent.* 类，如 ConcurrentHashMap、CopyOnWriteArrayList；再考虑使用容器同步包装 Collections.synchronizedXxx()。而阻塞队列则多用于生产-消费模型中的任务容器，典型如用在线程池中。

作者：Chavin
来源：juejin.cn/post/7181077489211408443

废话开篇：一些 404 页面为了体现趣味性会添加一些简单的交互效果。 这里用纯 JS 简单实现类似 404 可跳跃障碍物页面，内容全部用 canvas 画布实现。

一、效果展示

二、画面拆解

1、绘制地平线

地平线这里就是简单的一条贯穿屏幕的线。

2、绘制红色精灵

绘制红色精灵分为两部分：

（1）上面圆

（2）下面定点与上面圆的切线。

绘制结果：

进行颜色填充，再绘制中小的小圆，绘制结果：

（3）绘制障碍物

这里绘制的是一个黑色的长方形。最后的实现效果：

三、逻辑拆解

1、全局定时器控制画布重绘

创建全局的定时器。

它有两个具体任务：

（1）全局定时刷新重置，将画布定时擦除之前的绘制结果。

（2）全局定时器刷新动画重绘新内容。

2、精灵跳跃动作

在接收到键盘 “空格” 点击的情况下，让精灵起跳一定高度，到达顶峰的时候进行回落，当然这里设计的是匀速。

3、障碍物移动动作

通过定时器，重绘障碍物从最右侧移动到最左侧。

4、检测碰撞

在障碍物移动到精灵位置时，进行碰撞检测，判断障碍物最上端的左、右顶点是否在精灵的内部。

5、绘制提示语

提示语也是用 canvas 绘制的，当障碍物已移动到左侧的时候进行，结果判断。如果跳跃过程中无碰撞，就显示 “完美跳跃～”，如果调跃过程中有碰撞，就显示 “再接再厉”。

四、代码讲解

1、HTML

<!DOCTYPE html>
<html>
    <head>
        <meta charset="utf-8">
        <title></title>
        <script src="./wsl404.js"></script>
    </head>
    <body>
        <div id="content">
            <canvas id="myCanvas">
            </canvas>
        </div>
    </body>
    <script>
        elves.init();
    </script>
</html>

2、JS

(function WSLNotFoundPage(window) {
    var elves = {};//精灵对象
    elves.ctx = null;//画布
    elves.width = 0;//屏幕的宽度
    elves.height = 0;//屏幕的高度
    elves.point = null;//精灵圆中心
    elves.elvesR = 20;//精灵圆半径
    elves.runloopTargets = [];//任务序列（暂时只保存跳跃）
    elves.upDistance = 50;//当前中心位置距离地面高度
    elves.upDistanceInitNum = 50;//中心位置距离地面高度初始值
    elves.isJumping = false;//是否跳起
    elves.jumpTarget = null;//跳跃任务
    elves.jumpTop = false;//是否跳到最高点
    elves.maxCheckCollisionWith = 0;//碰撞检测的最大宽度尺寸
    elves.obstaclesMovedDistance = 0;//障碍物移动的距离
    elves.isCollisioned = false;//是否碰撞过
    elves.congratulationFont = 13;//庆祝文字大小
    elves.congratulationPosition = 40;//庆祝文字位移
    elves.isShowCongratulation = false;//是否展示庆祝文字
    elves.congratulationContent = "完美一跃～";
    elves.congratulationColor = "red";
    
    //初始化
    elves.init = function(){
        this.drawFullScreen("content");
        this.drawElves(this.upDistance);
        this.keyBoard();   
        this.runloop();
    }
    
    //键盘点击事件
    elves.keyBoard = function(){
        var that = this;
        document.onkeydown = function whichButton(event)
        {
          if(event.keyCode == 32){
            //空格
            that.elvesJump();
           }
         }
    }
    
    //开始跑圈
    elves.runloop = function(){
        var that = this;
        setInterval(function(){
            //清除画布
            that.cleareAll();
            //绘制障碍物
            that.creatObstacles();
            if(that.isJumping == false){
                //未跳起时重绘精灵
                that.drawElves(that.upDistanceInitNum);
            }
            //绘制地面
            that.drawGround();
            
            //跳起任务
            for(index in that.runloopTargets){
                let target = that.runloopTargets[index];
                if(target.isRun != null && target.isRun == true){
                    
                    if(target.runCallBack){
                        target.runCallBack();
                    }
                }
            }
            //碰撞检测
            that.checkCollision();
            //展示庆祝文字
            if(that.isShowCongratulation == true){
                that.congratulation();
            }
            
        },10);
    }
    
    //画布
    elves.drawFullScreen = function (id){
        var element = document.getElementById(id);
        this.height = window.screen.height - 200;
        this.width = window.screen.width;
        element.style.width = this.width + "px";
        element.style.height = this.height + "px";
        element.style.background = "white";
        this.getCanvas("myCanvas",this.width,this.height);
    }
    
    elves.getCanvas = function(id,width,height){
        var c = document.getElementById(id);
        this.ctx = c.getContext("2d");
        //锯齿修复
        if (window.devicePixelRatio) {
           c.style.width = this.width + "px";
           c.style.height = this.height + "px";
           c.height = height * window.devicePixelRatio;
           c.width = width * window.devicePixelRatio;
           this.ctx.scale(window.devicePixelRatio, window.devicePixelRatio);
        }
    };
    
    //绘制地面
    elves.drawGround = function() {
        // 设置线条的颜色
        this.ctx.strokeStyle = 'gray';
        // 设置线条的宽度
        this.ctx.lineWidth = 1;
        // 绘制直线
        this.ctx.beginPath();
        // 起点
        this.ctx.moveTo(0, this.height / 2.0 + 1);
        // 终点
        this.ctx.lineTo(this.width,this.height / 2.0);
        this.ctx.closePath();
        this.ctx.stroke();
    }
    
    //绘制精灵
    elves.drawElves = function(upDistance){
        
        //绘制圆
        var angle = Math.acos(this.elvesR / upDistance);
        this.point = {x:this.width / 3,y : this.height / 2.0 - upDistance};
        this.ctx.fillStyle = "#FF0000";
        this.ctx.lineWidth = 1;
        this.ctx.beginPath();
        this.ctx.arc(this.point.x,this.point.y,this.elvesR,Math.PI / 2 + angle,Math.PI / 2 - angle,false);
        
        //绘制切线
        var bottomPoint = {x:this.width / 3,y : this.point.y + this.upDistanceInitNum};
        
        let leftPointY = this.height / 2.0 - (upDistance - Math.cos(angle) * this.elvesR);
        let leftPointX = this.point.x - (Math.sin(angle) * this.elvesR);
        var leftPoint = {x:leftPointX,y:leftPointY};
        
        let rightPointY = this.height / 2.0 - (upDistance - Math.cos(angle) * this.elvesR);
        let rightPointX = this.point.x + (Math.sin(angle) * this.elvesR);
        var rightPoint = {x:rightPointX,y:rightPointY};
        
        this.maxCheckCollisionWith = (rightPointX - leftPointX) * 20 / (upDistance - Math.cos(angle) * this.elvesR);
        this.ctx.moveTo(bottomPoint.x, bottomPoint.y);
        this.ctx.lineTo(leftPoint.x,leftPoint.y);
        this.ctx.lineTo(rightPoint.x,rightPoint.y);
        
        this.ctx.closePath();
        this.ctx.fill();
        
        //绘制小圆
        this.ctx.fillStyle = "#FFF";
        this.ctx.lineWidth = 1;
        this.ctx.beginPath();
        this.ctx.arc(this.point.x,this.point.y,this.elvesR / 3,0,Math.PI * 2,false);
        this.ctx.closePath();
        this.ctx.fill();
    }
    
    //清除画布
    elves.cleareAll = function(){
        this.ctx.clearRect(0,0,this.width,this.height);
    }
    
    //精灵跳动
    elves.elvesJump = function(){
        if(this.isJumping == true){
            return;
        }
        this.isJumping = true;
        if(this.jumpTarget == null){
            var that = this;
            this.jumpTarget = {type:'jump',isRun:true,runCallBack:function(){
                let maxDistance = that.upDistanceInitNum + 55;
                if(that.jumpTop == false){
                    if(that.upDistance > maxDistance){
                        that.jumpTop = true;
                    }
                    that.upDistance += 1;
                } else if(that.jumpTop == true) {
                    that.upDistance -= 1;
                    if(that.upDistance < 50) {
                        that.upDistance = 50;
                        that.jumpTop = false;
                        that.jumpTarget.isRun = false;
                        that.isJumping = false;
                    }
                }
                that.drawElves(that.upDistance);
            }};
            this.runloopTargets.push(this.jumpTarget);
        } else {
            this.jumpTarget.isRun = true;
        }
    }
    
    //绘制障碍物
    elves.creatObstacles = function(){
        let obstacles = {width:20,height:20};
        if(this.obstaclesMovedDistance != 0){
            this.ctx.clearRect(this.width - obstacles.width - this.obstaclesMovedDistance + 0.5, this.height / 2.0 - obstacles.height,obstacles.width,obstacles.height);
        }
        this.obstaclesMovedDistance += 0.5;
        if(this.obstaclesMovedDistance >= this.width + obstacles.width) {
            this.obstaclesMovedDistance = 0; 
            //重置是否碰撞
            this.isCollisioned = false;
        }
        this.ctx.beginPath();
        this.ctx.fillStyle = "#000";
        this.ctx.moveTo(this.width - obstacles.width - this.obstaclesMovedDistance, this.height / 2.0 - obstacles.height);
        this.ctx.lineTo(this.width - this.obstaclesMovedDistance,this.height / 2.0 - obstacles.height);
        this.ctx.lineTo(this.width - this.obstaclesMovedDistance,this.height / 2.0);
        this.ctx.lineTo(this.width - obstacles.width - this.obstaclesMovedDistance, this.height / 2.0);
        this.ctx.closePath();
        this.ctx.fill();
    }
    
    //检测是否碰撞
    elves.checkCollision = function(){
        var obstaclesMarginLeft = this.width - this.obstaclesMovedDistance - 20;
        var elvesUpDistance = this.upDistanceInitNum - this.upDistance + 20;
        if(obstaclesMarginLeft > this.point.x - this.elvesR && obstaclesMarginLeft < this.point.x + this.elvesR && elvesUpDistance <= 20) {
            //需要检测的最大范围
            let currentCheckCollisionWith = this.maxCheckCollisionWith * elvesUpDistance / 20;
            if((obstaclesMarginLeft < this.point.x + currentCheckCollisionWith / 2.0 && obstaclesMarginLeft > this.point.x - currentCheckCollisionWith / 2.0) || (obstaclesMarginLeft + 20 < this.point.x + currentCheckCollisionWith / 2.0 && obstaclesMarginLeft + 20 > this.point.x - currentCheckCollisionWith / 2.0)){
                this.isCollisioned = true;
            }
        }
        
        //记录障碍物移动到精灵左侧
        if(obstaclesMarginLeft + 20 < this.point.x - this.elvesR && obstaclesMarginLeft + 20 > this.point.x - this.elvesR - 1){
            if(this.isCollisioned == false){
                //跳跃成功，防止检测距离内重复得分置为true，在下一次循环前再置为false
                this.isCollisioned = true;
                //庆祝
                if(this.isShowCongratulation == false) {
                    this.congratulationContent = "完美一跃～";
                    this.congratulationColor = "red";
                    this.isShowCongratulation = true;
                }
            } else {
                //鼓励
                if(this.isShowCongratulation == false) {
                    this.isShowCongratulation = true;
                    this.congratulationColor = "gray";
                    this.congratulationContent = "再接再厉～";
                }
            }
        }
    }
    
    //庆祝绘制文字
    elves.congratulation = function(){
        
        this.congratulationFont += 0.1;
        this.congratulationPosition += 0.1;
        if(this.congratulationFont >= 30){
                        //重置
            this.congratulationFont = 13;
            this.congratulationPosition = 30;
            this.isShowCongratulation = false;
            return;
        }
        this.ctx.fillStyle = this.congratulationColor;        
        this.ctx.font = this.congratulationFont + 'px "微软雅黑"';        
        this.ctx.textBaseline = "bottom";         
        this.ctx.textAlign = "center"; 
        this.ctx.fillText( this.congratulationContent, this.point.x, this.height / 2.0 - this.upDistanceInitNum - this.congratulationPosition);   
    }
    
    window.elves = elves;
})(window)

五、总结与思考

逻辑注释基本都写在代码里，里面的一些计算可能会绕一些。

作者：头疼脑胀的代码搬运工
来源：juejin.cn/post/7056610619490828325

很多公司都会有自己的组件库，但是在使用起来都不尽如人意，这里分享下我自己的一些观点和看法

问题思考

在规划这种整个团队都要用的工具之前要多思考，走一步想一步的方式是不可取的

首先，在开发一个组件库之前先要明确以下几点：

• 目前现状

  • 不自建的话会有哪些问题，为什么不用 antd/element

  • 哪些人提出了哪些的问题

  • 分析为什么会出现这些问题

  • 哪些问题是必须解决的，哪些是阶段推进的

• 期望目标

  • 组件库的定位是什么

  • 自建组件库是为了满足什么场景

  • 阶段目标是什么

  • 最终期望达到什么效果

• 具体实现

  • 哪些问题用哪些方法来解决

  • 关于后续迭代是怎么考虑的

目前现状

仅仅是因为前端开发为了部分代码或者样式不用重复写就封装一个组件甚至组件库是一件很搞笑的事情，最终往往会出现以下问题：

• 代码分散但是却高耦合，存在很多职责不明确

• 封装过于死板，且暴露的属性职责不明确

• 可维护性低，无法应对不断变化的需求

• 可靠性低，对上游数据不做错误处理，对下游使用者不做兼容处理

最后没法迭代，因为代码质量及版本问题，连原始开发者都改不动的，相关使用者怨声载道，然后又重构一遍，还是同样的设计思路，只不过基于已知业务场景改了写法，然后过一段时间又成为一个新的历史包袱。。。

当你为了方便改别人的代码而选择 fork 别人的组件库下来简单改改再输出时，难道你觉得别人不会对“你写的”这个组件库持同样的看法么？

你会发现，如果仅仅以一个业务员的角度去寻求解决办法的话，最后往往不能够得到其他业务员的认可的～

组件库的存在目的是为了提高团队的工作效率，不是单纯为了个别人能少写代码，前者才是目的，后者只是其中一种实现方式（这句话自己悟吧）

期望目标

一个合格的组件库应该要让使用者感受到两点：

• 约束（为什么只能这样传嘛？）

• 方便（只要这样传就可以耶～）

不合格的组件库往往只关注后者，但是其实前者更加重要

在能实现甲方的需求前提下，约束的树立会让团队对某一问题形成一个固有的解决方案，这个使用过程会促成惯性的产生

同时，这个惯性一旦建立，就能促成两个结果：

• 弥合了人与人之间的差异

• 提高了交流效率（不单单是开发，还包括设计、产品、测试等一条工作链路上的相关人）

要知道的是，团队合作过程中，效率最低的环节永远是沟通，一个好的团队不是全员大神，而是做什么事情以一个整体，每个人步调趋于一致，这样效率才高～

具体实现

编写一个公共库需要考虑很多东西，下面主要分三点来阐述

逻辑的分割

• 避免一次性、不通用、没必要的封装

• 不允许出现相互跨级或交叉引用的情况，应形成明确的上下级关系

• 被抽离的逻辑代码应该尽可能的“独立“，避免变成”谁也离不开谁”

逻辑的封装

对于一个管理平台框架来说，宗旨是让开发少写代码、产品少写文档，不需要每次有新业务都要重复产出

对于开发来说，具体有两点：

• 大部分情况下，能拷贝下 demo 即可实现各类交互效果

• 小部分情况下，组件能提供其他更多的可能以满足特殊需求

封装过程中，仅暴露关键属性，提供多种可能，并且以比较常用的值作为“默认值”并明确定义，即可满足“大部分需求只需无脑引用，同时小部分的特殊需求也能被满足”

维护与开发

作为一个上游的 UI 库，要充分考虑下游使用者的情况

• 做到升级后保证下游大部分情况下不需要改动

• 组件的新增、删除、修改要有充分的理由（需求或 bug），并且要遵循最小影响原则

• 组件的设计要充分考虑日后可能发生的变化

未来展望

仅靠一个 UI 框架难以解决问题，对于未来的想法有分成三个阶段：

1. UI 库，沉淀稳定高效的组件

2. 代码片段生成器，收集业务案例代码

3. 页面生成器，输出有效模版

这里更多面向的是中后台项目的解决方案

总结

组件库输出约束和统一解决办法，前者通过抚平团队中个体的差异来提高团队的沟通效率，后者通过形成工作惯性来提高团队的工作效率

作者：tellyourmad
来源：juejin.cn/post/7063017892714905608