为什么HTTPS不能抓包了？

Google在Android 7.0以后的版本中，添加了“网络安全配置（Network security configuration）”的相关配置项。其旨在增强App的安全性，可以避免TargetSDK版本>=N的App内部网络请求在非测试环境下被恶意抓包。

Network Sercurity Configuration对安全性的保证，主要是通过以下几个途径：是否允许明文HTTP请求（非HTTPS）、HTTPS证书（区分系统、用户）信任设置、域名以及App的Debug或Release配置，只有符合Manifest中配置的NetworkConfig字段内容下的条件，才可以进行正常的HTTP请求，如果需要使用Charles、Fiddler等工具进行抓包，也需要利用NetworkConfig来配置可以信任的证书，否则HTTPS请求在CONNECT阶段，就会返回错误，同时LogCat会打印出类似以下的错误信息：

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

Caused by: java.security.cert.CertificateException: xxx.
   at com.android.org.conscrypt.TrustManagerImpl.verifyChain(TrustManagerImpl.java:661)
   at com.android.org.conscrypt.TrustManagerImpl.checkTrustedRecursive(TrustManagerImpl.java:539)
   at com.android.org.conscrypt.TrustManagerImpl.checkTrustedRecursive(TrustManagerImpl.java:605)
   at com.android.org.conscrypt.TrustManagerImpl.checkTrusted(TrustManagerImpl.java:495)
   at com.android.org.conscrypt.TrustManagerImpl.checkServerTrusted(TrustManagerImpl.java:321)
   at android.security.net.config.NetworkSecurityTrustManager.checkServerTrusted(NetworkSecurityTrustManager.java:113)
   at android.security.net.config.NetworkSecurityTrustManager.checkServerTrusted(NetworkSecurityTrustManager.java:87)
   at android.security.net.config.RootTrustManager.checkServerTrusted(RootTrustManager.java:116)
   at com.huawei.secure.android.common.ssl.SecureX509TrustManager.checkServerTrusted(:105)
   at com.android.org.conscrypt.Platform.checkServerTrusted(Platform.java:212)
   at com.android.org.conscrypt.ConscryptFileDescriptorSocket.verifyCertificateChain(ConscryptFileDescriptorSocket.java:404)
   at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake(Native Method)
   at com.android.org.conscrypt.NativeSsl.doHandshake(NativeSsl.java:375)

通常，Android开发者会将NetworkConfig按照以下XML文件进行配置：

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

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <!-- 允许明文HTTP（非HTTPS）请求 -->
    <base-config cleartextTrafficPermitted="true">
        <trust-anchors>
            <!-- 其他情况只允许信任系统内置证书 -->
            <certificates src="system"/>
        </trust-anchors>
    </base-config>
    <!-- 仅Debug包允许用户证书 -->
    <debug-overrides>
        <trust-anchors>
            <certificates src="user"/>
        </trust-anchors>
    </debug-overrides>
</network-security-config>

然而对于开发者来说，通常App发版上线会选择使用Release版本的安装包，如果希望对Release包抓包，只能使用Android 6.0及以下的手机，这样一来，有时候出现线上问题，便无法进行HTTPS抓包，并不利于测试和修正

由来

一个月前，剁手了AMD Ryzen Threadripper 2990WX（官网），这个处理器的参数着实牛逼，32核心64线程，总共80MB的缓存，可以说秒杀目前所有的桌面级处理器了！狠了狠心，搞了一台，辅以32GB DDR4 3200MHz内存和970 EVO NVMe SSD，经过一番折腾（无CPU刷BIOS、装Windows/Linux系统），最终确定使用Windows 10专业工作站版作为日常开发使用。

Cinebench R15跑分：

CPU-Z跑分：

虽然分数不像网上那些人跑得那么高，但也是相当猛了，再加上任务管理器64个框框，心里十分舒坦！

背景

之前在开发实验室官网（https://www.xiyoumobile.com）的时候，由于图片特别多，学校服务器走电信和教育网，带宽也不够，在某些网络环境图片加载十分缓慢，而且有时候主页打开需要10s+的时间，所以考虑从图片压缩上节省网络带宽

目前业界的图片压缩方案有以下几种，他们的压缩比都很高，都可以有效减小图片文件的体积

|方案|提出者|编码类型|开源|官网|浏览器支持情况| |——-|——-|——-|——-|——-| |WebP|Google|VP8|是|https://developers.google.com/speed/webp/|Chrome、Opera、Edge、Android，及其他基于Chromium内核的浏览器| |BPG|Fabrice Bellard|HEVC|是|http://bellard.org/bpg|无| |TPG|腾讯|AVS2（类似AVC)|否|未知|QQ浏览器| |JPEG XR|微软|未知|否|（微软已投奔WebP）|IE、Edge|

根据TPG推出时腾讯的微信公众号文章来看，TPG的压缩算法相比WebP而言，能够使体积变得更小，图片更清晰，但是适用范围还是太局限了，所以还是选择了WebP

但主要问题是前端代码中已经固定了某些静态图片资源的URL及扩展名，数据库中保存的HTML中的图片引用也是如此，即使把图片全部转换为WebP格式，如何保证不改动HTML及CSS代码，就能够对支持的浏览器返回WebP格式图片，而不支持的浏览器返回JPG/PNG？

于是经过一段时间摸索和整理，就有了现在用在我个人网站的coderyuan-image-server：https://github.com/yuanguozheng/coderyuan-image-server

基本原理及流程

判断浏览器是否支持WebP

首先引用一段来自w3的定义（RFC 2616）：https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

The Accept request-header field can be used to specify certain media types which are acceptable for the response. Accept headers can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request for an in-line image.

   Accept         = "Accept" ":"
                    #( media-range [ accept-params ] )
   media-range    = ( "*/*"
                    | ( type "/" "*" )
                    | ( type "/" subtype )
                    ) *( ";" parameter )
   accept-params  = ";" "q" "=" qvalue *( accept-extension )
   accept-extension = ";" token [ "=" ( token | quoted-string ) ]

这里定义了HTTP请求头中Accept字段的含义——表示Response可以接受的媒体类型（MIME-Type）

如果支持WebP，那么Accept中将会包含image/webp这样的字符串

于是乎，我们就可以根据浏览器请求图片资源时的Accept字段来区分是否真正支持WebP格式

为什么不使用User-Agent？

Flutter是什么

我觉得可以理解为Google做的React Native/Weex，目标也是使用一套代码，同时运行在Android和iOS上，提供Native的性能和体验，也都支持热更新，只不过Flutter使用Dart语言，React Native使用JavaScript，据说Flutter的性能要比RN好一些，因为没有使用JSBridge这样的结构，直接使用Dart来操作Native控件，具体可以参考它的官网：https://flutter.io/

上图，Flutter官方文档的结构，和React Native都很像！

最近Flutter不知道怎么就火了，之前有人给我提过，现在准备一探究竟

环境搭建

类似React Native，Flutter也是同样的套路，需要先下载它的命令行工具，由于需要兼容iOS，所以还是推荐使用macOS来进行开发

由于网络问题，需要设置两个环境变量

1
2

export PUB_HOSTED_URL=https://pub.flutter-io.cn
export FLUTTER_STORAGE_BASE_URL=https://storage.flutter-io.cn

然后在Flutter的官方Github clone它的命令行工具，git clone -b dev https://github.com/flutter/flutter.git，这里建议使用dev分支，能及时更新到一些新功能，同时也比master分支要稍稳定一些

最近在读《Java并发编程实战》这本书，感觉写的很详细，易懂，可以比较全面地了解Java并发编程相关内容，为了以后方便查找，专门做个读书笔记，这篇只总结这本书的第一部分——基础知识

线程

• 线程会共享进程范围内的资源（例如：内存句柄和文件句柄），但每个线程都有各自的程序计数器、栈、局部变量等

• 线程也被称为轻量级进程，很多操作系统都以线程为基本的调度单位

• 同一个进程中的所有线程，共享进程的内存地址空间，可以访问相同的变量，在同一个堆上分配对象（所以多个线程同时访问时，必须使用同步机制来协同访问）

• 线程的优势：发挥多处理器的能力、建模简单、简化异步事件处理、GUI响应灵敏

• 线程带来的风险：安全性、活跃性、性能

• 安全性：存在竞态条件（同时访问，某个方法不一定返回的是唯一值），使用同步来解决

• 活跃性：死锁、饥饿、活锁

• 性能：线程调度器临时挂起活跃线程，并转而运行另一个线程，造成上下文（Context）频繁切换

为什么要检测？

Google在2018年的I/O大会上发布了Android P的Developer Preview 2（简称DP2）版本，其中还说明了在以后的Android P上，将对非SDK API的调用进行限制。目前，开发者对于非SDK API的调用，只能采取反射或JNI间接调用的方法进行调用。由于Android是开源的，所以开发者对非公有SDK的调用十分混乱，Google此举也是为了进一步防止碎片化，规范开发者的API使用行为。

而在运行Android P的手机上，启动APP时，ART虚拟机就会对APP的Dex文件进行检测，比对内置的黑名单、暗灰名单、亮灰名单，一旦发现APP内含有上面名的中的调用，就会发出警告，严重的，会直接抛出异常，如果没有进行处理，将导致APP的Crash，即使进行了try-catch，这些反射调用的功能，也会使用不正常。

Smali是什么？

简介

Smali是用于Dalvik（Android虚拟机）的反汇编程序实现，汇编工具（将Smali代码汇编为dex文件）为smali.jar，与之对应的baksmali.jar则是反汇编程序（下载地址），官方所说的基于Jasmin/dedexer语法，实际根不知道是什么鬼……

Smali支持注解、调试信息、行数信息等基本Java的基本特性，可以说是很接近Java编译在JVM上的中间语言了，一般用来做Android程序的逆向工程，还可以。。搞搞小名堂

个人认为Smali只是用于做反汇编的一种语言实现，如果可以，自己也能定义一套这样的语言，实现反汇编的效果

Smali基础

下面的内容涉及一些Smali编程的结构和基本语法，这些基本语法，在使用Smali修改App逻辑时需要用到

最近做了一些Android App启动速度的优化，有一些心得，整理整理

影响启动速度的原因

高耗时任务

数据库初始化、某些第三方框架初始化、大文件读取、MultiDex加载等，导致CPU阻塞

复杂的View层级

使用的嵌套Layout过多，层级加深，导致View在渲染过程中，递归加深，占用CPU资源，影响Measure、Layout等方法的速度

类过于复杂

Java对象的创建也是需要一定时间的，如果一个类中结构特别复杂，new一个对象将消耗较高的资源，特别是一些单例的初始化，需要特别注意其中的结构

主题及Activity配置

有一些App是带有Splash页的，有的则直接进入主界面，由于主题切换，可能会导致白屏，或者点了Icon，过一会儿才出现主界面

一些典型的例子及优化方案

Context是Android App中用的非常多的一种概念，常被翻译成上下文，这种概念在其他的技术中也有所使用，无意间点了Context的源码，那么就来分析分析Context在Android中到底是什么东西？

先贴段代码

1
2
3
4
5
6
7
8
9

/**
 * Interface to global information about an application environment.  This is
 * an abstract class whose implementation is provided by
 * the Android system.  It
 * allows access to application-specific resources and classes, as well as
 * up-calls for application-level operations such as launching activities,
 * broadcasting and receiving intents, etc.
 */
public abstract class Context {

通过注释可以看出，Android官方对它的解释，大概可以理解为应用程序环境中全局信息的接口，它整合了许多系统级的服务，可以用来获取应用中的类、资源，以及可以进行应用程序级的调起操作，比如启动Activity、Service等等，而且Context这个类是abstract的，不包含具体的函数实现。

17年底就开始寻思升级一下coderyuan.com了，想写点东西，最近搞了搞，用上了高大上的hexo！然后发现，这东西真的是万恶之源啊，跟无底洞一样，一堆东西都想做，越做越多，越做越深，像个层次特别深的递归，要算好久才能返回。。。

现在新主页上线了，以后应该都在这里写东西了，以前在CSDN写的文章就不同步过来了，有需要的朋友可以在https://blog.csdn.net/yuanguozhengjust继续看

Github：https://github.com/yuanguozheng