fpsviewer一个能实时显示fps,一段时间的平均帧率，以及帧率范围占比，并能获取卡顿堆栈的可视化工具。侵入性低，通过在异步线程采样获取堆栈，无代码侵入，性能消耗可忽略，对性能监控项的异常数据进行采集和分析，整理输出展示相应的堆栈，从而帮助开发者开发出更高质量的应用。

常见分析、定位卡顿的方案

系统工具

1. TraceView

目前一般是用现在AndroidStudio里的cpu-profile工具或者TraceCompat.beginSection()生成trace日志，
准确性高，这种分析方式只适合定性分析，因为工具很消耗cpu，有很多假jank，非常影响性能，显示耗时和实际耗时偏差很大，平常开发过程中也不易用，不可能实时开着，没法查看fps。
阅读全文

Android的业务开发中。列表需求很很常见也很重要的部分，列表承载的信息多，涉及的的协议多，布局也多，尤其一些复杂的列表，不管是用ListView还是RecyclerView，使用不当会带来很多的性能问题和后期的维护问题，形成一套规范的，高性能的列表开发模式很有必要。

案例分析

用一些案例说明一下吧(只是用一些App里的截图来做类比，并不知其协议类型和实现方式)

类似的列表不容易解决的主要在两个方面：

1. 先不管列表里每个Item的具体UI,首先列表是可通过下拉刷新和广播通知变化，数据应该也只能全量下发，更新频率可能特别高，列表的长度也可能很长比如几百条（一些聊天列表或者在线用户列表可能存在数据量更大的情况），如果过高频率的刷新很容易造成页面卡顿。 阅读全文

目前的问题

Handler的使用在Android日常开发中占用很大的比重，尤其在界面开发中，经常被用来做一些延迟执行的任务。但Handler带来的问题也很多，最常见的比如页面退出未执行的任务没有被移除导致内存泄漏，以及可能的由于界面已不存在而导致的崩溃。如下，如果不及时移除就可能造成上述问题。

1
2
3
4
5
6

mHander.postDelayed(new Runnable() {
    @Override
    public void run() {
       //do something
    }
},1000);

这些问题一般都比较容易想到，也容易解决，常用的方式是缓存一个Runnable变量在使用的类中，然后在页面生命周期结束移除

Dalvik虚拟机如同其他Java虚拟机一样，在运行程序时首先需要将对应的类加载到内存中。而在Java标准的虚拟机中，类加载可以从class文件中读取，也可以是其他形式的二进制流。因此，我们常常利用这一点，在程序运行时手动加载Class，从而达到代码动态加载执行的目的。
只不过Android平台上虚拟机运行的是Dex字节码,一种对class文件优化的产物,传统Class文件是一个Java源码文件会生成一个.class文件，而Android是把所有Class文件进行合并，优化，然后生成一个最终的class.dex,目的是把不同class文件重复的东西只需保留一份,如果我们的Android应用不进行分dex处理,最后一个应用的apk只会有一个dex文件。

项目地址：Router

代理模式的学习与应用介绍了代理模式的原理及简单使用方式，Router就是基于此实现了一个Android间组件、线程间方便通信的库。

项目背景

在Android中的，EventBus是开源最流行的事件总线库，大大简化了应用程序内各组件间、组件与后台线程间的通信。之前的个人项目NBAPlus也是使用EventBus来简化开发，但在使用过程中有一些问题。

关于Activity,Window,View的关系一直有个模糊的印象,看别人的分析一般都这么理解Activity是管理Window,Window用来承载View,View是最终的视图,也有说Window的作用可有可无的,作用并不大的,并不是说这些观点有问题,而是看了这么多后,会更迷惑,管理是怎么管理的,承载是怎么实现的,如果不自己根据源码看一些,这些概念会一直是抽象的,遇到问题还是没法理解，例如：

1 . 在Activity里调用

1
2

WindowManager.LayoutParams wl = new WindowManager.LayoutParams();  
getWindowManager().addView(mView,wl)；

和

1
2

LayoutParams wmParams =...    
addContentView(mView,wmParams); //activity里的方法

这两种方式背后的实现是怎样的,有什么区别?

分析这个过程不是单纯为跟一遍函数调用的流程，而是更好的理解平常用到的一些方法、对象的初始化时间，对象创建的个数，方法的先后顺序，以及每个类，方法背后的作用和目的。主要是一下几个问题：

1. Application是什么时候创建的，每个应用程序有几个Application
2. 应用的资源路径什么时候初始化的
3. 应用中ContextImpl的个数
4. Application.attach(),Activity.attach()的调用时机及作用
5. Instrumentation的重要性及具体作用
6. 点击Launcher启动Activity和应用内部启动Activity的区别

Binder是Android系统进程间通信（IPC）最重要的方式。要想了解Android的系统原理，必须要先对Binder框架有一定的理解。Binder是什么？Binder可以理解为能在进程间进行”通信”的对象,这个通信不是指在不同进程中操作同一个对象，而应理解为一种通信协议。

Binder的引入背景

传统的进程间通信方式有管道，消息队列，共享内存等，其中管道，消息队列采用存储-转发方式，即数据先从发送方缓存区拷贝到内核开辟的缓存区中，然后再从内核缓存区拷贝到接收方缓存区，至少有两次拷贝过程。共享内存虽然无需拷贝，但控制复杂，难以使用。socket作为一款通用接口，其传输效率低，开销大，主要用在跨网络的进程间通信和本机上进程间的低速通信。Binder通过内存映射的方式，使数据只需要在内存进行一次读写过程。

并发的学习与使用系列 第六篇

关于Asnynck有很多的源码解读，但一些解读现在看来已经不在适用了，比如AsyncTask类必须在UI Thread当中加载，AsyncTask的对象必须在UI Thread当中实例化等一些结论都是基于以前版本的代码来解读的，现在看来已经不是这样的了。同时分析了在AsyncTask的使用中存在的以及以及应该注意的问题，基于一些实际存在的问题尤其是并行串行问题，写了一个类似AsyncTask的库AsyncTaskScheduler，处理了上述的一些实际存在的问题。