光 HikariCP・A solid, high-performance, JDBC connection pool at last. in short, it's library for JDBC connection pool, it make you easier manage your  JDBC connection pool.

Using HikariCP integrate Clickhouse, there are three steps.

1. config Clickhouse datasource url/username/password on the yml file, it also set this information on Vault, it depends on you.
2. create the config class on SpringBoot, this class will read Clickhouse configuration on yml file, and establish connection.
3. this step is optional, create JdbcTemplate, it is easy for query clickhouse

First step

config yml file

spring:
  datasource:
    clickhouse:type: com.zaxxer.hikari.HikariDataSource
    driver-class-name: com.clickhouse.jdbc.ClickHouseDriver
    jdbc-url: jdbc:clickhouse://xxxxx
    username: abc
    password: abc

Second step

create config class

@Configuration
class ClickHouseDataSourceConfig {
    @Bean
    @ConfigurationProperties(prefix = "spring.datasource.clickhouse")
    fun clickhouseDataSource(
            @Value("${spring.datasource.clickhouse.username}") username: String,
            @Value("${spring.datasource.clickhouse.password}") password: String
    ): DataSource = DataSourceBuilder.create().type(HikariDataSource::class.java).build().apply {
        this.username = username
        this.password = password
        this.isReadOnly = true
    }
    
    @Bean("clickhouseJdbcTemplate") //create JdbcTemplate,optional
    fun clickhouseJdbcTemplate(@Qualifier("clickhouseDataSource") dataSource: DataSource): JdbcTemplate =
        JdbcTemplate(dataSource)
}

that's all

在命令行中加入下面代码就可以了

sudo apt install qemu-user-static
sudo update-binfmts --install i386 /usr/bin/qemu-i386-static --magic '\x7fELF\x01\x01\x01\x03\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x03\x00\x01\x00\x00\x00' --mask '\xff\xff\xff\xff\xff\xff\xff\xfc\xff\xff\xff\xff\xff\xff\xff\xff\xf8\xff\xff\xff\xff\xff\xff\xff'
sudo service binfmt-support start

V8垃圾回收分析

关于垃圾回收机制

由于JavaScript 的对象是在V8上生产的，所以生命周期也是由V8来控制，这里就牵扯到了垃圾回收。任何垃圾回收都会做以下三件事情：

• 识别不再被引用的对象（Dead Objects）
• 回收这些对象所占用的内存
• 重新压碎整理碎片化的内存块（可选的）

分代机制

V8的垃圾回收机制也与其他主流语言一样（有垃圾回收机制的语言），使用的世代回收机制，主要有两个世代：新生代（Young generation）和老年代（Old generation），V8在这个两个世代的前提下，又增加了独特的空间，用来存放专门的对象。以下是V8在内存管理中的所有空间：

  RO_SPACE,    // Immortal, immovable and immutable objects,
  NEW_SPACE,   // Young generation semispaces for regular objects collected with
               // Scavenger.
  OLD_SPACE,   // Old generation regular object space.
  CODE_SPACE,  // Old generation code object space, marked executable.
  MAP_SPACE,   // Old generation map object space, non-movable.
  LO_SPACE,    // Old generation large object space.
  CODE_LO_SPACE,  // Old generation large code object space.
  NEW_LO_SPACE,   // Young generation large object space.

这些空间组成了V8的heap管理并且在Isolate初始化时完成各自空间的初始化。
在了解每个世代的垃圾回收之前，我们先看一下V8的heap结构：

新生代

新生代又分了两个SemiSpace（from和to），默认的初始化容量是1MB、最大容量8MB，这2个空间类似于Java中的Eden和Survivor区，这2个半区每次GC后，总有一个区是空的，为什么呢？

每次进行minor GC时，将from区中仍然存活的对象copy到to区，然后将from区的内存全部清除，然后设置两个区的page的flag，将FROM_PAGE设置为TO_PAGE，这样from区就有之有之前to区的存活对象，而to区经过交换数据后，没有存活的对象了，自然就空了。虽然新生代只有一半的空间在使用，但是新生代的对象，大部分生命周期都很短，这样做也是出于效率的考虑。用空间换时间，这样效率还是很高的。

那么V8内部是如何触发内存回收的呢？是监听Heap的内存大小？还是定期主动进行GC？我们通过代码一探究竟。
V8中的所有对象都是通过工程方法创建的。它有一个专门的工厂类(factory.h)用来创建所有的对象。

 Handle<FixedArray> NewFixedArray(
      int length, AllocationType allocation = AllocationType::kYoung);
Handle<PropertyArray> NewPropertyArray(
      int length, AllocationType allocation = AllocationType::kYoung);
MaybeHandle<String> NewStringFromOneByte(
      const Vector<const uint8_t>& str,
      AllocationType allocation = AllocationType::kYoung);
MaybeHandle<String> NewStringFromUtf8(
      const Vector<const char>& str,
      AllocationType allocation = AllocationType::kYoung);
Handle<Struct> NewStruct(InstanceType type,
                           AllocationType allocation = AllocationType::kYoung);
Handle<ByteArray> NewByteArray(
      int length, AllocationType allocation = AllocationType::kYoung);
Handle<Object> NewNumber(double value,
                           AllocationType allocation = AllocationType::kYoung);
Handle<JSObject> NewJSObject(
      Handle<JSFunction> constructor,
      AllocationType allocation = AllocationType::kYoung);

这里列出了主要使用的API，上述还有很多API没有列出，都是与创建V8对象相关的。每个对象的生成都会调用AllocateRawWithRetryOrFail这个方法

HeapObject AllocateRawWithRetryOrFail(
      int size, AllocationType allocation,
      AllocationAlignment alignment = kWordAligned) {
      AllocationResult alloc;
  HeapObject result = AllocateRawWithLightRetry(size, allocation, alignment);
  if (!result.is_null()) return result;

  isolate()->counters()->gc_last_resort_from_handles()->Increment();
  CollectAllAvailableGarbage(GarbageCollectionReason::kLastResort);
  {
    AlwaysAllocateScope scope(isolate());
    alloc = AllocateRaw(size, allocation, alignment);
  }
  if (alloc.To(&result)) {
    DCHECK(result != ReadOnlyRoots(this).exception());
    return result;
  }
  // TODO(1181417): Fix this.
  FatalProcessOutOfMemory("CALL_AND_RETRY_LAST");
  return HeapObject();
}

AllocateRawWithRetryOrFail会在调用AllocateRawWithLightRetry和AllocateRaw

AllocateRawWithLightRetry->AllocateRaw->生成对象

AllocateRaw会针对 不同的AllocationType调用对应space生成对象。代码如下：

AllocationResult Heap::AllocateRaw(int size_in_bytes, AllocationType type,
                                   AllocationAlignment alignment) {
  DCHECK(AllowHandleAllocation::IsAllowed());
  DCHECK(AllowHeapAllocation::IsAllowed());
  DCHECK(gc_state_ == NOT_IN_GC);
#ifdef V8_ENABLE_ALLOCATION_TIMEOUT
  if (FLAG_random_gc_interval > 0 || FLAG_gc_interval >= 0) {
    if (!always_allocate() && Heap::allocation_timeout_-- <= 0) {
      return AllocationResult::Retry();
    }
  }
#endif
#ifdef DEBUG
  IncrementObjectCounters();
#endif

  bool large_object = size_in_bytes > kMaxRegularHeapObjectSize;

  HeapObject object;
  AllocationResult allocation;

  if (AllocationType::kYoung == type) {
    if (large_object) {
      if (FLAG_young_generation_large_objects) {
        allocation = new_lo_space_->AllocateRaw(size_in_bytes);
      } else {
        // If young generation large objects are disalbed we have to tenure the
        // allocation and violate the given allocation type. This could be
        // dangerous. We may want to remove FLAG_young_generation_large_objects
        // and avoid patching.
        allocation = lo_space_->AllocateRaw(size_in_bytes);
      }
    } else {
      allocation = new_space_->AllocateRaw(size_in_bytes, alignment);
    }
  } else if (AllocationType::kOld == type) {
    if (large_object) {
      allocation = lo_space_->AllocateRaw(size_in_bytes);
    } else {
      allocation = old_space_->AllocateRaw(size_in_bytes, alignment);
    }
  } else if (AllocationType::kCode == type) {
    if (size_in_bytes <= code_space()->AreaSize() && !large_object) {
      allocation = code_space_->AllocateRawUnaligned(size_in_bytes);
    } else {
      allocation = code_lo_space_->AllocateRaw(size_in_bytes);
    }
  } else if (AllocationType::kMap == type) {
    allocation = map_space_->AllocateRawUnaligned(size_in_bytes);
  } else if (AllocationType::kReadOnly == type) {
#ifdef V8_USE_SNAPSHOT
    DCHECK(isolate_->serializer_enabled());
#endif
    DCHECK(!large_object);
    DCHECK(CanAllocateInReadOnlySpace());
    allocation = read_only_space_->AllocateRaw(size_in_bytes, alignment);
  } else {
    UNREACHABLE();
  }

  if (allocation.To(&object)) {
    if (AllocationType::kCode == type) {
      // Unprotect the memory chunk of the object if it was not unprotected
      // already.
      UnprotectAndRegisterMemoryChunk(object);
      ZapCodeObject(object.address(), size_in_bytes);
      if (!large_object) {
        MemoryChunk::FromHeapObject(object)
            ->GetCodeObjectRegistry()
            ->RegisterNewlyAllocatedCodeObject(object.address());
      }
    }
    OnAllocationEvent(object, size_in_bytes);
  }

  return allocation;
}

老年代

老年代的对象都是经过了新生代一轮GC，晋升之后转移过来的。另外老年代又包含新生代的指针空间和新生代数据空间，前者是包含了指向新生代对象指针的对象，后者只保存原始数据对象，这些对象没有指向其他对象的指针。

InputFilter这个interface相信大家也不会陌生,任何对EditText的输入第一步就会经过它,而它的名字也十分的直白——输入过滤器.InputFilter只有一个方法,就是filter方法,而这个方法却对你的输入过滤有着至关重要的结果,我们现在看看google的官方文档是怎么描述这个filter方法的.

This method is called when the buffer is going to replace the range dstart … dend of dest with the new text from the range start … end of source. Return the CharSequence that you would like to have placed there instead, including an empty string if appropriate, or null to accept the original replacement. Be careful to not to reject 0-length replacements, as this is what happens when you delete text. Also beware that you should not attempt to make any changes to dest from this method; you may only examine it for context. Note: If source is an instance of Spanned or Spannable, the span objects in the source should be copied into the filtered result (i.e. the non-null return value). [copySpansFrom(Spanned, int, int, Class, Spannable, int)](https://developer.android.com/reference/android/text/TextUtils.html#copySpansFrom(android.text.Spanned, int, int, java.lang.Class, android.text.Spannable, int)) can be used for convenience.

简单翻译:当来自source的新内容(start--end)将要替换之前的内容(dstart--dend)时该方法被调用,返回一串字符串,使用source的内容替代,包括空字符串和null都可以替换原始的位置.需要注意的是当文本被删除时，我们可能会使用0-length的替换。另外还要注意的是，你不应该在这个方法里对原始内容做任何改动，你只是需要检查它的上下文。当缓冲区要用源的范围start ... end中的新文本替换dest的范围dstart ... dend时，将调用此方法。 返回您希望放置的CharSequence，包括空字符串（如果适用），或null以接受原始替换。 小心不要拒绝0长度替换，因为删除文本时会发生这种情况。 还要注意，您不应该尝试对此方法的dest进行任何更改; 你可能只会检查它的上下文。 注意：如果source是Spanned或Spannable的实例，则应将源中的span对象复制到筛选结果中（即非null返回值）。 在copySpansFrom（Spanned，int，int，Class，Spannable，int）中进行处理。

在使用InputFilter时,一般情况下都时在用过键盘输入时,需要过滤的内容,这是输入source一般输入的类型为Spanned的,而且里面会有UnderlineSpan.class的类型的Span在source里,所以这是显示在EditText上的内容是带下划线的,也让用户明白现在是待输入状态.

当我继续在输入法中选取Apple这个单词时,log有如下输出:

I/System.out: source is spanned:false src:|dest:apple|dest is spanned:true
I/System.out: source is spanned:false src:Apple|dest:|dest is spanned:true
I/System.out: source is spanned:true src:|dest:Apple|dest is spanned:true

这三个log输出应该都时由输入法触发的,所以如果你需要过滤用户的输入情况,那么一定要考虑到用户输入或者粘贴的内容是否是带有spann样式的.

如果只是需要去除粘贴板中spann的样式.只需:

onTextContextMenuItem(ID_PASTE_AS_PLAIN_TEXT)

即可

在Blink上工作不是件容易的事.Blink有很多专有的概念,并且有一套为了实现快速渲染引擎而引入的编码规范,这个对于新开发者来说并不是易事.即使是经验丰富的Blink开发人员也不容易,因为Blink非常庞大,对性能,内存和安全性极为敏感.

这篇文档的目的是帮助Blink的开发者快速熟悉架构:

• 该文档并不是讲述Blink的详细架构和编码规则教程.相反,该文档简明的描述了Blink的短期内不太可能发生变化基本面,并指出如果你想了解更多信息,你可以阅读的资源有哪些。
• 该文档没有解释具体的某些功能（例如，ServiceWorkers，编辑）.相反,该文档解释了基本功能(例如，存储器管理，V8 API)。

Blink是干什么的?

进程/线程架构

• 进程

• 线程

• 初始化Blink

目录结构

• Content公开API和blink公开API
• 目录结构和依赖
• Web Template Framework(WTF)

内存管理

任务调度

Page, Frame, Document, DOMWindow etc

• 概念
• 进程外的iframe(OOPIF)
• [移除Frame/Document](#Detached Frame_/_Document)
• 网页接口定义语言绑定(Web IDL bindings)

V8和Blink

• Isolate, Context, World
• V8的API
• V8的包装类们

渲染流水线

问题?

Blink是干什么的?

Blink是web平台的一个渲染引擎.通俗的说,Blink实现了能在浏览器里呈现所有内容的能力:

• 实现了浏览器平台的规范(例如html标志).包括DOM,CSS和Web IDL.
• 嵌入了V8引擎和执行JavaScript
• 从底层网络栈中请求资源
• 构建DOM树
• 计算样式和布局
• 嵌入了chrome的排版器和图形绘制

blink通过Content public APIs嵌入了许多第三方的浏览器(例如chromium,android webview,Opear).

从代码库的角度看,"Blink"通常是指//third_party/blink/.从项目角度看,"Blink"通常是指实现项目的功能.实现Web平台功能的代码范围为:

• //third_party/blink/
• //content/renderer/
• //content/browser/
• 其他地方。

进程/线程架构

堆排序的主要步骤分为三部分:

1. 建堆
2. 维持堆的性质
3. 排序

首先是建堆,建堆的主要目的是建立一个最大堆,这样我们就可以保证堆顶的元素一定是这个数组中最大的元素.

void buildHeap(int *array, int size)
{
    for (int i = size / 2; i >= 0; i--)
    {
        maxHeapify(array, i, size);  //维持最大堆性质
    }
}

其次是维持最大堆性质,其过程如下:

1. 比较当前节点(父节点)和自己的2个子节点(可能是1个)的大小.
2. 将3个节点中最大值的点与当前节点交换位置.
3. 如果产生了节点交换,那么继续以交换后的节点作为父节点继续执行maxHeapify.
4. 直到不再产生节点位置交换.

void maxHeapify(int *array, int index, int size)
{
    int l = left(index);
    int r = right(index);
    int largest;
    if (l < size && array[l] > array[index])
    {
        largest = l;
    }
    else
    {
        largest = index;
    }

    if (r < size && array[r] > array[largest])
    {
        largest = r;
    }
    if (largest != index)
    {
        int temp = array[largest];
        array[largest] = array[index];
        array[index] = temp;
        maxHeapify(array, largest, size);
    }
}

最后则是排序过程,因为在建堆和维持堆持续后,已经产生了1个最大堆,那么剩下的过程只需要将数组的最后1位和根节点交换位置,将数组的length-1,然后继续维持堆的性质后,那么就又产生了1个最大堆,如此循环直到只剩下1个元素的时候.排序过程如下图:


排序代码就很简单了,如下:

void heapSort(int *array, int size)
{
    buildHeap(array, size);
    int length = size;
    for (int i = length - 1; i >= 1; i--)
    {
        int temp = array[i];
        array[i] = array[0];
        array[0] = temp;
        size -= 1;
        maxHeapify(array, 0, size);
    }
}

最后附上完整代码

#include "iostream"
using namespace std;

int parent(int i)
{
    return i / 2;
}

int left(int i)
{
    return i * 2 + 1;
}

int right(int i)
{
    return i * 2 + 2;
}

void maxHeapify(int *array, int index, int size)
{
    int l = left(index);
    int r = right(index);
    int largest;
    if (l < size && array[l] > array[index])
    {
        largest = l;
    }
    else
    {
        largest = index;
    }

    if (r < size && array[r] > array[largest])
    {
        largest = r;
    }
    if (largest != index)
    {
        int temp = array[largest];
        array[largest] = array[index];
        array[index] = temp;
        maxHeapify(array, largest, size);
    }
}

void buildHeap(int *array, int size)
{
    for (int i = size / 2; i >= 0; i--)
    {
        maxHeapify(array, i, size);
    }
}

void heapSort(int *array, int size)
{
    buildHeap(array, size);
    int length = size;
    for (int i = length - 1; i >= 1; i--)
    {
        int temp = array[i];
        array[i] = array[0];
        array[0] = temp;
        size -= 1;
        maxHeapify(array, 0, size);
    }
}

int main()
{
    int array[] = {4, 1, 3, 2, 16, 9, 10, 14, 8, 7};
    int size = sizeof(array) / sizeof(array[0]);
    heapSort(array, size);

    for (int i = 0; i < sizeof(array) / sizeof(array[0]); i++)
    {
        cout << array[i] << endl;
    }
    return 0;
}

堆排序的时间复杂度分析:

时间复杂度为O(nlgn).而且为原址排序算法(如果输入数组中仅有常数个数元素需要在排序过程存储在数据之外,则称排序算法是原址的).这里快速排序是原址的,但归并排序不是原址的,因为在合并过程中有额外的数组存储.

heapSort在建立初始最大堆后,它的时间复杂度为O(n),而length-1次的调用maxHeapify,每次调用时间复杂度为O(lgn).所以总时间复杂度位O(nlgn);

问题

构建一个不崩溃或者绝对安全的渲染引擎几乎是不可能的.

在2006年左右,浏览器的状态类似于过去的单用户,协作式操作系统.由于一些程序的错误行为可能导致整个系统都崩溃,同样某些页面的错误操作会使整个浏览器奔溃,这只是一个页面的错误或者插件的bug就会导致整个浏览器关闭和所有的Tabs.

现在的操作系统往往都更健壮,因为它将不同的程序放到了彼此隔离的单独进程中.一个应用崩溃通常不会影响其他应用或者整个系统,并且每个用户访问其他用户的数据是受限的.

架构概览

我们对浏览器的Tab页使用单独进程,可以避免整个应用受到渲染引擎的bug或者小故障的影响.我们也限制每个渲染引擎进程访问其他进程和系统的其他部分.这为浏览器带来了内存保护和访问控制操作系统带来了好处.

我们将运行UI的主线程和管理Tabs和插件进程的作为"浏览器进程"或者"浏览器".同样的,特定Tab的进程称为"渲染进程"或者"渲染器".渲染器使用Blink开源布局引擎来解释和布局HTML.

管理渲染引擎

每个渲染过程都有一个全局RenderProcess对象，该对象管理与父浏览器进程的通信并维护全局状态。 浏览器为每个渲染进程维护一个相应的RenderProcessHost，它管理渲染器的浏览器状态和通信。 浏览器和渲染器使用Chromium的IPC系统进行通信。

管理视图

每一个Tab的渲染引擎都至少有一个RenderView对象,由RenderProcess管理.相应的RenderProcessHost维护着与渲染器中每个视图对应的RenderViewHost. 每个视图都有一个视图ID,用于区分同一渲染器中的多个视图.每个渲染过程都有一个或多个RenderView对象，由RenderProcess管理，对应于内容选项卡。 相应的RenderProcessHost维护与渲染器中每个视图对应的RenderViewHost.每个视图都有一个视图ID，用于区分同一渲染器中的多个视图.这些ID在同一个渲染器中是唯一的,但在整个浏览器中不是唯一的,因此识别视图需要RenderProcessHost和视图ID.从浏览器到特定Tab的通行是通过这些RenderViewHost对象完成的.这些RenderProcessHost对象知道如何将消息发送给RenderProcess和RenderView.

组件和接口

渲染进程:

• RenderProcess在浏览器中使用相应的RenderProcessHost处理IPC.每个渲染过程只有一个RenderProcess对象.这就是所有浏览器↔渲染器通信的发生方式。
• RenderView对象在浏览器进程（通过RenderProcess）和我们的WebKit嵌入层与其对应的RenderViewHost进行通信。 此对象表示Tab或弹出窗口中的一个网页内容

浏览器进程

• Browser对象代表了顶层的浏览窗口.
• RenderProcessHost对象代表了单个浏览器端↔渲染器的IPC连接, 每个渲染进程在浏览器进程中都有一个RenderProcessHost对象.
• RenderViewHost对象封装了与远程RenderView的通信,RenderWidgetHost在浏览器中处理RenderWidget的输入和绘制.

有关嵌入层是如何工作的更多详细信息，请参阅How Chromium displays web pages。

共享渲染进程

通常,每个新窗口或Tab都会在新进程中打开.浏览器将生成一个新进程并创建一个新的RenderView。

有时，我们希望在能在Tab或窗口之间共享渲染进程. Web应用程序打开新窗口,期望与其同步通信,例如,使用JavaScript中的window.open. 如果进程总数太大,或者用户已经打开到该域的导航,在这种情况下，当我们创建一个新窗口或Tab时，我们需要重用已经打开窗口的进程. 我们还有策略为现有进程分配新Tab.Process Models中描述了这些策略.

检测崩溃和渲染器的异常行为

每个与浏览器进程的IPC连接都会监视进程句柄.如果这些句柄发出信号,则渲染进程已经崩溃,并且会向Tab通知崩溃.现在,我们会显示一个“sad tab”在屏幕上,通知用户渲染器已经崩溃. 可以重新加载按钮或开始可以打开一个新的导航. 发生这种情况时，我们要注意,浏览器并没有任何一个进程并且也不会创建一个新进程.

沙箱渲染器

考虑到渲染器在单独的进程中运行,我们有机会通过沙盒限制其对系统资源的访问. 例如,我们可以确保渲染器只能通过其父浏览器进程访问网络.同样,我们可以使用主机操作系统的内置权限来限制其对文件系统的访问.

恢复内存

考虑到渲染器在单独的进程中运行,那么将隐藏Tab,这种较低优先级的操作变得简单明了.通常,Windows上最小化的进程会将其内存自动放入“可用内存”池中.在内存不足的情况下,Windows会在将此内存转到到硬盘上,而不是转移优先级较高的内存,从而有助于保持用户可见程序的响应速度.我们可以将相同的原则应用于隐藏的Tab.当渲染进程没有顶级Tab时，我们可以释放该进程的“工作集”,作为给系统的提示，以便在必要时首先将该内存转移到磁盘。因为我们发现当用户在两个标签之间切换时,减小工作集大小也会降低Tab切换性能,所我们会逐步释放这个内存.这意味着如果用户切换回最近使用的Tab时,该Tab的内存比最近使用的Tab更容易被换入.当有足够内存来运行所有程序时,用户根本不会注意到这个过程:Windows只会在需要时才会回收这些数据,因此在内存充足时不会有性能损失.

这有助于我们在低内存情况下获得更佳的内存占用. 与很少使用的后台Tab相关联的内存可以完全换出，而前台Tab的数据可以完全加载到内存中。 相比之下，单进程浏览器将所有选项卡的数据随机分布在其内存中，并且不可能如此干净地分离已使用和未使用的数据，从而浪费内存和性能。

插件和扩展程序

Firefox风格的NPAPI插件在自己的进程中运行，与渲染器分开。 这在Plugin Architecture中有详细描述。
Site Isolation项目旨在提供渲染器之间的更多隔离，此项目的早期成果包括在隔离进程中运行Chrome HTML / JavaScript内容的扩展程序。

最近开发功能的时候monkey总是能跑出一个bug,
java.lang.RuntimeException: Could not read input channel file descriptors from parcel.
百思不得其解,认为是系统上面的bug,实时证明自己还是太年轻.现在开始分析一下这个bug产生的原因.

一.为什么会产生句柄泄露?

众所周知Android是linux内核,也就是可以理解linux下,一切资源都是句柄,每个进程都有自己的句柄上限,而超过了这个句柄上线,就会发生异常.一般android的App都是在单个进程下运行的,FD的句柄上限是1024,这个在后面的会说明.一切的重点都在**proc(Processes,虚拟的目录，是系统内存的映射。可直接访问这个目录来获取系统信息。 )**这个文件夹下的内容.
这里有参考The proc File System.

The Linux kernel has two primary functions: to control access to physical devices on the computer and to schedule when and how processes interact with these devices. The /proc/ directory — also called the proc file system — contains a hierarchy of special files which represent the current state of the kernel — allowing applications and users to peer into the kernel's view of the system.

Within the /proc/ directory, one can find a wealth of information detailing the system hardware and any processes currently running. In addition, some of the files within the /proc/ directory tree can be manipulated by users and applications to communicate configuration changes to the kernel.

Linux系统上的/proc目录是一种文件系统，即proc文件系统。与其它常见的文件系统不同的是，/proc是一种伪文件系统（也即虚拟文件系统），存储的是当前内核运行状态的一系列特殊文件，用户可以通过这些文件查看有关系统硬件及当前正在运行进程的信息，甚至可以通过更改其中某些文件来改变内核的运行状态。

二.查看进程的句柄信息

我们通过proc这个虚拟文件系统,可以获取到当前App的进程,然后查看具体的进程信息,当前App是否存在句柄泄露的问题.具体方法如下.

    public class MainActivity extends Activity {
	    private PageView mPageView;
	    private Button mButton;

	    @Override
	    protected void onCreate(Bundle savedInstanceState) {
		 super.onCreate(savedInstanceState);
		 setContentView(R.layout.activity_main);
		 exeCommand("ps");

	    }

	    private void exeCommand(String command){
		   Runtime runtime = Runtime.getRuntime();
		   try {
			   Process proc = runtime.exec(command);
			   BufferedReader in = new BufferedReader(new InputStreamReader(proc.getInputStream()));
			   String line;
			   while ((line = in.readLine()) != null) {
				   System.out.println(line);
			   }
		   } catch (IOException e) {
			   e.printStackTrace();
		   }
	   }
    }

这样我们看到在Android Studio的logcat中打印出了当前所有的进程号.

然后我们继续修改我们的代码.

exeCommand("ps | grep com.behanga");

com.behanga是我测试App的名字.

这是我们可以看到该App的进程号是16023,也就是说对应在proc中对应的文件夹为/proc/16023/,在这个文件夹下我们看到当前App的信息,好我们继续往下查看.
这时我们打开terminal,输入

adb shell

进入adb shell,然后输入

cd /proc/16023 && ls -al

现在展示在我们面前的就是当前进程下信息.

我们现在可以查看一下当前进程一些限制.

cat limits

这里我们看到Max open fils的限制为1024,硬件限制为4096,也就是说我们当前打开文件句柄的最大数为1024.

这时我们继续往下看,因为是要分析file descriptors的问题,那么自然要进入fd目录下一看究竟.

cd fd && ls -al

当前展示了所在进程下所有已经被打开的文件句柄.我们可以在当前文件夹下统计所有的句柄总数.

ls | wc -l

这时打印出所有的句柄总数为64.这时我们已经完成对当前进程的一些句柄信息查看.

三.模拟句柄泄露情况

如果我们要模拟句柄泄漏的情况,我们可以在App中启动一个HandlerThread,每次在onCreate的时候HandlerThread.start(),但是在onDestory()时,并不调用HandlerThread.quit()方法.重复进入.然后在terminal中统计FD的总数,查看是否有变化,如果FD的总数一直在增加,就可以确认你当前App中已经出现了句柄泄露的情况.

四.如何避免句柄泄露的发生

提高对编码意识,另外就是monkey的测试,很多时候会发现一些黑盒测试无法发现的问题.

this.queryParams = this.$route.query
this.$router.onReady(() => {
   this.$router.push({ query })
})