打印堆栈是调试的常用方法，一般在系统异常时，我们可以将异常情况下的堆栈打印出来，这样十分方便错误查找。实际上还有另外一个非常有用的功能：分析代码的行为。android代码太过庞大复杂了，完全的静态分析经常是无从下手，因此通过打印堆栈的动态分析也十分必要。
成都创新互联公司是工信部颁发资质IDC服务器商，为用户提供优质的德阳服务器托管服务
Android打印堆栈的方法，简单归类一下
1. zygote的堆栈dump
实际上这个可以同时dump java线程及native线程的堆栈，对于java线程，java堆栈和native堆栈都可以得到。
使用方法很简单，直接在adb shell或串口中输入：
[plain] view plaincopy
kill -3 pid
输出的trace会保存在 /data/anr/traces.txt文件中。这个需要注意，如果没有 /data/anr/这个目录或/data/anr/traces.txt这个文件，需要手工创建一下，并设置好读写权限。
如果需要在代码中，更容易控制堆栈的输出时机，可以用以下命令获取zygote的core dump:
[java] view plaincopy
Process.sendSignal(pid, Process.SIGNAL_QUIT);
原理和命令行是一样的。
不过需要注意两点：
adb shell可能会没有权限，需要root。
android 4.2中关闭了native thread的堆栈打印，详见 dalvik/vm/Thread.cpp的dumpNativeThread方法：
[cpp] view plaincopy
dvmPrintDebugMessage(target,
"\"%s\" sysTid=%d nice=%d sched=%d/%d cgrp=%s\n",
name, tid, getpriority(PRIO_PROCESS, tid),
schedStats.policy, schedStats.priority, schedStats.group);
dumpSchedStat(target, tid);
// Temporarily disabled collecting native stacks from non-Dalvik
// threads because sometimes they misbehave.
//dvmDumpNativeStack(target, tid);
Native堆栈的打印被关掉了！不过对于大多数情况，可以直接将这个注释打开。
2. debuggerd的堆栈dump
debuggerd是android的一个daemon进程，负责在进程异常出错时，将进程的运行时信息dump出来供分析。debuggerd生 成的coredump数据是以文本形式呈现，被保存在 /data/tombstone/ 目录下(名字取的也很形象，tombstone是墓碑的意思)，共可保存10个文件，当超过10个时，会覆盖重写最早生成的文件。从4.2版本开 始，debuggerd同时也是一个实用工具：可以在不中断进程执行的情况下打印当前进程的native堆栈。使用方法是:
[plain] view plaincopy
debuggerd -b pid
这可以协助我们分析进程执行行为，但最最有用的地方是：它可以非常简单的定位到native进程中锁死或错误逻辑引起的死循环的代码位置。
3. java代码中打印堆栈
Java代码打印堆栈比较简单， 堆栈信息获取和输出，都可以通过Throwable类的方法实现。目前通用的做法是在java进程出现需要注意的异常时，打印堆栈，然后再决定退出或挽救。通常的方法是使用exception的printStackTrace()方法：
[java] view plaincopy
try {
...
} catch (RemoteException e) {
e.printStackTrace();
...
}
当然也可以只打印堆栈不退出，这样就比较方便分析代码的动态运行情况。Java代码中插入堆栈打印的方法如下：
[java] view plaincopy
Log.d(TAG,Log.getStackTraceString(new Throwable()));
4. C++代码中打印堆栈
C++也是支持异常处理的，异常处理库中，已经包含了获取backtrace的接口，Android也是利用这个接口来打印堆栈信息的。在Android的C++中，已经集成了一个工具类CallStack，在libutils.so中。使用方法：
[cpp] view plaincopy
#include utils/CallStack.h
...
CallStack stack;
stack.update();
stack.dump();
使用方式比较简单。目前Andoid4.2版本已经将相关信息解析的很到位，符号表查找，demangle，偏移位置校正都做好了。
[plain] view plaincopy
5. C代码中打印堆栈
C代码，尤其是底层C库，想要看到调用的堆栈信息，还是比较麻烦的。 CallStack肯定是不能用，一是因为其实C++写的，需要重新封装才能在C中使用，二是底层库反调上层库的函数，会造成链接器循环依赖而无法链接。 不过也不是没有办法，可以通过android工具类CallStack实现中使用的unwind调用及符号解析函数来处理。
这里需要注意的是，为解决链接问题，最好使用dlopen方式，查找需要用到的接口再直接调用，这样会比较简单。如下为相关的实现代码，只需要在要 打印的文件中插入此部分代码，然后调用getCallStack()即可，无需包含太多的头文件和修改Android.mk文件：
[cpp] view plaincopy
#define MAX_DEPTH 31
#define MAX_BACKTRACE_LINE_LENGTH 800
#define PATH "/system/lib/libcorkscrew.so"
typedef ssize_t (*unwindFn)(backtrace_frame_t*, size_t, size_t);
typedef void (*unwindSymbFn)(const backtrace_frame_t*, size_t, backtrace_symbol_t*);
typedef void (*unwindSymbFreeFn)(backtrace_symbol_t*, size_t);
static void *gHandle = NULL;
static int getCallStack(void){
ssize_t i = 0;
ssize_t result = 0;
ssize_t count;
backtrace_frame_t mStack[MAX_DEPTH];
backtrace_symbol_t symbols[MAX_DEPTH];
unwindFn unwind_backtrace = NULL;
unwindSymbFn get_backtrace_symbols = NULL;
unwindSymbFreeFn free_backtrace_symbols = NULL;
// open the so.
if(gHandle == NULL) gHandle = dlopen(PATH, RTLD_NOW);
// get the interface for unwind and symbol analyse
if(gHandle != NULL) unwind_backtrace = (unwindFn)dlsym(gHandle, "unwind_backtrace");
if(gHandle != NULL) get_backtrace_symbols = (unwindSymbFn)dlsym(gHandle, "get_backtrace_symbols");
if(gHandle != NULL) free_backtrace_symbols = (unwindSymbFreeFn)dlsym(gHandle, "free_backtrace_symbols");
if(!gHandle ||!unwind_backtrace ||!get_backtrace_symbols || !free_backtrace_symbols ){
ALOGE("Error! cannot get unwind info: handle:%p %p %p %p",
gHandle, unwind_backtrace, get_backtrace_symbols, free_backtrace_symbols );
return result;
}
count= unwind_backtrace(mStack, 1, MAX_DEPTH);
get_backtrace_symbols(mStack, count, symbols);
for (i = 0; i count; i++) {
char line[MAX_BACKTRACE_LINE_LENGTH];
const char* mapName = symbols[i].map_name ? symbols[i].map_name : "unknown";
const char* symbolName =symbols[i].demangled_name ? symbols[i].demangled_name : symbols[i].symbol_name;
size_t fieldWidth = (MAX_BACKTRACE_LINE_LENGTH - 80) / 2;
if (symbolName) {
uint32_t pc_offset = symbols[i].relative_pc - symbols[i].relative_symbol_addr;
if (pc_offset) {
snprintf(line, MAX_BACKTRACE_LINE_LENGTH, "#%02d pc %08x %.*s (%.*s+%u)",
i, symbols[i].relative_pc, fieldWidth, mapName,
fieldWidth, symbolName, pc_offset);
} else {
snprintf(line, MAX_BACKTRACE_LINE_LENGTH, "#%02d pc %08x %.*s (%.*s)",
i, symbols[i].relative_pc, fieldWidth, mapName,
fieldWidth, symbolName);
}
} else {
snprintf(line, MAX_BACKTRACE_LINE_LENGTH, "#%02d pc %08x %.*s",
i, symbols[i].relative_pc, fieldWidth, mapName);
}
ALOGD("%s", line);
}
free_backtrace_symbols(symbols, count);
return result;
}
对sched_policy.c的堆栈调用分析如下,注意具体是否要打印，在哪里打印，还可以通过pid、uid、property等来控制一下，这样就不会被淹死在trace的汪洋大海中。
[plain] view plaincopy
D/SchedPolicy( 1350): #00 pc 0000676c /system/lib/libcutils.so
D/SchedPolicy( 1350): #01 pc 00006b3a /system/lib/libcutils.so (set_sched_policy+49)
D/SchedPolicy( 1350): #02 pc 00010e82 /system/lib/libutils.so (androidSetThreadPriority+61)
D/SchedPolicy( 1350): #03 pc 00068104 /system/lib/libandroid_runtime.so (android_os_Process_setThreadPriority(_JNIEnv*, _jobject*, int, int)+7)
D/SchedPolicy( 1350): #04 pc 0001e510 /system/lib/libdvm.so (dvmPlatformInvoke+112)
D/SchedPolicy( 1350): #05 pc 0004d6aa /system/lib/libdvm.so (dvmCallJNIMethod(unsigned int const*, JValue*, Method const*, Thread*)+417)
D/SchedPolicy( 1350): #06 pc 00027920 /system/lib/libdvm.so
D/SchedPolicy( 1350): #07 pc 0002b7fc /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184)
D/SchedPolicy( 1350): #08 pc 00060c30 /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+271)
D/SchedPolicy( 1350): #09 pc 0004cd34 /system/lib/libdvm.so
D/SchedPolicy( 1350): #10 pc 00049382 /system/lib/libandroid_runtime.so
D/SchedPolicy( 1350): #11 pc 00065e52 /system/lib/libandroid_runtime.so
D/SchedPolicy( 1350): #12 pc 0001435e /system/lib/libbinder.so (android::BBinder::transact(unsigned int, android::Parcel const, android::Parcel*, unsigned int)+57)
D/SchedPolicy( 1350): #13 pc 00016f5a /system/lib/libbinder.so (android::IPCThreadState::executeCommand(int)+513)
D/SchedPolicy( 1350): #14 pc 00017380 /system/lib/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+183)
D/SchedPolicy( 1350): #15 pc 0001b160 /system/lib/libbinder.so
D/SchedPolicy( 1350): #16 pc 00011264 /system/lib/libutils.so (android::Thread::_threadLoop(void*)+111)
D/SchedPolicy( 1350): #17 pc 000469bc /system/lib/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+63)
D/SchedPolicy( 1350): #18 pc 00010dca /system/lib/libutils.so
D/SchedPolicy( 1350): #19 pc 0000e3d8 /system/lib/libc.so (__thread_entry+72)
D/SchedPolicy( 1350): #20 pc 0000dac4 /system/lib/libc.so (pthread_create+160)
D/SchedPolicy( 1350): #00 pc 0000676c /system/lib/libcutils.so
D/SchedPolicy( 1350): #01 pc 00006b3a /system/lib/libcutils.so (set_sched_policy+49)
D/SchedPolicy( 1350): #02 pc 00016f26 /system/lib/libbinder.so (android::IPCThreadState::executeCommand(int)+461)
D/SchedPolicy( 1350): #03 pc 00017380 /system/lib/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+183)
D/SchedPolicy( 1350): #04 pc 0001b160 /system/lib/libbinder.so
D/SchedPolicy( 1350): #05 pc 00011264 /system/lib/libutils.so (android::Thread::_threadLoop(void*)+111)
D/SchedPolicy( 1350): #06 pc 000469bc /system/lib/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+63)
D/SchedPolicy( 1350): #07 pc 00010dca /system/lib/libutils.so
D/SchedPolicy( 1350): #08 pc 0000e3d8 /system/lib/libc.so (__thread_entry+72)
D/SchedPolicy( 1350): #09 pc 0000dac4 /system/lib/libc.so (pthread_create+160)
6. 其它堆栈信息查询
之前很早就想写写Android 的动画，最近刚好有时间，大概聊一聊安卓动画。
个人习惯将动画分为：补间动画（透明度、旋转、位移、缩放）、帧动画、和属性动画，这一篇，我们先说说补间动画。
补间动画这个词出于flash，在两个关键帧（ 可以理解成动画开始和结束 ）中间需要做“补间动画”，才能实现图画的运动；插入补间动画后两个关键帧之间的插补帧是由计算机自动运算而得到的。
实际上，Android 的补间动画也是由我们指定动画开始、动画结束2个关键点，中间部分的动画由系统完成
在正式开始之前，我们先说下Android 系统的坐标系，屏幕左上角为坐标原点，假如屏幕为1080*1980，那么左上角为（0,0），右上角为（1080,0），左下角为（0,1980），右下角为（1080,1980）
所有动画有以下公共属性，注释比较详细，这里就不在详述了
ScaleAnimation有3种构造方法
我们先看第一种，其起始比例为0，缩放比例为1.4，即放大到1.4倍
效果如下：
第二种，pivotx,pivotY分别代表起始位置的x、y方向的坐标，我们设置为（100,100）
效果如下：
第三种，pivotXType和pivotYType有2种模式，RELATIVE_TO_SELF（相对于自身）和RELATIVE_TO_PARENT（相对于父布局），如果设置这个，pivotx,pivotY的值就应该是0-1的浮点数，这里分别对应xml中的%（自身）和%p（父布局）
TranslateAnimation有2种构造方法，和ScaleAnimation类似
效果如下：
效果如下：
RELATIVE_TO_PARENT
效果如下：
RotateAnimation有3种构造方法
顺时针720度
效果如下：
逆时针720度
效果如下：
效果如下：
再来RELATIVE_TO_PARENT
效果如下：
这是什么鬼？？？怎么跑到屏幕外面去了？
原来设置为RELATIVE_TO_PARENT时，旋转中心x方向应该为该空间离左边的边距+父布局宽度/2，y方向同理，而此时，我们布局中红色的Textview为居中状态，所以旋转中心为屏幕右下角。让我们来看个例子
修改布局如下：
效果如下：
这时，我们看到旋转中心x方向为离左边100dp处
AlphaAnimation只有1种构造方法
其中fromAlpha为动画开始的透明度；toAlpha为动画结束的透明度
效果如下：
效果如下：
AnimationSet是一个动画的集合，可以按照添加的顺序播放动画，让我们来看个例子，通过组合动画，实现旋转渐入动画
效果如下：
到这里，补间动画就介绍完了
参考资料： 自定义控件三部曲之动画篇
硬件抽象层模块编写规范
硬件抽象层最终都会生成.so文件，放到系统对应的目录中。在系统使用的时候，系统会去对应目录下加载so文件，实现硬件抽象层的功能。因此硬件抽象层的加载过程就是我们使用so的一个接口。先了解加载过程从源头了解抽象层模块儿的编写规范。
1、硬件抽象层加载过程
系统在加载so的过程中，会去两个目录下查找对应id的so文件。这两个目录分别是/system/lib/hw和/vendor/lib/hw。
so文件的名字分为两个部分例如id.prop.so，第一部分是模块id。第二部分是系统prop的值，获取顺序为“ro.hardware”、“ro.producat.board”、“ro.board.platform”、“ro.arch”，如果prop都找不到的话，就用default。（不是找不到prop的值，是找不到prop值对应的so文件）。
负责加载硬件抽象层模块的函数是hw_get_module，所在的文件是/hardware/libhardware/hardware.c如下：
/** Base path of the hal modules */
#if defined(__LP64__)
#define HAL_LIBRARY_PATH1 "/system/lib64/hw"
#define HAL_LIBRARY_PATH2 "/vendor/lib64/hw"
#else
#define HAL_LIBRARY_PATH1 "/system/lib/hw"
#define HAL_LIBRARY_PATH2 "/vendor/lib/hw"
#endif
/**
* There are a set of variant filename for modules. The form of the filename
* is ".variant.so" so for the led module the Dream variants
* of base "ro.product.board", "ro.board.platform" and "ro.arch" would be:
*
* led.trout.so
* led.msm7k.so
* led.ARMV6.so
* led.default.so
*/
static const char *variant_keys[] = {
"ro.hardware", /* This goes first so that it can pick up a different
file on the emulator. */
"ro.product.board",
"ro.board.platform",
"ro.arch"
};
static const int HAL_VARIANT_KEYS_COUNT =
(sizeof(variant_keys)/sizeof(variant_keys[0]));
/**
* Load the file defined by the variant and if successful
* return the dlopen handle and the hmi.
* @return 0 = success, !0 = failure.
*/
static int load(const char *id,
const char *path,
const struct hw_module_t **pHmi)
{
int status;
void *handle;
struct hw_module_t *hmi;
/*
* load the symbols resolving undefined symbols before
* dlopen returns. Since RTLD_GLOBAL is not or'd in with
* RTLD_NOW the external symbols will not be global
*/
handle = dlopen(path, RTLD_NOW);
if (handle == NULL) {
char const *err_str = dlerror();
ALOGE("load: module=%s\n%s", path, err_str?err_str:"unknown");
status = -EINVAL;
goto done;
}
/* Get the address of the struct hal_module_info. */
const char *sym = HAL_MODULE_INFO_SYM_AS_STR;
hmi = (struct hw_module_t *)dlsym(handle, sym);
if (hmi == NULL) {
ALOGE("load: couldn't find symbol %s", sym);
status = -EINVAL;
goto done;
}
/* Check that the id matches */
if (strcmp(id, hmi-id) != 0) {
ALOGE("load: id=%s != hmi-id=%s", id, hmi-id);
status = -EINVAL;
goto done;
}
hmi-dso = handle;
/* success */
status = 0;
done:
if (status != 0) {
hmi = NULL;
if (handle != NULL) {
dlclose(handle);
handle = NULL;
}
} else {
ALOGV("loaded HAL id=%s path=%s hmi=%p handle=%p",
id, path, *pHmi, handle);
}
*pHmi = hmi;
return status;
}
/*
* Check if a HAL with given name and subname exists, if so return 0, otherwise
* otherwise return negative. On success path will contain the path to the HAL.
*/
static int hw_module_exists(char *path, size_t path_len, const char *name,
const char *subname)
{
snprintf(path, path_len, "%s/%s.%s.so",
HAL_LIBRARY_PATH2, name, subname);
if (access(path, R_OK) == 0)
return 0;
snprintf(path, path_len, "%s/%s.%s.so",
HAL_LIBRARY_PATH1, name, subname);
if (access(path, R_OK) == 0)
return 0;
return -ENOENT;
}
int hw_get_module_by_class(const char *class_id, const char *inst,
const struct hw_module_t **module)
{
int i;
char prop[PATH_MAX];
char path[PATH_MAX];
char name[PATH_MAX];
char prop_name[PATH_MAX];
if (inst)
snprintf(name, PATH_MAX, "%s.%s", class_id, inst);
else
strlcpy(name, class_id, PATH_MAX);
/*
* Here we rely on the fact that calling dlopen multiple times on
* the same .so will simply increment a refcount (and not load
* a new copy of the library).
* We also assume that dlopen() is thread-safe.
*/
/* First try a property specific to the class and possibly instance */
snprintf(prop_name, sizeof(prop_name), "ro.hardware.%s", name);
if (property_get(prop_name, prop, NULL) 0) {
if (hw_module_exists(path, sizeof(path), name, prop) == 0) {
goto found;
}
}
/* Loop through the configuration variants looking for a module */
for (i=0 ; iHAL_VARIANT_KEYS_COUNT; i++) {
if (property_get(variant_keys[i], prop, NULL) == 0) {
continue;
}
if (hw_module_exists(path, sizeof(path), name, prop) == 0) {
goto found;
}
}
/* Nothing found, try the default */
if (hw_module_exists(path, sizeof(path), name, "default") == 0) {
goto found;
}
return -ENOENT;
found:
/* load the module, if this fails, we're doomed, and we should not try
* to load a different variant. */
return load(class_id, path, module);
}
int hw_get_module(const char *id, const struct hw_module_t **module)
{
return hw_get_module_by_class(id, NULL, module);
}
找到so文件之后，调用方法load方法去加载对应的so文件，并返回hw_module_t结构体。load方法源码在上面程序中。
load方法首先调用dlopen加载对应的so文件到内存中。然后用dlsym方法找到变量HAL_MODULE_INFO_SYM_AS_STR符号对应的地址，这个地址也就是一个hw_module_t结构体，然后从这个结构体中拿出id比对load方法出入的id是否一致，如果是的话表示打开成功。加载过程完成。
HAL_MODULE_INFO_SYM_AS_STR这个符号值为HMI，也就是必须要保证这个符号之后是一个hw_module_t。接下来的规范中有这个要求。
到此，模块加载完成
2、硬件抽象层模块编写规范
硬件抽象层有两个结构体，一个是hw_module_t和hw_device_t，定义在hardware.h中。
首先说一下hw_module_t的编写规范。
1、必须要有一个“自定义硬件抽象层结构体”，且结构体第一个变量类型要为hw_module_t。
2、必须存在一个HARDWARE_MODULE_INFO_TAG的符号，且指向“自定义硬件抽象层结构体”。在加载的时候根据这个符号找到地址，并把地址的转变为hw_module_t，这也是为什么第一条中hw_module_t必须要在第一个的原因。
3、hw_module_t的tag必须为HARDWARE_MODULE_TAG
4、结构体中要有一个方法列表，其中要有一个open方法。用open方法获得hw_device_t
接下来说一下hw_device_t的编写规范
1、必须要有一个“自定义硬件设备结构体”，且结构体第一个变量类型要为hw_device_t。
2、hw_device_t的tag必须为HARDWARE_DEVICE_TAG
3、要有一个close函数指针，来关闭设备
按照上面规范编写的硬件抽象层就可以由系统加载并正确获取到device。具体的应用层逻辑在device中实现。
android:fromYDelta="48" 从起始Y坐标,偏移48个坐标
android:fromYDelta="80%p" 从80%p的位置移动
80%p---父组件的80%
Android自定义键盘的使用
1、新建一个xml文件夹放在res目录下面，然后新建xml文件:money_keyboard.xml
2、然后在XML文件中添加按钮布局，这个布局就是键盘的样子了
3 属性介绍:
Keyboard：
存储键盘以及按键相关信息。
android:horizontalGap
按键之间默认的水平间距。
android:verticalGap
按键之间默认的垂直间距。
android:keyHeight
按键的默认高度，以像素或显示高度的百分比表示。
android:keyWidth:
按键的默认宽度，以像素或显示宽度的百分比表示。
Row：
为包含按键的容器。
Key:
用于描述键盘中单个键的位置和特性。
android:codes
该键输出的unicode值。
android:codes 官网介绍是说这个是该键的unicode 值或者逗号分隔值，当然我们也可以设置成我们想要的值，在源码中提供了几个特定的值
对照表:
android:isRepeatable
这个属性如果设置为true，那么当长按该键时就会重复接受到该键上的动作，在 删除键键 和 空格键 上通常设为true。
android:keyLabel
显示在按键上的文字。
android:keyIcon 与 keyLabel
是二选一关系，它会代替文字以图标的形式显示在键上。
android:keyWidth="33.33333%p"
每一个按钮的宽度,可以设置百分比
android:keyHeight="10%p"
每一个按钮高度，可以设置百分比
KeyboardView是一个渲染虚拟键盘的View。 它处理键的渲染和检测按键和触摸动作。
显然我们需要KeyboardView来对Keyboard里的数据进行渲染并呈现给我们以及相关的点击事件做处理。 1）//设置keyboard与KeyboardView相关联的方法。
public void setKeyboard(Keyboard keyboard)
2）//设置虚拟键盘事件的监听，此方法必须设置，不然会报错。
public void setOnKeyboardActionListener(OnKeyboardActionListener listener) 步骤上呢，做完第一步的关联，并设置第二步的事件，调用KeyboardView.setVisible(true);键盘就可以显示出来了， 是不是很简单。不过到这里还没有结束哦，接下来我们为了使用上的便利要进行相应的封装。 封装 这里我们通过继承EditText来对Keyboard与KeyboardView进行封装。
attr.xml文件，这里我们需要通过一个xml类型的自定义属性引入我们的键盘描述文件。
1、新建一个类，我取名叫KeyUtils然后在里面新建三个属性。KeyBoard用处可大了，他才是本体，可以通过设置他来切换键盘。
2、构造函数，初始下三个参数。
3、先说下预览图吧，就是效果图上的预览图，需要预览图的话的将setPreviewEnabled设置为true，不过还得在布局文件中的android.inputmethodservice.KeyboardView标签对立面设置预览布局。否则，不会有字。至于设置的布局，一个TextView就好了~
onPress: 按下触发。
onRelease：松开触发。
onKey ： 松开触发，在OnRelease之前触发。
swipeLeft : 左滑动，其他同理。哈哈~就这么懒。
onText ：需要在 键盘xml，也就是我此时的number.xml里面中key标签对里添加一个
