maniuT的博客

（1）获取User类的全部类信息，包括方法、字段、SUID等等，将其封装在ObjectStreamClass中；（2）在拿到全部类信息后，会将全部的类信息以及字段数据转换成二进制数据。从源码中我们可以看到，在统计类信息的时候，会检查两个方法是否存在，readObject和writeObject，而且只要实现了这两个方法，那么就不会走defaultWriteFields方法，

以终为始，还是要问一问为什么，即我们为什么要学习Handler消息机制，Handler消息机制有什么作用？首先，你要知道，Handler消息机制和Handler不一样哦，Handler只是指Handler这个具体类，而Handler消息机制是包括Handler在内的一系列相关类组成的一个机制。Handler消息机制里面，有几个非常关键的角色，需要逐个捋清。下面，咱们挨个说说综上，关于ThreadLocal，可以这样描述它能够映射线程本地变量，映射的原理，就是不同的线程，ThreadLocalMap不同。

{// ...getName(): 当前transform的名字，能够在打包过程中看到它对应生成的。: 指定要处理的输入类型，上面的设置就表示只处理字节码，不处理资源。getScope(): 表示处理输入的范围，上面的设置表示整个项目的所有module和所有的依赖。: 表示是否支持增量更新，最好选择是。如果是否的话，每次打包都相当于清除缓存后重新打包；如果是是的话，只会处理修改后的文件。: 方法为处理插桩的入口函数。

在Java层， 创建Socket的方式是直接构造 java.net.Socket对象，我们先跟踪其构造函数的实现。在构造函数中，会调用setImpl()函数，继续跟踪setImple()实现setImpl()函数先判断 factory是否为空，如果不为空则 使用factory创建SocketImpl实例，否则直接通过 SocksSocketImple()构造函数创建。

根据以上分析和实际测试结果，第一次同步的时候，两个方案速率相近，而第一次同步完成之后，新的方案效率就高得多。因为第一次同步的时候，两种同步方案可能都需要对远程的全部文件进行拉取。而第一次之后，新的同步方案只需要判断文件的上次修改时间，因此请求的数量和所有目录、子孙目录的数量相近（每次至少请求一次目录下的文件/目录信息）。实际测试结果表明，600 个文件同步一次只需要 60s （其中，为避免向服务器请求过于频繁，每个文件处理延时时间为 50ms）.以上就是基于 Android 系统的文件同步设计思路的分享。

分享一个没什么技术含量但是我觉得挺有意思的东西，很多第三方SDK初始化的时候都需要我们传入一个context进去，拿到context之后SDK就可以做很多事了，比如打开activity、弹窗、获取文件目录之类的。这里我想简单的去处理下它们的使用权限，给它们传入一个被代理的context，让它们无法为所欲为。

最近一直忙于音视频SDK的开发，遇到很多问题，简单来说，就是怎么让别人接入SDK时越简单越好。相信大多数Android开发都会遇到一个场景，给TextView或Button添加背景颜色，修改圆角，描边等需求。一看到这样的实现效果，自然就是创建drawble文件，设置相关属性shap，color，radius等。然后将drawble文件设置给对应的view即可实现想要的效果。但是作为一个SDK，如果不同的app都需要修改自己独特的颜色，圆角等需求，如何以最小的改动来满足不同app的需求呢？

在 Android Framework 中有两个主要的主线程Handler，一个是中的H，它主要来处理四大组建的各种生命周期；还有一个是中的，它主要负责绘制，动画，输入等操作。这两个Handler负责的工作和用户体验都极为密切，主线程也可以说非常忙。在项目中我经常发现很多的代码都会在主线程执行，明明有的操作不需要主线程执行。

内存泄漏是指 Android 进程中，某些对象已经不再使用，但被一些生命周期更长的对象引用，导致其占用的内存资源无法被GC回收，内存占用不断增加的一种现象；方法，可以看到这个本地方法把我们的 Activity 传进去了，后续处理不得而知，但基于上面的内存分析我们基本可以断定，正是由于这个方法，Activity 的引用被 Native 的长生命周期对象持有，导致 Activity 出现内存泄漏。但有两个疑问，一是这个内部类是写在方法里的，方法结束时，不会把方法栈中的内部类引用清除掉吗？

这几年，社会问题层出不穷，最头疼的就是民生就业问题，大厂裁员，小厂倒闭，每年大批量的应届毕业生也涌入就业市场。近几日，统计局也发布了就业相关数据，，面对此数据，我们能想到的是实际的失业人数肯定会比公布的数据要多很多，尤其是表示也纳入了就业范围。反观有一批Android开发在如此悲观的环境下站稳了跟脚，那就是**Android Framework开发。，Framework开发的热度从未下降。隐私保护，推送通知，声音设置，内存管理，位置服务，自定义系统界面**等，相信这些任务在我们日常开发中都有应用。

IdleHandlerLagTracer的实现逻辑还是很简单的，它通过hook的方法替换了主线程消息队列的IdleHandlers集合，从而拦截到了IdleHandler的添加和移除逻辑，在拦截到添加IdleHandler的操作时，为原来的IdleHandler做一层代理，从来可以在queueIdle方法执行时做超时监听逻辑，超时未执行完成则收集信息上报，从而发现IdleHandler导致的卡顿问题。

……

在当今社会，科技的快速发展推动了各行各业的变革。移动设备作为人们生活、工作、学习的重要工具，其市场份额逐年攀升。Android作为全球最受欢迎的移动操作系统之一，为开发者提供了广阔的发展空间。但是现在Android发展比较尴尬，之前想吃它红利的人群太多，加快了行业内卷的部分，致使现在Android人才市场饱，甚至可以说是溢出，岗位需求量已基本固定了，导致了如今工作难找的局面。在我身边就有不少这样的朋友，因层层原因几个月了都找不到Android 开发的工作。

这几年，社会问题层出不穷，最头疼的就是民生就业问题，大厂裁员，小厂倒闭，每年大批量的应届毕业生也涌入就业市场。近几日，统计局也发布了就业相关数据，，面对此数据，我们能想到的是实际的失业人数肯定会比公布的数据要多很多，尤其是表示也纳入了就业范围。反观有一批Android开发在如此悲观的环境下站稳了跟脚，那就是**Android Framework开发。。隐私保护，推送通知，声音设置，内存管理，位置服务，自定义系统界面**等，相信这些任务在我们日常开发中都有应用。

dumpsys这个指令很有用，除了可“dumpsys meminfo+包名”以抓取内存，还可以“dumpsys package +包名”查看包信息（此前有看到其他同事使用这个指令查看应用是否有system flag来确定是否是因为没有system标识而被冻结导致的ANR），“dumpsys gfxinfo +包名”查看显示渲染信息进而查看卡顿情况。■ meminfo 内存■ gfxinfo 帧率■ display 显示■ power 电源■ battery 电池。

首先，我们要先明白，什么叫「冷启动」。Android官方对启动的定义，可以参考文档：https://developer.android.com/topic/performance/vitals/launch-time，我们可以在Logcat中，通过Displayed的flitter筛出启动时间。例如：那么阿里集团是如何定义Android应用启动的呢？系统初始化应用初始化首屏展示启动完成（可交互）本文讲重点讲述「应用初始化」和「首屏展示」两个阶段的优化。

先看谷歌官方开发者文档的介绍 我们可以利用AIDL定义客户端与服务均认可的编程接口，以便二者使用进程间通信 (IPC) 进行相互通信。在安卓中，编写进程间通信的代码较为繁琐，Android 会使用AIDL 帮我们处理这类问题。我们先从一个典型的AIDL实例入手来探究。我们来定义一个 aidl 接口文件其中用到了User对象，所以上文还定义了该User.aidl，该对象实现Parcelable接口。我们找到。/***//***//***//***//***/可以看到生成了。

我们知道，自定义View的时候有时会重写onDraw方法，但是Android系统是无法检测onDraw里面具体会执行什么操作，从而系统无法为我们做一些优化。这样对编程人员要求就高了，如果View有大量重叠的地方就会造成CPU、GPU资源的浪费，此时我们可以使用canvas.clipRect()来帮助系统识别那些可见的区域。这个方法可以指定一块矩形区域，只有在这个区域内才会被绘制，其他的区域会被忽视。下面我们通过谷歌提供的一个小的Demo进一步说明OverDraw的使用。

典型的生产者-消费者模式。Android跨进程要掌握的是Binder, 而同一进程中最重要的应该就是Handler 消息通信机制了。我这么说，大家不知道是否认同，如果认同，还希望能给一个关注哈。

app卡帧一直是性能优化的一个重要方面，虽然现在手机硬件性能越来越高，明显的卡帧现象越来越少，但是了解卡帧相关的知识还是非常有必要的。本文分两部分从app卡帧的原理出发，讨论屏幕刷新机制，handler消息机制，为什么在主线程执行耗时任务会造成卡帧。另一部分讨论BlockCanary的原理，它是如何检测方法耗时的。大家小时候应该都玩过一个玩具，5毛一本的连环画小书，每一页绘制一幅画，用手指快速翻动会产生一个动画效果。

当初在讲App启动流程的时候，它的整个流程涉及到的类可以汇总成下面这张图：那时着重讲了AMS、PMS、Binder这些知识点，有一个是没有对它进行详细讲解的，那就是常见的Handler，它不仅在这个流程里作用在ApplicationThread和ActivityThread进行通信，它在整个安卓体系中也扮演着重要的角色，所以也是面试过程中经常被问到的知识点，所以接下来将对它的源码进行分析。

装模作样的总结一下。线程池调度 + 进阻塞队列单任务数据过大 + 处理任务过慢线程池调度任务是啥场景？有个Queue，来了任务，先入队有个ThreadPool，空闲了，从Queue取任务。那么，当入队的数据结构占内存太大，且ThreadPool处理速度小于 入队速度呢？就会造成Queue中数据越来越多，直到OOM。扫一扫完美的满足了上面条件入队频率足够高入队对象足够大处理速度足够慢。在这个例子中，做的不足的地方：追求并发未考虑机器性能大对象处理不够谨慎。

在Android系统中，我们知道UI线程负责我们所有视图的布局，渲染工作，UI在更新期间，如果UI线程的执行时间超过16ms，则会产生丢帧的现象，而大量的丢帧就会造成卡顿，影响用户体验。

为什么要写这个记录，都是一个非常简单的场景及使用方式，但是从发现这个问题到思考怎么解决却是一次算法学习的实际应用。我们在开发中，不会经常使用算法，但是像这种问题，我们可以用算法的角度去分析优化，这大概就是算法学习的意义。

App程序中己动态分配的堆内存，由于某种原因，App程序未释放或无法释放，会造成系统（手机）内存的浪费。长生命周期对象持有短生命周期对象强引用，从而导致短生命周期对象无法被回收。我们注意这两个关键词堆内存、强引用。上面的内存相关知识也是自己学习的一种总结，有错误的可以留言指正。内存优化，需要对下面的知识有一定的了解。Java内存分配模型Java的四大引用及其使用场景内存检测工具及常用命令GC Root的定义。

从上面的日志中，我们看到造成ANR的原因是Input dispatching timed out，那么除此之外，还有什么其他的错误。

……

有一份编译好的 Android 源码，现在的 AS 基本能满足，动手跟着步骤走，理解更深刻对 Binder 机制有一定的了解本文基于 API 26，用什么版本的源码并不重要，大体的流程并无本质上的区别从用户手指触摸点击桌面图标到 Activity 启动关键类简介。

这是以上关于我在工作中遇到的性能问题的及处理的一些总结，性能优化设计的方方面面实在是太多太多，本文不可能将全部的性能问题全部总结的清清楚楚，或许还多多少少存在一些纰漏之处，有不对的地方欢迎指出补充。

……

Binder 是基于开源的 OpenBinder 实现的，OpenBinder 是一个开源的系统 IPC 机制,最初是由 Be Inc.开发，接着由 Palm, Inc.公司负责开发，现在 OpenBinder 的作者在 Google 工作，既然作者在 Google 公司，在用户空间采用 Binder 作为 核心的 IPC 机制，再用 Apache-2.0 协议保护，自然而然是没什么问题，减少法 律风险，以及对开发成本也大有裨益的，那么从公司战略角度，Binder 也是不错 的选择。

了解携程ANR前，我们一起了解 binder 线程池的前生今世在android系统中，通过binder进行IPC时，服务端总是会起一些来响应客户端的请求。

我画了一张草图，大概描绘了一个车间内的工作，辅助理解（画的很抽象，不要介意）。那么以上就是以传送带模型的视角讲述的Handler机制的最基本的完整的流程，现在我们已经非常清楚了。接下来我们再以传送带模型的视角来思考一些问题，或者来看看，这些所谓的面试题，会瞬间感觉非常简单、理所当然。这篇文章以传送带模型的视角来分析了Handler机制，然而，Handler机制远比这些要复杂，但这篇文章的作用本来也不是为了能让你看完就掌握Handler机制，而是抛砖引玉。

binder 包括 BinderProxy、BpBinder 等各种 Binder 实体，以及对 binder 驱动操作的 ProcessState、IPCThreadState 封装，再加上 binder 驱动内部的结构体、命令处理，整体贯穿 Java、Native 层，涉及用户态、内核态，往上可以说到 Service、AIDL 等，往下可以说到 mmap、binder 驱动设备，是相当庞大、繁琐的一个机制。内存数据一定是存储在实际的物理内存上，即页必然对应于一个页框，页数据实际是存储在页框上的。

Framework作为Android的框架层，为App提供了很多API调用，但很多机制都是Framework包装好后直接给App用的，如果不懂这些机制的原理，就很难在这基础上进行优化。从做Android的第一天起，你一定听过无数次关于Framework的讨论，也曾在这个版块被面试官吊锤N次。像启动监控、掉帧监控、函数插桩、慢函数检测、ANR监控，都需要比较深入的了解Framework，才能知道怎么去监控、利用什么机制监控、函数插桩插到哪里、反射调用该反射哪个类哪个方法哪个属性……

MVVM 架构模式中，ViewModel 是不会持有宿主的信息，业务逻辑在 ViewModels 层中完成，而不是在 Activities 或 Fragments 中。LiveData 在里面担任数据驱动的作用：以往我们使用 Handler，EventBus，RxjavaBus 进行消息通信，LiveData 也是一个种观察者模式，作用跟 RxJava 类似，是观察数据的类，相比 RxJava，一般配合 Jetpack 组件配合使用。

关于性能优化，可能我们的第一反应是这是高手做的事情，一直以来我也是这样认为的。但在最近一段时间，在公司项目上做了一些框架的性能优化，让我初步掀开了性能优化的面纱，也对他有了进一步的认识。所以这篇文章结合我做的一些优化，做一些相关经验的分享。性能优化一般情况下分为两类：时间优化与空间优化。前者是降低处理器处理时间，后者是降低内存使用量。归根到底都是降低对硬件资源的使用，来提高程序的性能，从而提高程序运行流畅性、降低功耗等。今天也主要从这两个方面来展开聊一聊。

AMS是Android中最核心的服务，主要负责系统中四大组件的启动、切换、调度及应用进程的管理和调度等工作，其职责与操作系统中的进程管理和调度模块相类似，因此它在Android中非常重要。AMS是碰到的第一块难啃的骨头[①]，涉及的知识点较多。为了帮助读者更好地理解AMS，接下来将带小伙伴么按五条不同的线来分析它。第一条线：同其他服务一样，将分析SystemServer中AMS的调用轨迹。第二条线。

前段时间朋友在找 Android 高级开发工作，想进一步提升自己的能力，看了很多招聘信息，都要求熟练掌握 Framwork，了解底层原理等，发现是不是该深入研究底层技术……同时在网上也看到过相关问题，有很多人在关注。

要监控应用界面是否发生卡顿，需要先了解一下Android应用主线程的渲染机制：Android 系统提供一个稳定的帧率输出机制，让软件层和硬件层可以以共同的频率一起工作,使我们可以享受稳定帧率的画面。大部分手机的屏幕都是60Hz的刷新率，系统为了配合屏幕的刷新频率，每过16.6ms就会发出Vsync信号来通知应用进行绘制。如果每个Vsync周期应用都能完成渲染逻辑，那么应用的FPS就是60，给用户的感觉就是非常流畅。在应用层，实现上述机制的关键类就是。