binder

刚刚过去2019，新的一年2020年。都说衣不如新人不如故，技术是学新不学旧的？可是旧的知识不巩固，根基不固很容易在面试或者实战遇到很大的问题的 以下知识点PDF版后续可见 更多面试内容等等 更多完整项目下载。未完待续。源码。图文知识后续上传github。 可以点击 关于我 联系我获取 https://github.com/xiangjiana/Android-MS 一丶线程篇 1、线程池的好处？ 四种线程池的使用场景，线程池的几个参数的理解？ 参考答案 ： 使用线程池的好处是减少在创建和销毁线程上所花的时间以及系统资源的开销，解决资源不足的问题。如果不使用线程池，有可能造成系统创建大量同类线程而导致消耗完内存或则“过度切换”的问题，归纳总结就是 重用存在的线程，减少对象创建、消亡的开销，性能佳。 可有效控制最大并发线程数，提高系统资源的使用率，同时避免过多资源竞争，避免堵塞 提供定时执行、定期执行、单线程、并发数控制等功能。 Android 中的线程池都是直接或间接通过配置 ThreadPoolExecutor 来实现不同特性的线程池.Android 中最常见的类具有不同特性的线程池分别为： newCachedThreadPool ： 只有非核心线程，最大线程数非常大，所有线程都活动时会为新任务创建新线程,否则会利用空闲线程 ( 60s 空闲时间,过了就会被回收,所以线程池中有

刚刚过去2019，新的一年2020年。都说衣不如新人不如故，技术是学新不学旧的？可是旧的知识不巩固，根基不固很容易在面试或者实战遇到很大的问题的 以下知识点PDF版后续可见 更多面试内容等等 (更多完整项目下载。未完待续。源码。图文知识后续上传github。) ( VX：mm14525201314 ) https://github.com/xiangjiana/Android-MS 一丶线程篇 1、线程池的好处？ 四种线程池的使用场景，线程池的几个参数的理解？ 参考答案 ： 使用线程池的好处是减少在创建和销毁线程上所花的时间以及系统资源的开销，解决资源不足的问题。如果不使用线程池，有可能造成系统创建大量同类线程而导致消耗完内存或则“过度切换”的问题，归纳总结就是 重用存在的线程，减少对象创建、消亡的开销，性能佳。 可有效控制最大并发线程数，提高系统资源的使用率，同时避免过多资源竞争，避免堵塞 提供定时执行、定期执行、单线程、并发数控制等功能。 Android 中的线程池都是直接或间接通过配置 ThreadPoolExecutor 来实现不同特性的线程池.Android 中最常见的类具有不同特性的线程池分别为： newCachedThreadPool ： 只有非核心线程，最大线程数非常大，所有线程都活动时会为新任务创建新线程,否则会利用空闲线程 ( 60s 空闲时间,过了就会被回收

一、Binder框架 Binder用于完成进程间通信（IPC），比如普通应用程可以调用音乐服务，它工作在内核态，属于一个驱动，只是这个驱动要用的“硬件”是内存。 Binder架构由三个模块构成：服务端接口，Binder驱动，客户端接口。我们分开来看： 服务端 一个Binber服务端实际上是一个Binder类的对象，且一旦创建，内部就启动一个隐藏线程，用来接收Binder驱动发送的消息，收到消息后，会执行Binder对象中的onTransact()方法，并执照不同的参数执行不同的服务代码，所以实现一个Binder对象一定要重载onTransact()方法，onTransact()方法的参数来自于客户端调用transact()方法时的输入，两者的格式和顺序一定要一样。 Binder驱动 当服务端Binder对象创建时，同时会在Binder驱动中创建一个mRemote对象（这里不会再有新的线程），mRemote也是Binder类。当客户端访问远程服务时，是通过 mRemote对象 。 客户端 要访问服务端，先得到远程对象对应的mRemote对象,然后就可以调用其transact()方法，而在Binder驱动中，mRemote对象也重载了transact()方法，重载的内容重要是： 1.以线程间通信的模式，向服务端发送客户端传递过来的参数。 2.挂起当前线程（客户端线程）

文章目录 1. 抓取Bugreport方法 2. MEMINFO内存相关 2.1 dumpsys MEMINFO 2.2 cat MEMINFO 2.3 dumpsys PROCRANK 2.4 showmap 总结 3. CPUINFO 3.1 dumpsys cpuinfo 3.2 top 4. PROCESSES AND THREADS (进程和线程) 5. PRINTENV环境变量 6. Android Log(main system kernel event radio) 6.1 kernel log 6.2 SYSTEM EVENT RADIO log 7. lsof 8. getprop 9. binder 10. activity 11. package 12. crash 12.1 system_server_crash 12.2 system_app_crash 13. dumpsys -l 14. trace 14.1 dump java trace 14.1 dump native trace 1. 抓取Bugreport方法 执行命令adb bugreport就可以生产文件 下面内容是介绍bugreport里面内容 2. MEMINFO内存相关 Item 全称 含义 等价 USS Unique Set Size 物理内存 进程独占的内存 PSS

1. 介绍 Binder是Android下基于C/S架构的进程间通信机制，基于开源OpenBinder 从实现上来说可分为Binder驱动、ServiceManager、Server、Client四个组成部分 2. Binder驱动 Binder驱动代码主要位于drivers/android目录 2.1 数据结构 数据结构 说明 2.2 初始化 binder_init() /* * 创建如下目录和文件 * 目录 * /sys/kernel/debug/binder * /sys/kernel/debug/binde/proc * 文件 * $(BINDER_PROC)/state -- 记录状态信息 * $(BINDER_PROC)/stats -- 记录统计信息 * $(BINDER_PROC)/transactions -- 记录transaction相关信息 * $(BINDER_PROC)/transaction_log -- 记录transaction日志相关信息 * $(BINDER_PROC)/failed_transaction_log -- 记录失败的transaction日志相关信息 * 文件读取函数依次为 * binder_state_show() * binder_stats_show() * binder_transactions_show() *

看到android设备的进程列表，发现了好多个进程。但是回忆最近的android app开发，发现所有的相关处理和面试都是集中在systemServer中的，而关于zytote和ServiceManager的东西实际考察和使用较少。 突然想问自己，三者在android中的关系是怎样的。就这个问题，写个比较总结下。 1. 启动顺序关系 ServiceManager最先启动，Zygote再启动，最后启动systemServer。启动顺序决定了进程的依赖性。 1. 启动Zygote目的，就是为了启动systemServer进程。所有的java进程启动都由Zygote完成，systemServer是一个java进程。那么Zygote必然需要在systemServer之前启动。 2. ServiceManager最先启动的理由：systemServer的启动中有很多service启动，而这些service启动后，需要使用binder和实际的服务通讯。给ServiceManager中的service提供服务的主体服务服务器由init进程启动，service和主体服务之间的通讯依赖于binder，ServiceManager就是给service和主体服务之间实现通讯的工具。 因此service和主体服务都依赖于ServiceManager，那么ServiceManager 必然是最先启动。 2.

Service全部内容基本会在本篇涉及到，我们将围绕以下主要知识点进行分析： Service简单概述 Service在清单文件中的声明 Service启动服务实现方式及其详解 Service绑定服务的三种实现方式 关于启动服务与绑定服务间的转换问题 前台服务以及通知发送 服务Service与线程Thread的区别 管理服务生命周期的要点 Android 5.0以上的隐式启动问题及其解决方案 保证服务不被杀死的实现思路 1.Service简单概述   Service(服务)是一个一种可以在后台执行长时间运行操作而没有用户界面的应用组件。服务可由其他应用组件启动（如Activity），服务一旦被启动将在后台一直运行，即使启动服务的组件（Activity）已销毁也不受影响。 此外，组件可以绑定到服务，以与之进行交互，甚至是执行进程间通信 (IPC)。 例如，服务可以处理网络事务、播放音乐，执行文件 I/O 或与内容提供程序交互，而所有这一切均可在后台进行，Service基本上分为两种形式： 启动状态   当应用组件（如 Activity）通过调用 startService() 启动服务时，服务即处于“启动”状态。一旦启动，服务即可在后台无限期运行，即使启动服务的组件已被销毁也不受影响，除非手动调用才能停止服务， 已启动的服务通常是执行单一操作，而且不会将结果返回给调用方。 绑定状态  

   Android Binder机制(十) getService详解之请求的发送    在前面的篇章中，我们以MediaPlayerService为例，介绍了Service服务是如何通过addService请求添加到ServiceManager中的(其中的艰难困苦，你懂的)。本文，将以MediaPlayer获取MediaPlayerService服务为例，来介绍Client端是如何通过getService请求从ServiceManager中获取到Server接入点的。在本文的getService请求中，MediaPlayer是Client端，它要获取的Server接入点是MediaPlayerService。和前面介绍addService篇章一样，在分析getService时，会将文章分为请求的发送，请求的处理，和请求的反馈这三部分来分别进行介绍(不要问我为啥是三部分，因为内容太多)。 注意 ：本文是基于Android 7.xx版本进行介绍的 getService整体概述    老规矩，在大讲特讲之前，还是让我们上图说话，这样让读者先从整体上有一个了解，然后再深入细节，这个可不是谈女朋友额。上图： 猛地一看，你会发现该时序图和 Android Binder机制(六) addService详解之请求的发送 中的时序图几乎是一模一样的，难道是换了马甲不成，还不允许别人长一个样了啊

前言 概要 解剖 asInterface asBinder IInterface DESCRIPTOR onTransact服务端接收 transact客户端调用 总结 前言 继 上一篇AIDL 的简单介绍，相信应该对AIDL有一个大致的了解，那么这一篇我们来深入探讨一下AIDL为什么能够完成这个跨进程操作，这其中是否隐藏着一些不为人知的秘密，让我们跟着笔者的思路，慢慢拨开笼罩在AIDL上的谜团。 概要 先用上图整体描述这个AIDL从客户端(Client)发起请求至服务端(Server)相应的工作流程，我们可以看出整体的核心就是Binder 解剖 asInterface 用于将服务端的Binder对象转换成客户端所需的AIDL接口类型的对象，这种转换过程是区分进程的【如果客户端和服务端位于同一进程，那么此方法返回的就是服务端的Stub对象本身，否则返回的是系统封装后的Stub.proxy对象】 private ServiceConnection connection = new ServiceConnection() { @Override public void onServiceConnected(ComponentName name, IBinder service) { IDemandManager demandManager = IDemandManager.Stub

在上一篇，我们学习了通过startService来启动Service，由于篇幅过长，所以这一篇是接上一篇的 二、bindService方法启动Service 先看 bindSerivce(Intent service,ServiceConnection conn,int flags) 函数 参数说明： service： 通过该参数也就是Intent我们可以启动指定的Service conn： 该参数是一个ServiceConnection对象，这个对角用于监听访问者（也可以说成是客户端）与Service之间的连接情况，当访问者与Service连接成功时将回调ServiceConnection对象的onServiceConnected(ComponentName name,Ibinder service)方法；如果断开将回调onServiceDisConnected(CompontName name)方法 flags： 指定绑定时是否自动创建Service。 步骤： 1、 新建一个类继承于Service类，重写onBind()、onCreate()、onUnBind()、onDestory()方法。再在这个类里声明一个Ibinder的子类对象用于提供于客户端，同时可以定义一些成员变量，客户端可以获取到这个成员变量属性 2、 在AndroidMainfest