JasonWang's Blog

socket通常用于跨进程通信(Inter-Process Communication,IPC)，由于其最早BSD Unix发行版中使用，因此也叫做Barkeley sockets。socket封装了底层网络通信协议细节，为上层应用提供了一个统一的接口，按照使用的“域”不同，又分为用于网络通信的internet socket以及用于本地进程通信的Unix domain socket。

那么，如何利用socket实现IPC通信了？在多个客户端的情况下，服务端要如何实现同时响应多个客户请求了，即如何实现多个IO端口的监听(I/O multiplex)？这篇文章，就来看看这两个问题。首先，来看下socket编程的一些基本知识。

社会或法律就是这样或者应当这样起源的。它们给弱者新的桎梏， 给富人以新的力量。

卢梭

Telephony(RIL Java,以下简称RILJ）与RILD(RIL Daemon)的通信在Android OO8.0以前都是基于socket通信，而Android 8.0则是基于HAL binder进行IPC的数据交换。有关RILJ与RILD的工作原理可以参考之前的两篇文章：Android RIL概述以及RILD详解。这篇文章主要分析RILJ与RILD是如何通过HAL Binder进行通信。

RILJ与RILD的通信，服务端是RILD,客户端是RILJ。对于RILD而言，其对应的HAL接口是/android/hardware/interfaces/radio/1.0/IRadio.hal:

HAL binder是Android O(8.0)专门用于HAL（Hardware Abstract Layer)层（native）进程与其clients之间的通信机制（clients可以是native进程，也可以是Java Framework进程)。 HAL binder替代了早先使用的socket通信，其kernel层实际是基于原有的binder驱动，但为了配合Client与Server之间的数据传输，需要使用特定的中间层HIDL来进行接口与数据的转换。那么，相对之前的HAL通信方式（socket），基于HIDL的HAL通信有什么优势了？从系统架构的角度，HIDL为客户端与服务端提供了清晰的接口；从效率的角度，binder IPC实际在传输数据上只有一次拷贝，而socket实际传输需要两次数据拷贝。

目前Android有两种类型的HAL：

• binder化的HAL： 利用HIDL(HAL interface Definition Language)来描述HAL接口，Framework层与HAL层通过binder IPC的方式进行通信；如下的HAL模块都是利用binder IPC来进行通信的:

  • android.hardware.biometrics.fingerprint@2.1
  • android.hardware.configstore@1.0
  • android.hardware.dumpstate@1.0
  • android.hardware.graphics.allocator@2.0
  • android.hardware.radio@1.0
  • android.hardware.usb@1.0
  • android.hardware.wifi@1.0
  • android.hardware.wifi.supplicant@1.0

• 直通式HAL： 基于HIDL或者传统HAL方式来实现，在这种模式下，Framework层与HAL层的通信可以通过IPC的方式进行，也可以使用共享内存的方式在同一个进程内进行（passthrough,直通）。目前有如下两个HAL模块使用直通式方式进行通信：

  • android.hardware.graphics.mapper@1.0
  • android.hardware.renderscript@1.0

HTTP 自从上世纪90年代随着WEB的诞生而出现的，是所有WEB应用的基础。随着网络购物、电子商务、网上银行等逐渐普及，HTTP本身存在信息窃听与身份伪装等问题，已很难满足人们对于可信安全的通信环境的需求了。如何确保用户隐私与数据不被非法获取，这是HTTPS（HTTP Secure )需要解决的问题。使用HTTPS协议的网站，一般都以https开头而不是http，如:https://tools.ietf.org/html/rfc2246 。

那么，从数据安全的角度来看，HTTP有哪些不足了？

• HTTP本身不具备加密功能，因此请求与响应都没有经过加密，而使用的是不加密的明文，因此内容可能会被窃听；
• 通信时不会验证通信方（client/server)的身份，任何人都可以发送请求，而服务器对于所有请求也照单全收，因此客户端与服务端都有可能被伪装；
• 在传输数据时，报文可能被篡改或者攻击，无法保证报文的完整性(integrity);这种在请求与数据传输过程中，被攻击者拦截并篡改的攻击方式被称为中间人攻击(Man-in-the-middle attack );

作为文化的中国，其实已经灭亡了。。。为什么中国人在这一百多年，老是把传统和现代，把西方文化和中国文化对立起来，为什么我们不能像欧洲那样把传统和现代的关系处理的那么好？

粟宪庭

Java将所有运行时的分配的对象保存到堆(heap)中，虚拟机通过诸如new,newarray,anewarray以及multianewarray等指令来分配对象，但并不会在代码中显式的释放这些内存区域，而是由虚拟机中自带的内存回收器(Garbage Collection，以下简称GC）来负责内存分配、压缩以及回收。GC的主要任务就是找到堆中那些不再被引用的内存对象，将其回收用于分配新的对象；同时，GC还要负责压缩堆内存分片，减少内存碎片，确保新的对象有足够的连续空间可以使用。GC让开发人员不用再担心内存释放的问题，提升了开发效率；在另外一个方面，GC使开发人员不用再担心错误的释放了某个对象，确保了程序的完整性。但使用GC的一个潜在弊端是，GC在收集内存时会增加程序负担，减低程序运行效率。

接下来，就来看看Java虚拟机中常用的垃圾回收算法。

垃圾收集算法

任何垃圾收集算法都需要做如下几件事情：

• 检测需要回收的对象；
• 回收“垃圾”对象所占用的内存，将这些内存提供给程序使用；
• 对内存进行去碎片化处理；

Java诞生于互联网兴盛的上世纪90年代，为了在不同终端设备上运行Java程序，其在设计之初，就考虑到了语言的可移植性，确保编写完后，可以在任何平台上运行。随着互联网时代的来临，Java因其平台无关性（platform independence), 安全性(security)、网络可移动性(network mobility)以及内存自动管理(Garbage Collection)等特征而得到了广泛的应用。那么， Java的这些特性究竟是如何实现的？相比早前的C/C++等编译型语言，Java程序首先被编译成一个个包含了字节码(bytecode)的.class文件，运行时，.class文件被加载Java虚拟机（Java Virtual Machine)上执行。实际上，任何其他语言只要能够编译成JVM能够识别的bytecode， JVM都可以执行

Android从5.0开始添加了一个任何调度服务JobSchedulerService,APP可以通过该服务进行各种任务的调度，如定时任务，与服务器同步资源，下载特定信息等。由于JobScheduler通过收集各个应用的调度任务，采用批处理的方式，允许多个任务同时运行，可以让设备具有更长的睡眠时间， 从而延长了电池使用。这篇文章，主要从应用与原理两个方面讲述分析JobScheduler。

通信网络中的两个节点需要交换数据,通常有两种数据传输方式: Circuit Switching (CS, 链路交换)以及Packet Switching (PS, 分组交换)。链路交换早在19世纪便在电讯行业中使用了。对于CS网络，呼叫方（caller）首先需要与被被叫方（callee）建立一个专用的链接，通信才可能进行，双方通信期间，需要占用一定的频带或者时间资源，通信结束，资源才会释放，如果网络出现拥塞，无法分配资源，则通信失败 。下图是链路交换网络通信示意图：