概述 记录一个意外发现的一个类 com.sun.net.httpserver.HttpsServer. 一个 Http 的 Server 端. 用处 适用于泛前端类开发者,在无后端服务的情况下,可以用来mock数据或者mock后端行为,非常灵活. 适用于网络库的开发者,测试库的行为; 缺点 目前不支持HTTP2协议. 分类 HTTP 协议 自定义一个 HTTP 服务; 1 2 3 4 5 6 HttpsServer server = HttpsServer.create(new InetSocketAddress(8500), 0); HttpsConfigurator httpsConfigurator = new HttpsConfigurator(SSLContext.getDefault()); server.setHttpsConfigurator(httpsConfigurator); HttpContext context = server.createContext("/example"); context.setHandler(new CustomHttpHandler()); server.start(); 该 Http 服务,是在本机的 8500 端口启动的; 根目录为 example. 所以,直接通过 http://127.0.0.1:8500/example 即可访问. Server 的行为定义 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 public class CustomHttpHandler implements HttpHandler { @Override public void handle(HttpExchange exchange) throws IOException { URI requestURI = exchange.

Override 本篇是对于 Google NDK GUIDES 中 JNI tips 的总结,是关于 JNI 开发过程 中的一些原则和注意点,没有原理. 所有的内容适用于 Java 和 Kotlin. 约定 - managed code (Java/kotlin编写的代码) - native code (C/C++编写的代码) Tips General 整体上大的原则是: 尽量减少 JNI 层的操作. 故而有以下3点注意事项,重要性由高到低依次为: JNI 层调用传递的数据尽量少,调用的频率尽量低; JNI Java 调用 native 避免异步调用,异步操作都放在 Java 层.这指的是 JNI 调用,不包含 native 库自身有些异步操作; JNI 操作涉及到的线程越少越好.即使要用线程池,也是由线程池的管理者负责JNI之间的交互,而不是由工作线程直接负责交互; 为了方便维护和重构, 保证JNI相关的代码在固定的位置,容易辨认,且接口尽量少; JavaVM & JNIEnv 二者本质上都是指向函数表的指针的指针. 虽然理论上来说,每个进程可以有多个 JavaVM 对象,但是 Android 规定,每个进程只能有一个 JavaVM ; 注意点 JNIEnv 是个线程局部变量,线程不可共享,请勿在线程之间共享 JNIEnv 对象; 如若无其他方式获取 JNIEnv,可以采如下方式; 1 2 JNIEnv* env; vm->AttachCurrentThread(&env, nullptr); // 此处的 vm 即为JavaVM 对象,可以处理成全局单例; 由于 JavaVM & JNIEnv 在 C 和 C++ 中的定义是不一样(“jni.

概述 记录另外一个mockserver的库使用方式. API 更加丰富. 添加依赖 1 2 compile group: 'org.mock-server', name: 'mockserver-netty', version: '5.6.1' compile group: 'log4j', name: 'log4j', version: '1.2.17' 使用方式 最简单的使用方式, 请求 -> 返回mock的response Server端 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 public class MockServerTest { public static void main(String[] args) { // 1.

概述 本篇记录okhttp自带的mockserver这个库的使用方式. 作为一个网络库,okhttp自身也实现了一个mockserver,以方便写测试用例,这个库是独立的,也可以单独使用. 用作平时简单的mock数据,进行测试,很方便 使用方式 此处以Android为例,Java除了依赖方式有点差异,其他一致; 添加依赖 1 androidTestImplementation('com.squareup.okhttp3:mockwebserver:3.13.1') 代码使用 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 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 public class MockRes { public final MockWebServer server = new MockWebServer(); public OkHttpClient client = new OkHttpClient(); @Test public void simpleTest() { // 构造一个mock的 response MockResponse mockResponse = new MockResponse().

概述 刚在InfoQ上看到一篇介绍C4Model的文章,觉得这个模型设计的很赞,很有指导意义,做个简单的记录. Why,为什么需要架构图? ThoughtWorks中国 文章中有几句话我觉得很有道理,这里直接摘抄. “纸上的不是架构，每个人脑子里的才是” ; “那些精妙的方案之所以落不了地，是因为没有在设计上兼容人类的愚蠢”。 我觉得,软件工程,或者软件中的术语发明的原因就是为了减少沟通的障碍,让大家在一个 平台 上对话. 而架构图可以起到如下作用; 一方面: 让软件的开发人员自己,以及和软件开发相关的用户,PM等人员都能快速了解一个系统的业务模型; 另一方面: 利于开发人员相互之间协作,定下方案,因为自然语言是有模糊地带的,难以无歧义的传达; 利于软件系统的维护,一图胜千言. What,C4 是什么呢? 详细的讲解,可以参考InfoQ的文章,这里做个总结. C4 4个单词的首字母为C的单词的代表, 分别为: 上下文(Context),容器(Container),组件(Component)和代码(Code); 依据不同的受众,分别抽象出了这四个级别.其中容器（应用程序、数据存储、微服务等,组件和代码来描述一个软件系统的静态结构. 第 1 层：系统上下文 显示了正在构建的软件系统，以及构建的系统与用户及其他软件系统之间的关系。 这个层级的图,关注的是用户层面看到的关系,注重的是和准备开发的系统与外部系统和交互人之间的关系. 将用户,你的代建系统,已有的其他系统用不同的颜色进行区分; 第 2 层：容器 将软件系统放大，显示组成该软件系统的容器（应用程序、数据存储、微服务等）。 在这个层级,已经关注系统本身了,开始关注这个系统有哪些部分组成,不过粒度非常粗. 第 3 层：组件 将单个容器放大，以显示其中的组件。这些组件映射到代码库中的真实抽象（例如一组代码）。 在这个层级,关注的已经是系统中的模块具体的功能了,这部分可能对应了具体的功能模块. 第 4 层：代码 如若必要,可以放大个别组件，以显示该组件的实现方式。 一般以UML图的形式展示; 这个层级,是具体的开发人员关注的实现细节了,用于具体的功能逻辑的分析和展示. How,怎能画图呢? 在C4官网,下有个Tooling节点,讲述了目前已有的几个画图工具. 参考 用于软件架构的C4模型 可视化架构设计——C4介绍 C4官网

概述 HTTP/2 仍是对之前 HTTP 标准的扩展,而非替代.HTTP 的应用语义不变，提供的功能不变,HTTP 方法、状态代码、URI 和标头字段等这些核心概念也不变. 背景 本文是对Google博客上文章的翻译和笔记.以及一些待解决的问题记录. Google 博客上这篇文章的中文版有很多翻译错误. HTTP/2 的主要目标是: 通过支持完整的请求与响应的多路复用来减少延迟; 通过有效压缩 HTTP 标头字段将协议开销降至最低; 增加对请求优先级和服务器推送的支持; 重要的两点 HTTP/2 没有改动 HTTP 的应用语义。HTTP 方法、状态代码、URI 和标头字段等核心概念一如往常; HTTP/2 修改了数据格式化(分帧)以及在客户端与服务器间传输的方式; 这两点统帅全局，通过新的分帧层向我们的应用隐藏了所有复杂性。可以实现在同一连接上 进行多个并发交换. Binary framing layer: 二进制分帧层 HTTP/2 所有性能增强的核心在于新的二进制分帧层，它定义了如何封装 HTTP 消息并在客户端与服务器之间传输。 这里所谓的“层”，指的是位于套接字接口与应用可见的高级HTTP API之间一个经过优化的新编码机制:HTTP 的语义（包括各种动词、方法、标头）都不受影响，不同的是传输期间对它们的编码方式变了。 HTTP/1.x 协议以换行符作为纯文本的分隔符，而 HTTP/2 将所有传输的信息分割为更小的消息和帧，并采用二进制格式对它们编码。 数据流、消息和帧 数据流：已建立的连接内的双向字节流，可以承载一条或多条消息。 消息：与逻辑请求或响应消息对应的完整的一系列帧。 帧：HTTP/2 通信的最小单位，每个帧都包含帧头，至少也会标识出当前帧所属的数据流。 简单概括一下: 所有通信都在一个 TCP 连接上完成，此连接可以承载任意数量的双向数据流。 每个数据流都有一个唯一的标识符和可选的优先级信息，用于承载双向消息。 每条消息都是一条逻辑 HTTP 消息(例如请求或响应)，包含一个或多个帧。 帧是最小的通信单位，承载着特定类型的数据，例如 HTTP 标头、消息负载等等.来自不同数据流的帧可以交错发送，然后再根据每个帧头的数据流标识符重新组装. HTTP/2 将 HTTP 协议通信分解为二进制编码帧的交换，这些帧对应着特定数据流中的消息。所有这些都在一个 TCP 连接内复用。 Request and response multiplexing: 请求与响应复用 在 HTTP/1.