Android性能优化专题

今天这篇文章，我们来讲讲`BroadcastReceiver` 和 `Service Timeout` ANR分别是怎样产生的。

`ContentProvider`的启动，是在`Application的onCreate`方法之前的，所以`ContentProvider`的初始化时间会影响整个App的启动速度。

ContentProvider会影响App的启动速度，本篇文章讲讲Google Jetpack中Startup的优化思路。

这是Android Input系列的第三篇文章，今天主要讲讲App端在收到事件之后，是如何消费这些事件的。

发生ANR后，系统会为我们提供一些信息，便于我们分析问题，如生成trace文件，在log中打印CPU信息等。这篇文章，我们来看看ANR发生之后，系统会提供给我们哪些信息，以及这些信息是如何采集和输出的

在App开发过程中，我们经常需要自动重启的功能。比如： 登录或登出的时候，为了清除缓存的一些变量，比较简单的方法就是重新启动app。 crash的时候，可以捕获到异常，直接自动重启应用。

App的崩溃率，是性能的一个重要的衡量指标。做过客户端开发的朋友，肯定与线上各种各样的崩溃问题打过交道。我们有没有什么办法能提高程序的稳定性、降低崩溃率，甚至做到永不崩溃呢？对于Java崩溃，答案是肯

epoll机制 一句话解释：epoll机制可以监听特定的fd，当fd收到内容时，发送事件回调。相比select和poll机制，效率更高。

日常开发中，使用过SharedPreference的同学，肯定在监控平台上看到过和SharedPreference相关的ANR，而且量应该不小。如果使用比较多或者经常用sp存一些大数据，如json等，

前一篇文章[ANR]为什么SharedPreference会引起ANR，我们知道， SharedPreference的apply方法虽然是异步写入文件的，但是会在Activity和Service生命周

最近在做ANR优化，发现线上非常多的ANR（一半以上）原因都是 Input dispatching timed out。那这些ANR是怎样产生的呢？这篇文章我们就从源码角度剖析一下。

大家都知道，当发生ANR后，App会弹窗提示”应用失去响应，是否重启“，然后系统会dump一份trace文件，存在data/anr目录下。 这个时候，系统肯定是知道ANR发生了，所以像Console和

`system_server`进程的`InputDispatcher`线程，需要与App端的UI线程进行通信，需要先建立socket连接。这篇文章，我们讲讲socket连接的建立过程。

我们都如果在Android应用中发生了未捕获的崩溃问题，不管是在主线程还是在子线程，应用都会直接退出。 但是Java程序，子线程抛出的异常，不会引起程序的退出。 那你们知道JVM是如何处理应用未捕获崩