Be Focus

在我们的漫漫解bug的路上，有一类bug是比较头疼的：崩溃在SDK实现代码中，例如下面这个：

java.lang.NullPointerException: java.lang.NullPointerException at android.view.ViewGroup.dispatchDraw(ViewGroup.java:2803) at android.view.View.getDisplayList(View.java:12709) at android.view.View.getDisplayList(View.java:12755) ... at android.widget.FrameLayout.draw(FrameLayout.java:467) at com.android.internal.policy.impl.PhoneWindow$DecorView.draw(PhoneWindow.java:2211) at android.view.View.getDisplayList(View.java:12711) at android.view.View.getDisplayList(View.java:12755) at android.view.HardwareRenderer$GlRenderer.draw(HardwareRenderer.java:1205) at android.view.ViewRootImpl.draw(ViewRootImpl.java:2193) at android.view.ViewRootImpl.performDraw(ViewRootImpl.java:2065) at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:1874) at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1009) at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:4418) at android.view.Choreographer$CallbackRecord.run(Choreographer.java:749) at android.view.Choreographer.doCallbacks(Choreographer.java:562) at android.view.Choreographer.doFrame(Choreographer.java:532) at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:735) at android.os.Handler.handleCallback(Handler.java:725) at android.os.Handler.dispatchMessage(Handler.java:92) at android.os.Looper.loop(Looper.java:137) at android.app.ActivityThread.main(ActivityThread.java:5063) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:511) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:817) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:584)

这类bug往往是开发中的使用API不当，只是崩溃在SDK实现中。

头疼的是，虽然崩溃栈上有行数，但是由于Android版本和各种手机对源码都有修改，这个行数不是准确的，所以，从这个地方只能定位到函数。例如上例，只能定位到崩溃在ViewGroup#dispatchDraw这个方法中，而具体是由于哪个变量为空导致的空指针，则无能为力了。

如果是在开发中遇到这样的崩溃，能够复现，最简单的办法就是用Nexus系列手机，SDK版本能对上就能准确定位到问题出现的代码行数。这里不再详述。#Android开发一定要有亲儿子

如果实在后台发现这样的崩溃数据，如果你手上有产生这个崩溃的设备的话，那么下面的方法也许可以帮助定位问题。

找到SDK实现，反编译

这一步需要相应的设备，因为设备上是有SDK实现，有可能是jar包，有可能是odex，通常在 /system/framework里，在上述例子中，/system/framework/framework.jar就是要找的jar包。 根据找到的是jar包还是odex，选择不同的工具反编译。 反编译出来的smali代码中，会保留如下的行数信息：

.line 134 new-instance v0, Landroid/graphics/PointF; invoke-direct {v0}, Landroid/graphics/PointF;-><init>()V iput-object v0, p0, Landroid/view/ViewGroup;->mLocalPoint:Landroid/graphics/PointF; .line 147 const/4 v0, -0x1 iput v0, p0, Landroid/view/ViewGroup;->mLastTouchDownIndex:I .line 178 iput v1, p0, Landroid/view/ViewGroup;->mLayoutMode:I

阅读smali代码，对比源码

找到smali代码中的行数，阅读附近的源码，对比一份版本相近的SDK源码，就算是定制的rom，源码也不会修改太多。根据这个，能找到具体崩溃在什么地方。

通过上述方法，找到崩溃对应的代码：

for (int i = 0; i < childrenCount; i++) { int childIndex = customOrder ? getChildDrawingOrder(childrenCount, i) : i; final View child = (preorderedList == null) ? children[childIndex] : preorderedList.get(childIndex); if ((child.mViewFlags & VISIBILITY_MASK) == VISIBLE || child.getAnimation() != null) { more |= drawChild(canvas, child, drawingTime); } }

这个时候再定位问题就方便很多了。

前提

简单来说，用上述方法需要两个前提条件：

有崩溃发生的设备

红外遥控工作原理

1. 红外遥控为什么能发送和接收指令？

红外遥控是一个硬件设备，能够发出人不可视的红外波长的光，并且能以一定频率发光，从而能达到传输数据的目的。如下图：

相应的，红外接收器就是能够接收这些光，并且转化为电信号的硬件设备。

2. 怎么传输数据？

接收器能够接收到发送器发出的光，所以简单来说，接收器接收到的信号就是“亮了”。在这基础上，如果约定一些发送的模式，例如"亮0.1ms，灭0.2ms，亮0.1ms" 代表 "上一个频道""，就能完成数据的传输了。

而这些发送的模式，就是红外的协议。现在常用的有RC5，RC6，SIRC，NEC等协议。

下面来介绍一下NEC协议，我们现在常见的好几款盒子都是采用这个协议的，例如天猫魔盒、乐视盒子等。

NEC协议常用在频率为38kHz的红外设备上（也就是说亮和灭的最小时间是26.3µs）。协议很简单：

亮562.5µs，再灭562.5µs，一共1.125ms表示bit“0”

亮562.5µs，再灭1.6875ms，一共2.25ms表示bit"1"

当一个按键被按下的时候：

先亮9ms，再灭4.5ms，表示开始

16 bit的地址码，主要用于区分设备

8 bit控制码

8 bit控制码取反，用于校验

亮562.5µs，表示单次传输结束

所以NEC协议一共能传输32bit数据，即十六进制下8位数字(0xaaaaaaaa).

这个在我们目前的协议中有所体现，在工程IRControlUtil.java中：

public static int HERTZ_DEFAULT = 37990; // 38kHz ... ... case R.id.device_tmall: home = "9017, 4491, 544, 577, 544, 577, 544, 578, 543, 577, 544, 577, 544, 577, 544, 577, 544, 577, 544, 1697, 544, 1697, 544, 1696, 543, 1696, 544, 1696, 543, 577, 544, 577, 544, 1696, 543, 1696, 544, 1697, 544, 1696, 543, 577, 544, 577, 544, 577, 544, 1697, 543, 577, 544, 577, 543, 577, 544, 578, 543, 1697, 543, 1697, 544, 1697, 544, 577, 544, 1697, 544, 42396, 9016, 2254, 543, 96200"; //一次协议传输，9ms，4.5ms开头

具体NEC协议见这里。 SIRC协议见这里。

3. 所以，要模拟红外需要怎么做?

从现在我们研究的程序来看，其实模拟红外是忽略红外协议这一层的，相当于直接用一个模式来代表某个动作，这是一种方法。

还有一种方法是知道红外用的是哪个协议，传输的是什么数据。例如用NEC协议传输0x8006ff00.

Android系统接收控制原理

硬件层红外基本了解了，下面来看下Android系统是怎么接收红外键值的。

1. Android architecture

众所周知，Android是基于linux系统，其基本结构可以看下这个图：

图片来源于 http://www.tutorialspoint.com/android/android_architecture.htm

2. Input System

Android输入系统原理基本就是下层一个linux的输入系统，然后Android由一个进程轮询（poll）/dev/input/*，从而得到Android输入。

对于按键，是有多套键值的。linux有一套(input.h)，Android有一套(KeyEvent.java)，所以转译过程如下：

硬件 驱动 EventHub 模拟信号 ----> 数字信号 -----> linux keycode ---------> Android keycode

本机读取红外键值可行性

从上面可以知道，如果要从本机读取红外键值，需要知道：

使用的红外协议

红外数据到linux keycode映射

linux keycode到Android keycode映射

其中，3是通过/system/usr/keylayout下的配置文件是可以知道的。 而1和2，完全取决于红外模块的驱动是怎么实现的，而Android系统中，驱动代码是闭源的。 从现在可以知道的信息来看：

armlogic芯片红外驱动会读取/etc/remote.conf配置，所以在该平台上可以获取到红外键值。详细方法见此帖子。

海思芯片红外驱动键值映射是写死在代码中的，根据这篇blog推测。

全志系列，红外驱动键值也是写死在代码中，并且会单独编译内核模块以让其他厂家修改。虽然其整个解决方案都开源了，keyboard驱动部分见这里。但是由于其他厂家使用的都是自己编译的红外驱动内核模块(sunxi-ir.ko)，故相当于也是闭源的，没有办法，从这篇帖子最后部分可以得到证实：天敏D6四核强制线刷教程

同时，观察现有破解的红外键值，还有相当一部分不是使用的NEC协议。所以现在的遥控码库基本都是记录raw data的形式。

结论

综上，结论就是：

由于没有办法了解驱动的代码，没有通用的方法获取红外键值的方法

在定位问题，和服务端配合等时候，我们常常需要定位这个功能是在哪一版上的。

使用git，这个问题很好解决。

找到对应代码，git blame，或者用Android Studio里的右键->annotation方法，找到现在这份代码对应的commit的id。

根据commit的id，找出对应包含这个commit id的分支:

git branch -a --contains <commit>

这样就能快速定位出代码是哪个版本发布的。

SourceTree

配合SourceTree，整个流程还能更简单。SourceTree提供右键自定义动作。 写一个简单的script：

#!/bin/bash /usr/bin/git branch -a --contains $1 |grep release

新建一个Custom Action：

使用的时候，右键菜单里会有自定义动作：

前言

客户端编程中，很大一部分工作都是GUI(Graphic User Interface)编程。GUI编程发展了这么多年，才有了现在大家接触到的这个样子。下面我尝试以安卓为模板，按照自底向上（从古至今）的顺序，来聊一聊现在的GUI框架。

首先要聊的，肯定是绘制，下面主要讲讲2D的绘制。

Canvas

其实GUI编程，最终的目的是控制屏幕上每个像素的状态。简单来说，就是要生成一张位图，用于给屏幕显示。 若要在屏幕上显示一个从（0，0）到（x，y）的方形，需要

遍历设置(0, 0)到(x,0)的像素值 遍历设置(x, 0)到(x,y)的像素值 遍历设置(x, y)到(0,y)的像素值 遍历设置(0, y)到(0,0)的像素值

如果需要显示一个圆形，那就更加复杂了。如果在屏幕上需要显示若干个图形，是不是感觉有点转不过来了？

不知道远古时期的程序员们是不是需要这么痛苦写代码，总之，封装一个专门画基本形状的库，就是理所应当的了。

Windows上的GDI/GDI+，Android上的skia，都是这样的库。

在Android中，2D图形库的接口，被命名为Canvas（画布）。

Canvas这个类持有一个Bitmap对象，主要提供的方法:drawXXX,clipXXX,drawTextXXX，可以在内存中的Bitmap上绘制基本形状，并且提供矩阵变换操作。（在windows中，虽然没有Canvas这个类，但是使用对HDC操作的系列函数可以很简单封装出一个Canvas类，基本是一一对应的）

有了Canvas接口，一次画多少形状都不是问题了。

但是，在这个基础上，你写一个输入框试试？你会发现，选中、插入/覆盖模式切换、换行、退格、双击、拖拽等逻辑异常复杂。怎么办？继续封装。

Control

随着windows系为代表的UI风格普及，大家发现，其实用的最多的，也就那么几样：按钮，输入框，图标等等。那就把交互也封进去吧，于是，控件诞生了。

按钮的几态，不用写代码一个一个画了，用现成的，做点小修改，基本能解决问题。举个例子，Button：接受点击事件，绘制按下态，全部由Button这个控件的实现来完成。

当年的Windows上面GUI就封装到了这一层，有基本的控件可以使用。

但是，一个程序，往往由很多控件构成，控件之间是不知道如何协作的。所以，如果有一个点击事件发生，那么代码就得这么写：

if (点击在Button上) 处理逻辑 else if (点击在Icon上) 处理逻辑

输入事件还不止点击这一种，还有键盘输入，还有焦点处理等等。

还有，每个控件都有自己的绘制代码，如果界面上有很多控件，如何协调他们之间的绘制？

还不够，还得继续改进。

View Hierarchy

解决办法：树形结构View。

View就是一个最基本的控件，封装了通用的绘制代码，同时还能与其他View协作，完成下面这些任务：

整体绘制

View之间有了父子关系，那么父View绘制的时候，必须让子View也绘制，所以把整个界面绘制出来就很简单了：请求根View绘制，绘制请求就会沿着这个树传递到每个View。

同时子View的座标系是相对于父View的，这样让组合控件成为了可能，试想一下：我需要一个新的控件 - 两个按钮并排放在一起。如果View的座标系是全局的，那么这样控件是不能通过简单组合来完成的；反之，子View的座标系是相对于父View的，那么我只需要将两个Button放在同一个父View中，并且第一个的座标为(0, 1/2),第二个(1/2, 1)就能满足需求。

事件传递与分发

事件分发与绘制类似，由于存在父子关系，那么由父View分发至子View，只需要在View实现中实现这样的函数：

click(x,y) { 对于每一个childView： if (x,y 在childView内) childView.click(relX, relY) onClick() }

例如：

点击事件会从RelativeLayout->LinearLayout->Button，最终Button的onClick会被调用。

所以上文这样的代码：

if (点击在Button上) 处理逻辑 else if (点击在Icon上) 处理逻辑

就可以避免了。

还有一些其他的特性，例如事件冒泡、焦点处理等，这里不详细描述了，总之，用树形结构来表示View之间的关系，能解决很多问题。

Layout

伴随着树形View结构的，还有一套（自动）布局系统。布局系统能够：

解决窗口缩放问题，即界面能适应不同大小的空间。

解决不同语言、平台中最基本的差异，例如字体大小、不同语言文字大小等。

最重要的，能将开发者从子View位置计算中解放出来。

布局系统基本的工作原理是：

子View向父View提出空间需求

父View决定子View的大小和位置，并且将相应值传给子View

一搬分成两个阶段：Measure和Layout。

在Measure阶段，父View会和子View“协商”好子View的大小。类似于：

父：你需要多大？ 子：400像素 父：我这最多300像素，你需要多大？ 子：300像素 父：deal！

以Android为例，父View的measure方法

OOM

OOM(Out Of Memory)是Android应用开发中相信每个人都遇到过的问题，而OOM在crash log中的stack trace一般没有实际意义，因为是在分配内存的时候才会抛出OOM异常，而这个时候的stack trace和OOM的原因没有任何关系。所以OOM问题的定位和分析就需要多花费一些功夫。

下面，我就结合一个例子，来讲讲怎么定位OOM问题。

问题

在程序员们把代码写完，基本流程测试无误，准备要发布的时候，云测的结果却是：一大波OOM异常。没办法，只好重新打开电脑定位问题。 由于不是我一个人写的代码，所以直接看代码定位问题有点困难，这个时候就要上工具了。

0 定性问题

0.1 定位问题，先定性

这是一个内存泄漏导致的OOM，还是应用本身设计不当，导致一次需要加载的内存过多，导致的OOM？

定位问题的方法很简单，看内存是不是一直在增长，如果在使用的过程中内存一直在增长，则很有可能是内存泄漏导致的。

0.2 推荐使用的工具

Android Studio自带的Memory Monitor，很简单的一个小工具，能够把应用内存实时展现出来，简单到我认为不需要多说了。如下图：

在摆弄了几分钟之后，我发现了几个问题：

app刚刚启动的时候，内存占用就很大，因为用了很多的贴图（设计不当）

app在进入播放界面并且推出之后，即使什么操作都不做，内存一直在缓慢增长（内存泄漏）

app在我退出再进的时候，内存占用几乎翻番（内存泄漏）

其中，问题2很快就能猜出来，播放结束后MediaPlayer没有被释放，之后验证了下，解决。

1 设计不当？优化！

这个问题就很泛了，比如，纯色的背景就不用图片来实现，不用超过需要像素值的图片，不加载显示范围之外的图片，等等。

最终找到了几张图片，只需要1280x720，给的图是1920x1080。同时简单实现了图片的LazyLoading。问题1基本凑合搞定。

2 内存泄漏？

如果在使用过程中，内存曲线一直是上涨趋势，这就很有可能存在内存泄漏了。

2.1 查看堆的信息

Android SDK的工具集中就提供这样一个工具：Device Monitor。使用方法如下：

打开Android Device Monitor

选择你要调试的进程

点击Update Heap按钮

基本情况如下图：

可以看到基本的堆情况，以及堆内对象的概览。

2.2 查看Activity泄漏

常见的内存泄漏很多都是由于Activity对象不能被释放导致的，用下面的adb命令可以快速的定位到这个问题：

adb shell dumpsys meminfo <package_name>

得到结果如下：

** MEMINFO in pid 9953 [com.google.android.gm] ** Pss Pss Shared Private Shared Private Heap Heap Heap Total Clean Dirty Dirty Clean Clean Size Alloc Free ------ ------ ------ ------ ------ ------ ------ ------ ------ Native Heap 0 0 0 0 0 0 7800 7637(6) 126 Dalvik Heap 5110(3) 0 4136 4988(3) 0 0 9168 8958(6) 210 Dalvik Other 2850 0 2684 2772 0 0 Stack 36 0 8 36 0 0 Cursor 136 0 0 136 0 0 Ashmem 12 0 28 0 0 0 Other dev 380 0 24 376 0 4 .so mmap 5443(5) 1996 2584 2664(5) 5788 1996(5) .apk mmap 235 32 0 0 1252 32 .ttf mmap 36 12 0 0 88 12 .dex mmap 3019(5) 2148 0 0 8936 2148(5) Other mmap 107 0 8 8 324 68 Unknown 6994(4) 0 252 6992(4) 0 0 TOTAL 24358(1) 4188 9724 17972(2)16388 4260(2)16968 16595 336 Objects Views: 426 ViewRootImpl: 3(8) AppContexts: 6(7) Activities: 2(7) Assets: 2 AssetManagers: 2 Local Binders: 64 Proxy Binders: 34 Death Recipients: 0 OpenSSL Sockets: 1 SQL MEMORY_USED: 1739 PAGECACHE_OVERFLOW: 1164 MALLOC_SIZE: 62

其中的ViewRootImpl、Activities、AppContexts数量很值得关注。 关于其他的输出含义，见developer docs

2.3 取heap dump

在基本确定内存有泄漏之后，就需要定位具体是哪个对象泄漏，好定位相关代码，这个时候就可以对heap dump进行分析。 heap dump就是一个内存heap的快照，可以用来很具体的分析内存里到底有什么。

首先，我们用Device Manager需要导出一个heap dump，如图所示

然后转化成java dump，用 Eclipse Memory Analyzer Tool (MAT) 来分析。

用platform-tools里的hprof-conv来转化：

hprof-conv heap-original.hprof heap-converted.hprof

转化完成之后，我们就可以用MAT来打开分析。

3 Eclipse Memory Analyzer Tool (MAT)

当我们用MAT打开dump时，看到的基本界面如下:

这里有几个概念需要了解：

Shallow Heap & Retained Heap

Shallow Heap的大小就是对象所占的内存空间，一般一个Object持有一个引用会需要32或者64bit的空间（取决于JVM）。 由于A对象持有B对象引用会导致B对象在GC中不会被销毁，所以由于被对象直接或者间接持有引用而不会被释放的对象的占用的内存总和，就是Retained Heap。 简单来说，Shallow heap就是对象占用的空间，Retained Heap就是假如对象被释放，连带能够释放出来的空间。

Dominator Tree

定义在这里。简单来说，Dominator Tree可以很好地观察Retained Heap大小。

通常，在dump中查看Histogram和dominator_tree就可以看出一些端倪，例如这个例子中，histogram图中，占用内存最多的是byte[]对象，通过右键 -> List object菜单，可以看到

基本上都是Bitmap对象，而且Bitmap有重复数据：

到这一步，可以继续追查是谁导致两份相同的数据不能得到释放，通过 右键 -> Path to CG root功能，可以追查到最终是被哪个对象持有导致不能被释放，结果如下：

到这里，问题基本就明白了： DBHelper是一个单例静态对象，这个对象会持有一个Context对象，在代码中被当成Context传入DBHelper的是一个Activity对象，所以这个Activity不会被释放；当这个Activity被销毁重建时，新的Activity会重新加载ContentView,而老的Activity所持有的整个View的树全部不会被释放，同时View持有的图片也不会被释放，导致内存不够。

至此，整个问题基本已经找到，同时告诉我们，用单例最好不要持有Context对象，如果需求需要，查看下这个设计是否合理，以及使用的时候谨慎。

一个常用的MAT技巧

在分析内存占用的时候，通常可以看到各种占用最多的时Bitmap对象，这个时候，如果能直接显示这个Bitmap内容，那么找起来会方便很多。下面是一个查看的方法：

stackoverflow上回答见这里

结尾

为什么会写这篇blog

有人在StackOverflow上提了这个问题，碰巧我这个雷锋路过，就顺手回答了一下，还特意写了一点代码，不过，答案也没有被采纳，哭。那就写写吧。

效果

ProgressBar能达到这样的效果：

而要想达到下面这样的效果，那就要额外写点代码了：

ProgressBar原理

ProgressBar是直接从View继承出来的，所以如果我们要看进度是如何绘制的，首先应该看onDraw()方法，但是，onDraw()方法中并没有任何画多少进度的代码，再仔细一找整个类中也没有记录进度的成员，这是就应该去setProgress()看一下设置进度最终设置到了哪。 下面是setProgress()最终调用的函数：doRefreshProgress

private synchronized void doRefreshProgress(int id, int progress, boolean fromUser, boolean callBackToApp) { float scale = mMax > 0 ? (float) progress / (float) mMax : 0; final Drawable d = mCurrentDrawable; if (d != null) { Drawable progressDrawable = null; ... final int level = (int) (scale * MAX_LEVEL); // 在这里progress被设置成了level最终被设置进了progressDrawable (progressDrawable != null ? progressDrawable : d).setLevel(level); } else { invalidate(); } ... }

原来进度值最终被转成了level然后被设置进了progressDrawable。 一般我们写progressDrawable都是这么写：

<item android:id="@android:id/progress"> <clip> <shape> <solid android:color="#20ffffff"/> <corners android:radius="60dp"/> </shape> </clip> </item>

所以，这是一个ClipDrawable,那再看一下ClipDrawable.draw(),一切都明了了：

@Override public void draw(Canvas canvas) { if (mClipState.mDrawable.getLevel() == 0) { return; } final Rect r = mTmpRect; final Rect bounds = getBounds(); int level = getLevel(); int w = bounds.width(); final int iw = 0; //mClipState.mDrawable.getIntrinsicWidth(); if ((mClipState.mOrientation & HORIZONTAL) != 0) { w -= (w - iw) * (10000 - level) / 10000; } int h = bounds.height(); final int ih = 0; //mClipState.mDrawable.getIntrinsicHeight(); if ((mClipState.mOrientation & VERTICAL) != 0) { h -= (h - ih) * (10000 - level) / 10000; } final int layoutDirection = getLayoutDirection(); Gravity.apply(mClipState.mGravity, w, h, bounds, r, layoutDirection); if (w > 0 && h > 0) { canvas.save(); canvas.clipRect(r); //根据进度矩形裁剪 mClipState.mDrawable.draw(canvas); canvas.restore(); } }

所以，要让Progress出现圆角，就需要修改ClipDrawable这块，让其裁剪出一个圆角矩形。

RoundClipDrawable

怎么样才能裁剪出一个圆角矩形呢？去看看Canvas的文档，就能发现Canvas.clipPath是能够剪裁Path的，这样能裁剪的形状就多了。这样思路也基本确定了，仿照ClipDrawable的思路，就能写出下面的RoundRectangleClipDrawable:

public class RoundRectangleClipDrawable { ... @Override public void draw(Canvas canvas) { final Rect r = mTmpRect; final Rect bounds = getBounds(); int level = getLevel(); int w = bounds.width(); mTmpPath.reset(); final int iw = 0; //mClipState.mDrawable.getIntrinsicWidth(); w -= (w - iw) * (10000 - level) / 10000; int h = bounds.height(); r.set(bounds); r.right = r.left + w; mTmpRectF.set(r); // 圆角矩形path mTmpPath.addRoundRect(mTmpRectF, mRadius, mRadius, Path.Direction.CW); if (w > 0 && h > 0) { canvas.save(); canvas.clipPath(mTmpPath); mClipState.mDrawable.draw(canvas); canvas.restore(); } } ... }

整个文件见 RoundClipDrawable Gist

为ProgressBar的progress加上圆角

按照这个节奏，接下来就是把这个RoundRectangelClipDrawable写到xml中就完事了，可是，安卓由于安全原因，不允许在xml中使用自定义Drawable,这也好办，再多写点代码，在ProgressBar基础上改改，将progressDrawable替换成RoundRectangelClipDrawable就可以了：

public class RoundIndicatorProgressBar extends ProgressBar { private static final float CORNER_RADIUS = 50.0f; public RoundIndicatorProgressBar(Context context) { this(context, null); } public RoundIndicatorProgressBar(Context context, AttributeSet attrs) { this(context, attrs, 0); } public RoundIndicatorProgressBar(Context context, AttributeSet attrs, int defStyle) { super(context, attrs, defStyle); } @Override public void setProgressDrawable(Drawable d) { super.setProgressDrawable(tileify(d, false)); } // 将xml中读取的drawable中id为progress和secondaryProgress的drawable替换为圆角的版本 private Drawable tileify(Drawable drawable, boolean clip) { if (drawable instanceof LayerDrawable) { LayerDrawable background = (LayerDrawable) drawable; final int N = background.getNumberOfLayers(); Drawable[] outDrawables = new Drawable[N]; for (int i = 0; i < N; i++) { int id = background.getId(i); outDrawables[i] = tileify(background.getDrawable(i), (id == android.R.id.progress || id == android.R.id.secondaryProgress)); } LayerDrawable newBg = new LayerDrawable(outDrawables); for (int i = 0; i < N; i++) { newBg.setId(i, background.getId(i)); } return newBg; } else { if (clip) { return new RoundClipDrawable(drawable, CORNER_RADIUS); } } return drawable; } }

这里应该是结语

其实，写了这么多，还是觉得Linus大神那句话来的最实在：Read the fucking source code。源码都有了，还有什么做不出来呢？

Animator

Animator V.S. Animation

这两个长的很像啊，不过一个是 android.animation.Animator，一个是android.view.Animation。从包名可能能猜出少许：前者是一个适用面更加广泛的动画类，后者主要操作View，在之前的文章也说了。android.animation.Animator是API 11以后引入的。

对比其类的成员变量，也可以发现：Animation是基于View的矩阵变换的；而Animator则是一个更加纯粹的抽象动画定义。故Animation能处理的动画效果有限。

Animator or Animation ?

当你想实现一个动画时，是使用Animator还是Animation类？这取决于：

支持的Android版本，Animator不支持API 11以前的版本

动画的效果，Animation支持的动画效果有限，例如3D翻转的效果用Animation就无法实现无法用XML表达。

如果你想在API 11之前的版本使用Animator，可以看看这个库。

android.animation.Animator

android.animation.Animator是一个定义了动画的抽象类。其抽象方法都是些start()、setInterpolator()之类的最基本的设置以及操作动画的方法。

android.animation.AnimatorSet

这个类定义了动画集。动画集有多个子动画组成，且自动化之间可有可没有依赖（依赖是指动画之间的关系，例如子动画A要在子动画B之后执行）。

TO BE DONE

android.animation.ValueAnimator

ValueAnimator是能对一个值进行动画计算的类。在这个类中，实现了一个AnimationHandler,专门用于处理动画的Handler，每个线程都有一个静态的Handler专门来处理动画。 我们来看一下AnimationHandler的实现：

protected static class AnimationHandler implements Runnable { // Called by the Choreographer. @Override public void run() { mAnimationScheduled = false; doAnimationFrame(mChoreographer.getFrameTime()); } private void scheduleAnimation() { if (!mAnimationScheduled) { // 让 mChoreographer安排下一次计算的时间 mChoreographer.postCallback(Choreographer.CALLBACK_ANIMATION, this, null); mAnimationScheduled = true; } } private void doAnimationFrame(long frameTime) { ... ... for (int i = 0; i < numAnims; ++i) { ValueAnimator anim = mTmpAnimations.get(i); if (mAnimations.contains(anim) && anim.doAnimationFrame(frameTime)) { //调用 doAnimationFrame mEndingAnims.add(anim); } } mTmpAnimations.clear(); if (mEndingAnims.size() > 0) { for (int i = 0; i < mEndingAnims.size(); ++i) { mEndingAnims.get(i).endAnimation(this); } mEndingAnims.clear(); } // If there are still active or delayed animations, schedule a future call to // onAnimate to process the next frame of the animations. if (!mAnimations.isEmpty() || !mDelayedAnims.isEmpty()) { scheduleAnimation(); //安排下一次动画计算 } } }

可以看到，整个过程就是 计算动画数值->安排下一次计算->计算动画数值 这样循环以往。

ViewPropertyAnimator

在Android 3.0以后，可以直接调用View.animate().start()来实现动画，下面我们就来看一下：

/** * This method returns a ViewPropertyAnimator object, which can be used to animate * specific properties on this View. * * @return ViewPropertyAnimator The ViewPropertyAnimator associated with this View. */ public ViewPropertyAnimator animate() { if (mAnimator == null) { mAnimator = new ViewPropertyAnimator(this); } return mAnimator; }

View.animate()返回的其实是一个ViewPropertyAnimator对象，这个对象是专门来动画View对象的。 下面我们来看一下ViewPropertyAnimator：

public class ViewPropertyAnimator { ... ... /** * Starts the underlying Animator for a set of properties. We use a single animator that * simply runs from 0 to 1, and then use that fractional value to set each property * value accordingly. */ private void startAnimation() { mView.setHasTransientState(true); ValueAnimator animator = ValueAnimator.ofFloat(1.0f); ArrayList<NameValuesHolder> nameValueList = (ArrayList<NameValuesHolder>) mPendingAnimations.clone(); mPendingAnimations.clear(); int propertyMask = 0; int propertyCount = nameValueList.size(); ... ... animator.addUpdateListener(mAnimatorEventListener); animator.addListener(mAnimatorEventListener); ... ... animator.start(); } }

可见实际上ViewPropertyAnimator底层用的还是ValueAnimator，只不过记下来了当前动画的属性和名字，然后设置好ValueAnimator的事件回调，在onAnimationUpdate()回调中设置属性的值同时invalidate()。

@Override public void onAnimationUpdate(ValueAnimator animation) { PropertyBundle propertyBundle = mAnimatorMap.get(animation); if (propertyBundle == null) { // Shouldn't happen, but just to play it safe return; } boolean useDisplayListProperties = mView.mDisplayList != null; // alpha requires slightly different treatment than the other (transform) properties. // The logic in setAlpha() is not simply setting mAlpha, plus the invalidation // logic is dependent on how the view handles an internal call to onSetAlpha(). // We track what kinds of properties are set, and how alpha is handled when it is // set, and perform the invalidation steps appropriately. boolean alphaHandled = false; if (!useDisplayListProperties) { mView.invalidateParentCaches(); } float fraction = animation.getAnimatedFraction(); int propertyMask = propertyBundle.mPropertyMask; if ((propertyMask & TRANSFORM_MASK) != 0) { mView.invalidateViewProperty(false, false); } ArrayList<NameValuesHolder> valueList = propertyBundle.mNameValuesHolder; if (valueList != null) { int count = valueList.size(); for (int i = 0; i < count; ++i) { NameValuesHolder values = valueList.get(i); float value = values.mFromValue + fraction * values.mDeltaValue; // 这里修改属性 if (values.mNameConstant == ALPHA) { alphaHandled = mView.setAlphaNoInvalidation(value); } else { setValue(values.mNameConstant, value); } } } if ((propertyMask & TRANSFORM_MASK) != 0) { mView.mTransformationInfo.mMatrixDirty = true; if (!useDisplayListProperties) { mView.mPrivateFlags |= View.PFLAG_DRAWN; // force another invalidation } } // invalidate(false) in all cases except if alphaHandled gets set to true // via the call to setAlphaNoInvalidation(), above if (alphaHandled) { mView.invalidate(true); } else { mView.invalidateViewProperty(false, false); } if (mUpdateListener != null) { mUpdateListener.onAnimationUpdate(animation); } }

Conclusion

ActionBar Overflow

当ActionBar上当Item多的时候，系统会将这些Item折叠成一个下拉菜单，并且显示一个三个点的Action Item，这个就是ActionBar Overflow

Inconsistent

但是Android设备上就有很多不一致的地方，比如有的机器有硬件菜单按钮，有的就没有。在有硬件菜单按钮的机器上，Overflow是不在ActionBar上显示按钮的，这就意味着，如果用户不去按菜单按钮，是不知道这块还有更多选项的。

standard ?

Design Guide 也对此有所提及：

Android phones with traditional navigation hardware keys don't display the virtual navigation bar at the bottom of the screen. Instead, the action overflow is available from the menu hardware key. The resulting actions popup has the same style as in the previous example, but is displayed at the bottom of the screen.

不过，在后来Google自家的应用中，好像也没有遵守这个Guide。 好吧，反正我是觉得，不管有没有硬件菜单键，Overflow button 都应该出现在ActionBar中。 下面就来讲讲怎么实现。

solution Hack

这个方法就是骗系统说，我没有菜单键，你看着办。。

try { ViewConfiguration config = ViewConfiguration.get(this); Field menuKeyField = ViewConfiguration.class.getDeclaredField("sHasPermanentMenuKey"); if(menuKeyField != null) { menuKeyField.setAccessible(true); menuKeyField.setBoolean(config, false); } } catch (Exception ex) { // Ignore }

当然，这个方法会有一些缺点：例如在LG某款机器上不好用，或者如果你的按键有声音的话，你会听见两声按键声。

solution 2

很自然会想到，那我自己实现一个菜单怎么样？当然没问题：

<menu xmlns:android="http://schemas.android.com/apk/res/android" > <item android:id="@+id/menu_overflow" android:icon="@drawable/abs__ic_menu_moreoverflow_normal_holo_light" android:orderInCategory="11111" android:showAsAction="always"> <menu> <item android:id="@+id/menu_overflow_item1" android:showAsAction="never" android:title="@string/overflow_item1_title"/> <item android:id="@+id/menu_overflow_item2" android:showAsAction="never" android:title="@string/overflow_item2_title"/> </menu> </item>

这样就实现一个看起来差不多的overflow了，然后还需要实现菜单键能调出这个overflow：

@Override public boolean onCreateOptionsMenu(Menu menu) { // ...init menu here... mainMenu=menu; return true; } @Override public boolean onKeyUp(int keycode, KeyEvent e) { switch(keycode) { case KeyEvent.KEYCODE_MENU: if (mainMenu !=null) { mainMenu.performIdentifierAction(R.id.menu_overflow, 0); } } return super.onKeyUp(keycode, e); }

当然，这个方法在2.x的系统上，菜单不是下拉的，而是popup的，并且你要注意ActionItem的数量，避免出现两个ActionOverflow的尴尬情况。

really nice post here: http://nicolaspomepuy.fr/?p=18

问题

如何访问/data/data/your.package/中的文件？在没有root的情况下，shell是没有/data/data的访问权限的。

run-as

adb shell 中有一个命令叫做run-as

Usage: run-as < package-name> < command> [< args>]

即使用run-as命令可以su到相应的用户，从而有私有文件的权限，这样在调试的时候就方便许多了。

tags: android

今天在使用appcompat库的时候，要用一个custom属性，经过一番google，结论是使用：

<menu xmlns:android="http://schemas.android.com/apk/res/android" xmlns:app="http://schemas.android.com/apk/res-auto" xmlns:tools="http://schemas.android.com/tools" tools:context="com.wukongtv.wkremote.client.MainActivity2">

结果怎么都无法找到资源，后来发现，对于不是一个包名的，res-auto可能不好使，所以这时namespace可以制定包名：

<menu xmlns:android="http://schemas.android.com/apk/res/android" xmlns:app="http://schemas.android.com/apk/android.support.v7.app" xmlns:tools="http://schemas.android.com/tools" tools:context="com.wukongtv.wkremote.client.MainActivity2">

这样就可以了。

现在随着友盟这类统计工具在项目中集成，根据不同渠道打不同的APK包也成为日常工作之一。神马？你还在手动改渠道号一个一个打包？！那你一定是个非常勤奋的程序员- -！正好尝试使用Android Studio，稍微了解了下Android Studio的使用的构建工具：Gradle。

什么是Gradle

你可以看一下Gradle主页。

简单来说，Gradle是一个自动化编译部署测试工具。Gradle内容很广，还有专门的书介绍Gradle。而Android Studio使用的是Gradle中的一部分功能。

build.gradle

build.gradle就是Android Studio使用的Gradle文件，下面是一个最简单的build.gradle示例：

buildscript { repositories { mavenCentral() } dependencies { classpath 'com.android.tools.build:gradle:0.6.+' } } apply plugin: 'android' android { compileSdkVersion 17 }

buildscript {...} 配置编译代码，这部分基本上不用怎么编辑;

apply plugin: 'android' 是表示用android插件;

android {...} 就是android插件的配置了。具体配置内容以及取值可以看这里

Build Task

Gradle中用Task来代表一系列操作，有点类似于Makefile中的Target。常见的Tasks有：

assemble

build

check

clean

根据名字基本就能知道Task作用，其中build = assemble + check。

执行task直接就是在命令行执行gradle [task],例如： gradle assemble

gradle assembleRelease

Build参数配置

Gradle脚本中的参数是DSL规范的，即使用的是类似于Java包名的方式：

a.b.c = 1 a { b { c 1 } }

上面两种方式表示的是一个意思。 可以配置的参数这里不做详述，请到http://tools.android.com/tech-docs/new-build-system/user-guide查阅。

下面讲几个主要使用的参数。

Build Types

TODO

Signing Configurations

在生成APK的时候，有一步是用一个Key给APK签名，关于签名的配置项都在signingConfigs中：

signingConfigs { myConfig { storeFile file("path-to-keystore") storePassword "******" keyAlias "******" keyPassword "******" } }

然后在编译类型中引用：

buildTypes { release { ... signingConfig signingConfigs.myConfig } }

这样签名的配置就好了。不过按上文配置，有一个问题：build.gradle经常是会提交到代码管理系统中，而显然把key明文放在代码库里不怎么安全（特别如果你写的是开源项目）。一个替代的方案是输入密码，或者将密码存储在环境变量中，可以参看这个链接：http://stackoverflow.com/questions/18328730/how-to-create-a-release-signed-apk-file-using-gradle

... signingConfigs { release { storeFile file(System.getenv("KEYSTORE")) storePassword System.getenv("KEYSTORE_PASSWORD") keyAlias System.getenv("KEY_ALIAS") keyPassword System.getenv("KEY_PASSWORD") } }

Product flavors

如果你一个项目想要生成不同的APK包，有不同的包名，或者不同的资源，那么这就是使用Product flavors的时候了。

android { .... productFlavors { flavor1 { packageName "com.example.flavor1" versionCode 20 } flavor2 { packageName "com.example.flavor2" minSdkVersion 14 } } }

上面的示例会生成两个不同的APK包，有着不同的包名以及属性。Product flavors里边可以设置的属性，参照http://tools.android.com/tech-docs/new-build-system/user-guide。

友盟多渠道打包

看了上面这么多，现在来一个示例：写一个build.gradle完成友盟多渠道打包。 友盟渠道区分是通过在AndroidManifest.xml的<meta-data>实现的：

<meta-data android:value="UMENG_CHANNEL_VALUE" android:name="UMENG_CHANNEL"/>

所以基本的思路就是，在打包的时候替换AndroidManifest.xml中的字符串以打出不同的APK包。 build.gradle关键部分如下：

android { compileSdkVersion 19 buildToolsVersion '19.0.0' defaultConfig { minSdkVersion 7 targetSdkVersion 19 } // 签名信息，都存在环境变量中 signingConfigs { release { storeFile file(System.getenv("KEYSTORE")) storePassword System.getenv("KEYSTORE_PASSWORD") keyAlias System.getenv("KEY_ALIAS") keyPassword System.getenv("KEYSTORE_PASSWORD") } } buildTypes { release { runProguard true proguardFile getDefaultProguardFile('proguard-android-optimize.txt') signingConfig signingConfigs.release //使用上述签名信息 } } productFlavors { defaultFlavor { proguardFile 'proguard-rules.txt' } // 需要打不同的版本 xiaomi { } LeTv { } } } // 下面这段代码摘自 https://github.com/umeng/umeng-muti-channel-build-tool/tree/master/Gradle // 实现用productFlavor名字替换AndroidManifest.xml 中的 UMENG_CHANNEL_VALUE 字符串 android.applicationVariants.all { variant -> variant.processManifest.doLast{ copy{ from("${buildDir}/manifests"){ include "${variant.dirName}/AndroidManifest.xml" } into("${buildDir}/manifests/$variant.name") filter{ String line -> line.replaceAll("UMENG_CHANNEL_VALUE", "${variant.productFlavors[0].name}") } variant.processResources.manifestFile = file("${buildDir}/manifests/${variant.name}/${variant.dirName}/AndroidManifest.xml") } } }

在修改完build.gradle之后，需要使用Android Studio的sync Project with gradle files功能同步工程设置。 之后就在Android Studio的Terminal中输入gradle build（windows是gradlew build）,稍等片刻，所有生成的APK都在你工程的build/apk下啦！

enjoy！

写在前面的话

在这半年学习安卓的过程中，我发现最好的资料就是http://developer.android.com了，而SDK中带的Demo工程，也是相当优秀的学习材料。个人觉的如果把ApiDemos这个工程熟悉了，那么Android应用开发基本是熟练了。以这个工程为提纲来学习Android开发似乎是个不错的选择。

准备利用闲暇时间把ApiDemos这个工程系统过一遍，中间的收获我也会尝试写成博客记录下来。

ApiDemos工程路径：SDK/samples/android-version/ApiDemos

自从Android 3.0发布以来，关于如下的异常栈就经常在StackOverflow上被问到：

java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState at android.support.v4.app.FragmentManagerImpl.checkStateLoss(FragmentManager.java:1341) at android.support.v4.app.FragmentManagerImpl.enqueueAction(FragmentManager.java:1352) at android.support.v4.app.BackStackRecord.commitInternal(BackStackRecord.java:595) at android.support.v4.app.BackStackRecord.commit(BackStackRecord.java:574)

这篇文章将解释这个异常出现的时间以及原因，并且提出几个解决这个异常的方案。

异常抛出的原因

这个异常之所以会被抛出，是因为你尝试在Activity的状态已经被保存之后commit一个FragmentTransaction，这个现象称之为Activity状态丢失(Activity state loss)。在进一步了解细节之前，让我们先来看一下当onSaveInstanceState()被调用的时候发生了什么。大家都知道，Android系统能够在任何时段终止应用进程以获得内存，后台进程也很有可能被终止。换句话说，Activity就要做好随时被终止的准备,并且不能让用户感知到Activity的不稳定。因此，Android Framework提供给Activity一个机会来保存当前的数据以备恢复：onSaveInstanceState()。在onSaveInstanceState()被保存的数据在Activity被重新创建时提供给它，这样就能让用户体会不到Activity的销毁与重建，从而获得无缝切换的体验。

当framework调用onSaveInstance()时，会传入一个Bundle对象给Activity以让其存储其当前dialogs,fragments,views的状态。当onSaveInstance()返回的时候，系统将这个Bundle对象打包(parcel)然后存储起来。当系统决定重建Activity的时候，就把这个Bundle传入onCreate()回复其以前的状态。

为什么这个异常会被抛出呢？我们知道在onSaveInstance()返回的时候，Activity的所有信息都保存在那个Bundle中了。在这个时间点之后对Activity做的状态改动，自然就不能够被保存下来了。为了保证用户体验，Android会避免状态丢失，在这个情况下就是抛出这个异常。

如何避免这个异常出现

了解了这个异常抛出的原因，那么防止这个异常崩溃就很容易了。下面就是一些建议：

尽量不要在在Activity生命周期函数（onActivityResult(), onResume(), onStart()等等）里边commitFragmentTransaction。如果你的应用需要在其他（不是在onCreate()）生命周期里边commit，尝试切换到FragmentActivity#onResumeFragments() 或者 Activity#onPostResume()。

不要在异步回调里边commitFragmentTransaction，例如AsyncTask。这点很明显，不多说。

如果上述方法均不适用，考虑使用commitAllowingStateLoss()来替代commit()，这个允许你出现状态丢失，不过至少你的程序不会崩溃了。

参考

http://www.androiddesignpatterns.com/2013/08/fragment-transaction-commit-state-loss.html

BTIH

BTIH，简单来说，可以理解一个种子的标识符。

BTIH (BitTorrent Info Hash) These are hex encoded SHA1 hash sums of the "info" sections of BitTorrent metafiles as used by BitTorrent to identify downloadable files or sets of files. For backwards compatibility with existing links, clients should also support the Base32 encoded version of the hash.[2] xt=urn:btih:[ BitTorrent Info Hash (Hex) ] Some clients require Base32 of info_hash (Vuze for ex.).

一般来说，为长度40的SHA-1哈希。

BTIH本来只是一个获取种子的手段，但是，万能的迅雷出现了。。迅雷上很大一部分资源都是用BTIH索引的，也就是说，你只需要一个BTIH值就可以点播一部影片。

这个时候想要从BT种子计算出BTIH就是必须的了。

计算方法

根据BTIH的定义，其计算方法就是 SHA1(info section of a torrent file) 所以其关键是怎么从BT种子中找出其info段。

BEncode

种子文件是使用BEncode来编码的，关于BEncode编码规则：

Bencode uses ASCII characters as delimiters and digits.

An integer is encoded as ie. Leading zeros are not allowed (although the number zero is still represented as "0"). Negative values are encoded by prefixing the number with a minus sign. The number 42 would thus be encoded as "i42e", 0 as "i0e", and -42 as "i-42e". Negative zero is not permitted.

A byte string (a sequence of bytes, not necessarily characters) is encoded as :. The length is encoded in base 10, like integers, but must be non-negative (zero is allowed); the contents are just the bytes that make up the string. The string "spam" would be encoded as "4:spam". The specification does not deal with encoding of characters outside the ASCII set; to mitigate this, some BitTorrent applications explicitly communicate the encoding (most commonly UTF-8) in various non-standard ways. This is identical to how netstrings work, except that netstrings additionally append a comma suffix after the byte sequence.

A list of values is encoded as le . The contents consist of the bencoded elements of the list, in order, concatenated.

A list consisting of the string "spam" and the number 42 would be encoded as: "l4:spami42ee". Note the absence of separators between elements.

A dictionary is encoded as de. The elements of the dictionary are encoded each key immediately followed by its value. All keys must be byte strings and must appear in lexicographical order. A dictionary that associates the values 42 and "spam" with the keys "foo" and "bar", respectively, would be encoded as follows: "d3:bar4:spam3:fooi42ee". (This might be easier to read by inserting some spaces: "d 3:bar 4:spam 3:foo i42e e".)

There are no restrictions on what kind of values may be stored in lists and dictionaries; they may (and usually do) contain other lists and dictionaries. This allows for arbitrarily complex data structures to be encoded.

代码

具体代码见 https://gist.github.com/bladeFury/6975656

源代码位置

support library 源码的位于/extras/android/support/v4/src下面

attach至eclipse

有了源码，你会发现这个lib是只读的没法attach源码。这时按如下步骤操作：

Goto "Configure Build Path"

Add External JARs > YourProject/libs/android-support-v4.jar (I know your project had already referenced to it but don't worry, just add it again).

Expand jar and attach Source to the External Jar: android-sdk/extras/android/support/v4/src

Switch to the "Order and Export" tab, pull up the external jar above the "Android Dependencies"

关于 Android 源码我就不介绍了，source.android.com上自己慢慢看。 按照source.android.com上面的教程，需要使用Goolgle的repo工具来同步git repo，偏偏，这个repo.py在windows下不好使，这让我等没有mac的屌丝情何以堪。

用windows起码还有一个好处，可以用Source Insight嘛。

下面就是如何在windows下获取Android源码的步骤：

安装Git环境

这个就不详细说了，你可以装msysGit,或者Github for windows

打开shell，下载这个脚本authogit.sh

打开shell，切换至一个空目录，执行这个脚本。注意要有足够的磁盘空间

下载应该已经开始了，等一个晚上把

整个source tree应该有差不多10G，这个脚本没有像repo那样制定分支等功能。