我想要台时光机

↓双击 Markdown插件，就可以开始编辑啦。APP进程ActivityThread的启动public static void main(String[] args) { ActivityThread thread = new ActivityThread(); thread.attach(false, startSeq); }在attach方法...

Android中的Watchdog在Android中，Watchdog是用来监测关键服务是否发生了死锁，如果发生了死锁就kill进程，重启SystemServerAndroid的Watchdog是在SystemServer中进行初始化的，所以Watchdog是运行在SystemServer进程中Watchdog是运行一个单独的线程中的，每次wait 30s之后就会发起一个监测行为，如果系

单元测试的必要性完整，规范的单元测试有利于提升程序的“自动化”验证降低后期程序的维护成本高覆盖率的单元测试在很大程度上能提前发现一些潜在的bug编写单元测试的过程中可以帮助程序模块化重构，一个耦合性非常高的程序是无法针对他编写完善的单元测试的private void connectImpl(String domain, String ip, int port) {

Hook Context.startActivity和Activity.startActivityContext的startActivity其实具体是由ContextImpl去实现的，首先来看下framework的相关源码ContextImpl：@Override public void startActivity(Intent intent) { warn

BlockCanary原理如何计算主线程的方法执行耗时 计算方法耗时最简单粗暴的就是在方法之前前记录下开始时间，方法执行完后用当前时间剪去方法开始执行的时间就完事了，但是主线程那么多方法总不能每一个方法都这个干吧？那肯定崩！有没有一个统一的地方来实现这个功能？当然有了，不然这篇博客到这里就戛然而止了……public static void loop() {

简书博客地址：简书博客地址

微信的智能心跳策略微信智能心跳策略1. 为什么TCP连接需要心跳？ 因为运营商有一个NAT超时：因为IP v4的IP量有限，运营商分配给手机终端的IP是运营商内网的IP，手机要连接Internet，就需要通过运营商的网关做一个网络地址转换(Network Address Translation，NAT)。简单的说运营商的网关需要维护一个外网IP、端口到内网IP、端口的对应关系，以确保内网的手机可

混淆误区在android studio中AndroidMainifest.xml文件，对于主APP工程和lib工程来说，在生成apk的时候是会自动合并的，这给我造成一个误区让我以为主工程里面配置的混淆和lib工程配置的混淆在生成apk的时候也会自动合并，经过测试发现，混淆配置是不会合并的如果APP主工程中开启了混淆而lib工程的混淆配置没有开启，那么编译出来的apk，对于lib工程来说，包名，类

耗电检测环境搭建（Battery Historian2.0） 这里啰嗦一句，Battery Historian1.0已经过时了，而且1.0的分析表格远远没有2.0来的详细，所以推荐用2.0的环境来检测，但是2.0的环境搭建比1.0要稍微复杂一点go语言环境安装go语言环境变量配置，这个跟java环境变量配置是一样的GOROOT是配置你go语言的安装目录 GOPATH是配置go工程目录 最后

could not parse aggregated battery stats之前有一篇文章Android5.0系统耗电分析中提到用Battery Historian来分析耗电问题，但是在最近几次用Battery Historian2.0分析的时候点击Submit按钮analyse成功后，进入界面的报错“Note: Could not parse aggregated battery stats

话不多直接进入主题 所谓重连就是Android客户端额度TCP连接断开之后自动进行连接，但是有时候会遇到一直重连不上的情况，那么就不能一直频繁的进行重连操作，毕竟在手机休眠的时候重连操作可能会有网络数据通信，手机会被唤醒，等重连操作完成后手机才会再进入休眠，所以频繁的重连会导致手机频繁的唤醒，耗电量妥妥的就上来了。重连策略重连分两种，一种是连接断开重连，另一种是连接成功后秒断重连，连接成功秒

MotionEvent.ACTION_DOWN传递在Android中，触碰控件的时候回产生一个ACTION_DOWN事件并逐层向下传递，首先ACTION_DOWN回先从Activity的dispatchTouchEvent方法开始向下传递：public boolean dispatchTouchEvent(MotionEvent ev) { if (ev.getActi

Android的Activity界面从何处开始绘制Activity启动之后，灰溜溜的会去跑onCreate，onStart，onResume等生命周期方法，那么从framework里面，让我们看看Activity在onResume之前都在干些啥？ 在ActivityThread中的handleResumeActivity方法中先调用了performResumeActivity方法，而per

线程池（ThreadPoolExecutor）的几个状态RUNNING：Accept new tasks and process queued tasks（可接受新的任务并且执行已经加入队列的任务）SHUTDOWN：Don’t accept new tasks, but process queued tasks（不再接受新的任务，但是可以继续把已经加入队列的任务执行完成）STOP：Don...

IM SDK开发数据协议数据编解码与数据加解密TLV编解码的JAVA实现与优化数据加解密SDK架构设计公共部分TLV编解码数据存储与共享跨进程通信管理配置管理自定义异常大数据埋点统计APP进程协议请求管理协议响应管理消息分发管理第三方推送集成PUSH进程push进程的状态管理TCP连接管理TCP连接...

Hash（哈希）哈希即散列，散列表是为了解决高速存取而设计的，是一种典型的通过空间去换取时间的做法；为啥叫散列？其实我们可以把这个数据接口理解为一个线性的表，但是这个表当中的元素并不是紧密排列的，而是分散的，元素与元素之间可能存在间隙，所以这里就会造成空间上的浪费；散列表是依据Key-Value键值对去实现存取的，把Key通过一个映射函数映射到表中的一个位置，而这个映射函数就叫做散列函数对...

布局优化窗体的布局结构：窗体布局层次：窗体绘制：上图中是表明DecorView的加载耗时：31.89ms检测方法耗时手表性能太低，无法使用traceview去跟踪方法耗时，会造成ANRaop的方式还要再集成或者自己开发来获取方法耗时，开发耗时周期太长简单粗暴的方法，直接再程序中加入日志打印计算在启动过程中的方法执行耗时可通过systemtrace来抓去t...

自定义换行我们通常在自定义控件的时候会遇到不想用系统默认的文字换行，而需要根据自己的需求来实现文字的换行，原理如下：使用Paint的measureText方法来测量文字的长度假设设定单行的最大长度为maxWidth，那么就通过measureText来测量每一个字的长度，然后不断的累加再去对比maxWidth，如果比maxWidth大，那就追加一个换行符号，然后再把累加长度归零，继续开始...

需求当TextView限制最大行数的时候，文本内容超过最大行数可自动实现文本内容向上滚动随着TextView的文本内容的改变，可自动计算换行并实时的向上滚动文字向上滚动后可向下滚动回到正确的水平位置自定义方法自定义一个View，继承自View，定重写里面的onDraw方法文字的滚动是用Canvas对象的drawText方法去实现的public void drawT...

使用contentprovider发现的问题在我们的android设备上有两个app，app1提供了一个contentprovider出去，也就是contentprovider的server端，app2使用了app1提供的contentprovider，也就是contentprovider的client端，当app1的进程被杀死的时候会发现app2的进程也被杀死了，一开始遇到这个问题的是感觉...

说明：本篇博客属于读书笔记，大量参考《深入理解Java虚拟机》这本书JVM的内存程序计数器程序计数器是线程私有的，每一个线程都有自己的一个程序计数器，并且互不干扰，程序计数器相当于当前代码所执行指令的指针，控制了当前线程的执行流程，当Java程序在执行Java方法的时候，程序计数器记录的是当前执行代码的指令地址，当Java程序正在执行Native方法，程序计数器则为空（Und

在启动的Activity的onCreate里面做了太多的事情导致初始化activity太慢onCreate做到精简，如果实在不行那就开异步任务，这样onCreate就不会因为执行太多任务都卡住，可以顺利的回调下面的生命周期，因为activity是在onResume的时候才是可视的在start下一个activity的下一句代码马上就finish当前的activity其实一般情况下，这种是不会造成

使用android shell命令查看内存使用情况使用adb shell dumpsys meminfo pkgname或者直接使用AndroidStudio里面的memory usage功能然后就会出现如下信息：Applications Memory Usage (kB):Uptime: 14237237 Realtime: 23790474** MEMINFO in pid 8071 [com

可能造成耗电的一些原因网络请求耗电，而且手机数据网络进行http请求比无线网进行http请求更加耗电，因为数据网络调用到一些底层的硬件模块，就如GPS一样，当手机打开GPS功能后，也是启动了一些硬件模块就会明显增加耗电高频的刷新UI界面，刷新UI界面其实就是进行layout的绘制，如果一个Activity的布局嵌套太多层，那么每一层layout都会刷新一次，例如动画等等这些都会造成耗电数据库，

AsyncTask默认一次只能执行一个任务AsyncTask默认是使用线程池实现异步操作的，如果你调用的是execute()方法，那么：public final AsyncTask<Params, Progress, Result> execute(Params... params) { return executeOnExecutor(sDefaultExecutor, param

首先，明确一点，一个线程只能创建一个Looper，只有一个MessageQueue，但是可以有多个Handler来发消息LooperLooper里面包装了一个消息队列MessageQueue，Looper.prepare()，方法是用来初始化该线程的Looper信息，例如new一个Looper出来，然后保存到ThreadLocal，这样可以确保这个线程只有一个Looper，因为ThreadLocal

之前做过一个项目，手机机型比较老，导致了android广播的接收问题 当我使用动态注册的广播，app程序能很快收到动态的广播，当我使用静态广播的时候，手机基本上很难收到广播，具体情况如下：1.手机能正常收到静态广播，但是这种正常情况几率较小；2.手机要等好久才能收到静态广播，30多秒，有时候甚至1到2分钟才收到，要不是我死死盯着程序测试，还真以为收不到静态广播了呢收不到静态广播的原因分析：静态广

android中判断是否联网的那个方法在某些情况下是不可靠的，其实最可靠的就是ping当前的网络例如ping百度看下能不能ping通，能就代表网络正常，不能就表示网络不正常，以下就是ping的代码实现：public static boolean ping(String host, int pingCount, StringBuffer stringBuffer) { String l

直接使用android sdk里面的Dialog以及子类AlertDialog,这种弹窗要求依赖Activity环境，如果传入的context不是activity就会报错，所以这种弹窗是和界面强相关的使用系统弹窗：TYPE_SYSTEM_ALERT，而且要加权限：android.permission.SYSTEM_ALERT_WINDOWAlertDialog.Builder dialog =

1. 前言，以前在开发j2ee的时候有那种比较完善的开发框架，例如spring mvc，所以项目架构非常清晰，基本做到了数据展示与数据获取完全分离，严格的遵守了MVC的框架模式，项目可维护性高，新进开发人员理解上手容易；后来转到android端开发，我发现android端并没有非常明显的MVC架构，因为Activity中数据展示和数据获取都可以写在一起的，也就是说Activity扮演了View和Co

某些手机(TCL和华硕品牌的手机)自定义静态广播无法正常接收） 一般情况下我们都习惯这么写广播 public class MyTestReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { String a

项目中用到了一个比较坑爹的问题，就是App的耗电问题，发现自己开发的时候没有注意这个问题，一发布给用户就暴露了这个我平常不注意的问题挺蛋疼，平常开发我都觉得耗电是很正常的，再耗电也在可接受范围内，但是这次我错了，App的耗电我粗略自己测了下，不断的操作十多分钟耗电量竟然高达百分之十，这个就算是我自己也无法接收！耗电原因具体有一下几个主要方面 http请求(GZIP压缩) json数据

我一直苦恼为什么IntentService为什么同一时刻只能执行一个任务，看源码也只是HandlerThread与Handler相配合sendMessage而已，后来经过测试才发现原来一个线程中的Looper与MessageQueue取Message是像队列一样去取的，取出来的Message中的任务执行完了之后再取下一个Message，后来我测试在onHandleIntent当中开启线程来执行，然后

Android性能优化主要分几个方面图片加载数据库操作Http请求UI优化代码好习惯图片加载app在加载较大Bitmap的时候经常会包OOM异常，反复改变一个控件的图片或者加载太多图片到内存的时候会报OOM；原因如下，android给每个app开辟的运行内存是固定的，有的是16MB，有的更多，具体根据手机而定，而当大图片被加载到内存之后可能导致内存超过了android系统给定的内存，这时

Evenbus是基于java反射机制来实现事件分发的EventBus.getDefault().register(this);这里的this一般情况下是Activity类，但其实它只要是一个Object就可以了，Eventbus支持任何对象的事件分发public void register(Object subscriber) { register(subscriber, fal

最近项目中遇到一个问题：APP运行2个进程，然后发现APP的Application的onCreate被调用了两次，导致Application初始化了两次，造成app启动的时候非常缓慢而且已启动占用的内存很大，因为两个进程都初始化了相同的资源，而且两个进程是相互独立的，所以各自初始化的资源都是独立的，也就是初始化了两份一样的资源； 原因：APP运行多进程导致Application被初始话多次 解决

IM Android端SDK开发过程中遇到的问题华为手机我们曾经采用Native守护进程保活的方案做到了在android5.0系统以下的手机可以做到push进程被杀死后能够重启，后来在华为一些机型手机上出现严重的耗电问题，同时也发现在这些机型上Native层的守护进程无效，push进程被杀死后无法正常拉起，具体原因我们没有再分析，只是直接把Native层的守护进程去掉了，之所以直接去掉是考虑到不同

静态的系统广播静态的系统广播，例如：开机广播，用户开屏广播，USB插入和拔出广播等这类广播在app运行期间可以用静态注册的广播正常接收，但是在app被杀死后就无法收到了，android系统做了屏蔽，把被杀死的app的系统静态广播都过滤了，所以想让app被杀死后仍然通过静态注册的广播接收系统广播是做不到的自定义广播我们一般发广播都是局限在app内部，所以通常都是这么发的：Intent intent =

Activity内部类泄漏Activity如果存在内部类，无论是匿名内部类，或者是声明的内部类，都有可能造成Activity内存泄漏，因为内部类默认是直接持有这个activity的引用，如果内部类的生命周期比activity的生命周期要长，那么在activity销毁的时候内部类仍然存在并且持有activity的引用，那么activity自然无法被gc，造成内存泄漏Activity内部Handle

什么是IM IM就是即时通讯(instant messenger)的简称，市面上比较流行的即时通讯APP有微信，易信，阿里旺旺，陌陌等，在Android平台上，即时通讯主要都是通过TCP来实现的TCP的鲜明特点TCP连接是可靠连接，保证消息必达TCP链路是双工通道，所谓双工就是链路两端都可以同时进行数据发送与接收并不受影响，也就是说TCP链路在写数据的同时可以进行读数据TCP数据传输都是