Android 常用的数据结构及优缺点

Android 常用的数据结构有八种：数组（Array），栈（Stack），链表（Linked List），图（Graph），队列（Queue），树（Tree），堆（Heap），散列表（Hash）；

适配器就是就是把一些数据给弄得适当,适合以便于在View上显示。

1、Android适配器是数据和视图之间的桥梁，以便于数据在View上显示。适配器就像显示器，把复杂的东西按人可以接受的方式来展现。我们常用的适配器一共有三个：ArrayAdapter，SimpleAdapter，SimpleCursorAdapter 这三个，他们都是继承于BaseAdapter 。

2、Android是一种基于Linux的自由及开放源代码的 *** 作系统，主要使用于移动设备，如智能手机和平板电脑，由Google公司和开放手机联盟领导及开发。尚未有统一中文名称，中国大陆地区较多人使用“安卓”或“安致”。Android *** 作系统最初由Andy Rubin开发，主要支持手机。

本篇文章针对向ServiceManager注册服务 和 获取服务两个流程来做总结。在这两个过程中，ServiceManager都扮演的是服务端，与客户端之间的通信也是通过Binder IPC。

在此之前先了解下Binder的进程与线程的关系：

用户空间 :ProcessState描述一个进程，IPCThreadState对应一个进程中的一个线程。

内核空间 ：binder_proc描述一个进程，统一由binder_procs全局链表保存，binder_thread对应进程的一个线程。

ProcessState与binder_proc是一一对应的。

Binder线程池 ：每个Server进程在启动时会创建一个binder线程池，并向其中注册一个Binder线程；之后Server进程也可以向binder线程池注册新的线程，或者Binder驱动在探测到没有空闲binder线程时会主动向Server进程注册新的的binder线程。对于一个Server进程有一个最大Binder线程数限制15，(#define DEFAULT_MAX_BINDER_THREADS 15)。对于所有Client端进程的binder请求都是交由Server端进程的binder线程来处理的。我的理解是：binder线程是进程进行binder ipc时的一条数据处理路径。

MediaPlayerService向ServiceManager注册过程如下：

相关类：

整个过程总结如下：

1 获取BpServiceManager 与 BpBinder

由defaultServiceManager()返回的是BpServiceManager，同时会创建ProcessState对象和BpBinder对象。然后通过BpBinder执行transact，把真正工作交给IPCThreadState来处理。

2 BpBinder transact

Binder代理类调用transact()方法，真正工作还是交给IPCThreadState来进行transact工作。

3 通过IPCThreadState 包装并转换数据并进行transact事务处理

每个线程都有一个IPCThreadState，每个IPCThreadState中都有一对Parcel变量：mIn、mOut。相当于两根数据管道：

最后执行talkWithDriver。

writeTransactionData：将BC Protocol + binder_transaction_data结构体 写入mOut， 然后执行waitForResponse：

由talkWithDriver将数据进一步封装到binder_write_read结构体，通过ioctl（BINDER_WRITE_READ）与驱动通信。同时等待驱动返回的接收BR命令，从mIn取出返回的数据。

mIn包装的数据结构(注册服务handle = 0 ，code 为ADD_SERVICE_TRANSACTION)：

4 Binder Driver

把binder_write_read结构体write_buffer里数据取出来，分别得到BC命令和封装好数据的事务binder_transaction_data, 然后根据handler，在当前binder_proc中，找到相应的binder_ref，由binder_ref再找到目标binder_node实体，由目标binder_node再找到目标进程binder_proc。然后就是插入数据：当binder驱动可以找到合适的线程，就会把binder_transaction节点插入到servciemanager的线程的todo队列中，如果找不到合适的线程，就把节点之间插入servciemanager的binder_proc的todo队列。

5 ServiceManager

经过Binder Driver的处理，数据已经到了ServiceManager进程，在BR_TRANSACTION的引导下，在binder_loop（）中执行binder_parser（）取出数据，执行do_add_service（） *** 作，最终向 svcinfo 列表中添加已经注册的服务（没有数据的返回）。最后发送 BR_REPLY 命令唤醒等待的线程，通知注册成功。结束MediaPlayerService进程 waitForResponse()的状态，整个注册过程结束。

获取服务的过程与注册类似，首先 ServiceManager 向 Binder 驱动发送 BC_TRANSACTION 命令携带 CHECK_SERVICE_TRANSACTION 命令，同时获取服务的线程进入等待状态 waitForResponse()。Binder 驱动收到请求命令向 ServiceManager 的发送 BC_TRANSACTION 查询已注册的服务，会区分请求服务所属进程情况。

查询到直接响应 BR_REPLY 唤醒等待的线程。若查询不到将与 binder_procs 链表中的服务进行一次通讯再响应。

以startService为例来简单总结下执行流程：

31 从方法执行流程来看：

Client ：

1 AMPstartService 标记方法以及通过Parcel包装数据；

2 BinderProxytransact 实际调用native的 android_os_BinderProxy_transact 传递数据；

3 获取BpServiceManager 与 BpBinder 同时会创建ProcessState。然后通过BpBinder执行transact，把真正工作交给IPCThreadState来处理；

4 IPCtransact 主要执行writeTransactionData，将上层传来的数据重新包装成binder_transaction_data，并将BC Protocol + binder_transaction_data结构体 写入mOut；

5 IPC waitForResponse talkWithDriver + 等待返回数据；

6 talkWithDriver 将数据进一步封装成binder_write_read，通过ioctl（BINDER_WRITE_READ）与驱动通信；

Kernel :

7 binder ioctl 接收BINDER_WRITE_READ ioctl命令；

8 binder_ioctl_write_read 把用户空间数据ubuf拷贝到内核空间bwr；

9 binder_thread_write 当bwr写缓存有数据，则执行binder_thread_write；当写失败则将bwr数据写回用户空间并退出；

10 binder_transaction 找到目标进程binder_proc并插入数据到目标进程的线程todo队列，最终执行到它

时，将发起端数据拷贝到接收端进程的buffer结构体；

11 binder_thread_read 根据binder_transaction结构体和binder_buffer结构体数据生成新的binder_transaction_data结构体，写入bwr的read_buffer，当bwr读缓存有数据，则执行binder_thread_read；当读失败则再将bwr数据写回用户空间并退出；最后，把内核数据bwr拷贝到用户空间ubuf。

12 binder_thread_write + binder_ioctl BR命令和数据传递

Server:

13 IPCexecuteCommand 解析kernel传过来的binder_transaction_data数据，找到目标BBinder并调用其transact()方法;

14 IPCjoinThreadPool 采用循环不断地执行getAndExecuteCommand()方法, 处理事务。当bwr的读写buffer都没有数据时,则阻塞在binder_thread_read的wait_event过程 另外,正常情况下binder线程一旦创建则不会退出

15 BBindertransact 到BinderexeTransact 调用 AMNonTransact

16 AMNonTransact 把数据传递到AMSstarService去执行

17 AMSstarService Server处理了Client的请求了

然后原路replay回去，talkWithDriver 到Kernel ，然后找到Client进程，把数据拷贝到read_buffer里，最终唤醒IPC，把反馈传递回AMPstartService。完成启动服务。

32 从通信协议流程来看：

非oneWay:

oneway:

oneway与非oneway区别: 都是需要等待Binder Driver的回应消息BR_TRANSACTION_COMPLETE 主要区别在于oneway的通信收到BR_TRANSACTION_COMPLETE则返回,而不会再等待BR_REPLY消息的到来 另外，oneway的binder IPC则接收端无法获取对方的pid

33 从数据流来看

从用户空间开始：

进入驱动后：

回到用户空间：

参考：

>

基于hashing的原理，jdk8后采用数组+链表+红黑树的数据结构。我们通过put和get存储和获取对象。当我们给put()方法传递键和值时，先对键做一个hashCode()的计算来得到它在bucket数组中的位置来存储Entry对象。当获取对象时，通过get获取到bucket的位置，再通过键对象的equals()方法找到正确的键值对，然后在返回值对象。

当数组table的size达到阙值时即++size > load factor capacity 时，也是在putVal函数中。

扩容需要重新分配一个新数组，新数组是老数组的2倍长，然后遍历整个老结构，把所有的元素挨个重新hash分配到新结构中去。

对key的hashCode进行hashing，与运算计算下标获取bucket位置，如果在桶的首位上就可以找到就直接返回，否则在树中找或者链表中遍历找，如果有hash冲突，则利用equals方法去遍历链表查找节点。

对key的hashCode做hash *** 作，与高16位做异或运算。

还有平方取中法，除留余数法，伪随机数法。

因为数组位置的确定用的是与运算，仅仅最后四位有效，设计者将key的哈希值与高16为做异或运算使得在做&运算确定数组的插入位置时，此时的低位实际是高位与低位的结合，增加了随机性，减少了哈希碰撞的次数。

会产生哈希碰撞，若key值相同则替换旧值，不然链接到链表后面，链表长度超过阙值8就转为红黑树存储。

HashCode相同，通过equals比较内容获取值对象。

超过阙值会进行扩容 *** 作，概括的讲就是扩容后的数组大小是原数组的2倍，将原来的元素重新hashing放入到新的散列表中去。

相同点：都是存储key-value键值对的

不同点：

loadFactor表示HashMap的拥挤程度，影响hash *** 作到同一个数组位置的概率。默认loadFactor等于075，当HashMap里面容纳的元素已经达到HashMap数组长度的75%时，表示HashMap太挤了，需要扩容，在HashMap的构造器中可以定制loadFactor。

JDK 18 以前 HashMap 的实现是 数组+链表，即使哈希函数取得再好，也很难达到元素百分百均匀分布。当 HashMap 中有大量的元素都存放到同一个桶中时，这个桶下有一条长长的链表，这个时候 HashMap 就相当于一个单链表，假如单链表有 n 个元素，遍历的时间复杂度就是 O(n)，完全失去了它的优势。针对这种情况，JDK 18 中引入了 红黑树（查找时间复杂度为 O(logn)）来优化这个问题。但是链表大于8的概率是非常非常低的。

选择Integer，String这种不可变的类型，像对String的一切 *** 作都是新建一个String对象，对新的对象进行拼接分割等，这些类已经很规范的覆写了hashCode()以及equals()方法。作为不可变类天生是线程安全的。如果要使用自定义类做为Key，就需要重写hashCode()以及equals()方法。红黑树在做比较的时候使用的是SystemidentityHashCode()方法，是不需要做特殊处理的。

更多内容戳这里（整理好的各种文集）

我简单写下代码，我的思想是使用数据库链表填充，先看代码吧：

//数据库怎么 *** 作读取数据我就不写了，假如我现在有了dataset对象ds，在查数据表的时候我们就把顺序排列好

for(int i=0;i<dsTables[0]RowsCount;i++)

{

   treeNodesAdd(dsTables[0]Rows[i]["列名"]ToString());

}

如果要加入子节点，那我们就加完父节点再查找子节点，挨个加进去：

//建立个ds返回对象，以父节点作为参数

for(int i=0;i<dsTables[0]RowsCount;i++)

{

   treeNodesAdd(dsTables[0]Rows[i]["列名"]ToString());

} 

foreach(TreeNodes td in treeNodes)

{

   for(int j=0;j<tdText)Tables[0]RowsCount;i++)

   {

       tdAdd(dss(tdText)Tables[0]Rows[j]["列名"]ToString());

   }

}

以上就是关于Android 常用的数据结构及优缺点全部的内容，包括:Android 常用的数据结构及优缺点、android中的适配器是什么东东、Android通信方式篇（七）-Binder机制（Native层（下））等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！