最近在学习张绍文老师的《Android 开发高手课》。课后作业可不是一般的难，最近几天抽空练习了一下，结合老师给的步骤与完成的同学经验，完成了前五课的内容（截止目前还有剩余五课内容，后面在练习吧！）。
整理总结了一下，分享出来。希望可以帮到一同学习的同学（当然希望大家尽量靠自己解决问题）。
Chapter01
例子里集成了
Breakpad来获取发生native crash时候的系统信息和线程堆栈信息。通过一个简单的Native崩溃捕获过程，完成minidump文件的生成和解析，在实践中加深对Breakpad工作机制的认识。
直接运行项目，按照README.md的步骤操作就行。
中间有个问题，老师提供的minidump_stackwalker 工具在macOS 10.14以上无法成功执行，因为没有libstdc++.6.dylib库，所以我就下载Breakpad源码重新编译了一遍。
使用 minidump_stackwalker 工具来根据minidump 文件生成堆栈跟踪log，得到的crashLog.txt文件如下：
Operating system: Android
0.0.0 Linux 4.9.112-perf-gb92eddd #1 SMP PREEMPT Tue Jan 1 21:35:06 CST 2019 aarch64
CPU: arm64 // 注意点1
8 CPUs
GPU: UNKNOWN
Crash reason: SIGSEGV /SEGV_MAPERR
Crash address: 0x0
Process uptime: not available
Thread 0 (crashed)
0 libcrash-lib.so + 0x600 // 注意点2
x0 = 0x00000078e0ce8460 x1 = 0x0000007fd4000314
x2 = 0x0000007fd40003b0 x3 = 0x00000078e0237134
x4 = 0x0000007fd40005d0 x5 = 0x00000078dca14200
x6 = 0x0000007fd4000160 x7 = 0x00000078c8987e18
x8 = 0x0000000000000000 x9 = 0x0000000000000001
x10 = 0x0000000000430000 x11 = 0x00000078e05ef688
x12 = 0x00000079664ab050 x13 = 0x0ad046ab5a65bfdf
x14 = 0x000000796650c000 x15 = 0xffffffffffffffff
x16 = 0x00000078c83defe8 x17 = 0x00000078c83ce5ec
x18 = 0x0000000000000001 x19 = 0x00000078e0c14c00
x20 = 0x0000000000000000 x21 = 0x00000078e0c14c00
x22 = 0x0000007fd40005e0 x23 = 0x00000078c89fa661
x24 = 0x0000000000000004 x25 = 0x00000079666cc5e0
x26 = 0x00000078e0c14ca0 x27 = 0x0000000000000001
x28 = 0x0000007fd4000310 fp = 0x0000007fd40002e0
lr = 0x00000078c83ce624 sp = 0x0000007fd40002c0
pc = 0x00000078c83ce600
Found by: given as instruction pointer in context
1 libcrash-lib.so + 0x620
fp = 0x0000007fd4000310 lr = 0x00000078e051c7e4
sp = 0x0000007fd40002f0 pc = 0x00000078c83ce624
Found by: previous frame's frame pointer
2 libart.so + 0x55f7e0
fp = 0x130c0cf800000001 lr = 0x00000079666cc5e0
sp = 0x0000007fd4000320 pc = 0x00000078e051c7e4
Found by: previous frame's frame pointer
......
下来是符号解析，可以使用 ndk 中提供的addr2line来根据地址进行一个符号反解的过程,该工具在 $NDK_HOME/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-addr2line
注意：此处要注意一下平台，如果是 arm64位的 so，解析是需要使用 aarch64-linux-android-4.9下的工具链。
因为我的是arm64位的 so。所以使用aarch64-linux-android-4.9，libcrash-lib.so在app/build/intermediates/cmake/debug/obj/arm64-v8a下，0x600为错误位置符号。
aarch64-linux-android-addr2line -f -C -e libcrash-lib.so 0x600
输出结果如下
Crash()
/Users/weilu/Downloads/Chapter01-master/sample/.externalNativeBuild/cmake/debug/arm64-v8a/../../../../src/main/cpp/crash.cpp:10
可以看到输出结果与下图错误位置一致（第十行）。
最后，我将编译的minidump_stackwalker文件，以及上述用到dmp，libcrash-lib.so，crashLog.txt文件上传到了csdn，有兴趣的下载尝试一下。
Chapter02
该例子主要演示了如何通过关闭
FinalizerWatchdogDaemon来减少TimeoutException的触发
在我的上一篇博客：安卓开发中遇到的奇奇怪怪的问题（三）中有说明，就不重复赘述了。
Chapter03
项目使用了
inline hook来拦截内存对象分配时候的RecordAllocation函数，通过拦截该接口可以快速获取到当时分配对象的类名和分配的内存大小。
在初始化的时候我们设置了一个分配对象数量的最大值，如果从 start 开始对象分配数量超过最大值就会触发内存dump，然后清空alloc对象列表，重新计算。该功能和Android Studio里的Allocation Tracker类似，只不过可以在代码级别更细粒度的进行控制。可以精确到方法级别。
项目直接跑起来后，点击开始记录，然后点击5次生成1000对象按钮。生成对象代码如下：
for (int i = 0; i < 1000; i++) {
Message msg = new Message();
msg.what = i;
}
因为代码从点击开始记录开始，触发到5000的数据就 dump 到文件中，点击5次后就会在sdcard/crashDump下生成一个时间戳命名的文件。项目根目录下调用命令：
java -jar tools/DumpPrinter-1.0.jar dump文件路径 > dump_log.txt
然后就可以在 dump_log.txt中看到解析出来的数据：
Found 5000 records:
....
tid=4509 android.graphics.drawable.RippleForeground (112 bytes)
android.graphics.drawable.RippleDrawable.tryRippleEnter (RippleDrawable.java:569)
android.graphics.drawable.RippleDrawable.setRippleActive (RippleDrawable.java:276)
android.graphics.drawable.RippleDrawable.onStateChange (RippleDrawable.java:266)
android.graphics.drawable.Drawable.setState (Drawable.java:778)
android.view.View.drawableStateChanged (View.java:21137)
android.widget.TextView.drawableStateChanged (TextView.java:5289)
android.support.v7.widget.AppCompatButton.drawableStateChanged (AppCompatButton.java:155)
android.view.View.refreshDrawableState (View.java:21214)
android.view.View.setPressed (View.java:10583)
android.view.View.setPressed (View.java:10561)
android.view.View.onTouchEvent (View.java:13865)
android.widget.TextView.onTouchEvent (TextView.java:10070)
android.view.View.dispatchTouchEvent (View.java:12533)
android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:3032)
android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:2662)
android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:3032)
tid=4515 int[] (104 bytes)
tid=4509 android.os.BaseLooper$MessageMonitorInfo (88 bytes)
android.os.Message.<init> (Message.java:123)
com.dodola.alloctrack.MainActivity$4.onClick (MainActivity.java:70)
android.view.View.performClick (View.java:6614)
android.view.View.performClickInternal (View.java:6591)
android.view.View.access$3100 (View.java:786)
android.view.View$PerformClick.run (View.java:25948)
android.os.Handler.handleCallback (Handler.java:873)
android.os.Handler.dispatchMessage (Handler.java:99)
android.os.Looper.loop (Looper.java:201)
android.app.ActivityThread.main (ActivityThread.java:6806)
java.lang.reflect.Method.invoke (Native method)
com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:547)
com.android.internal.os.ZygoteInit.main (ZygoteInit.java:873)
......
我们用Android Profiler查找一个Message对象对比一下，一模一样：
简单看一下HOOK代码：
void hookFunc() {
LOGI("start hookFunc");
void *handle = ndk_dlopen("libart.so", RTLD_LAZY | RTLD_GLOBAL);
if (!handle) {
LOGE("libart.so open fail");
return;
}
void *hookRecordAllocation26 = ndk_dlsym(handle,
"_ZN3art2gc20AllocRecordObjectMap16RecordAllocationEPNS_6ThreadEPNS_6ObjPtrINS_6mirror6ObjectEEEj");
void *hookRecordAllocation24 = ndk_dlsym(handle,
"_ZN3art2gc20AllocRecordObjectMap16RecordAllocationEPNS_6ThreadEPPNS_6mirror6ObjectEj");
void *hookRecordAllocation23 = ndk_dlsym(handle,
"_ZN3art3Dbg16RecordAllocationEPNS_6ThreadEPNS_6mirror5ClassEj");
void *hookRecordAllocation22 = ndk_dlsym(handle,
"_ZN3art3Dbg16RecordAllocationEPNS_6mirror5ClassEj");
if (hookRecordAllocation26 != nullptr) {
LOGI("Finish get symbol26");
MSHookFunction(hookRecordAllocation26, (void *) &newArtRecordAllocation26,
(void **) &oldArtRecordAllocation26);
} else if (hookRecordAllocation24 != nullptr) {
LOGI("Finish get symbol24");
MSHookFunction(hookRecordAllocation26, (void *) &newArtRecordAllocation26,
(void **) &oldArtRecordAllocation26);
} else if (hookRecordAllocation23 != NULL) {
LOGI("Finish get symbol23");
MSHookFunction(hookRecordAllocation23, (void *) &newArtRecordAllocation23,
(void **) &oldArtRecordAllocation23);
} else {
LOGI("Finish get symbol22");
if (hookRecordAllocation22 == NULL) {
LOGI("error find hookRecordAllocation22");
return;
} else {
MSHookFunction(hookRecordAllocation22, (void *) &newArtRecordAllocation22,
(void **) &oldArtRecordAllocation22);
}
}
dlclose(handle);
}
使用了 inline hook 方案 Substrate来拦截内存对象分配时候libart.so的 RecordAllocation函数。首先如果我们要 hook 一个函数，需要知道这个函数的地址。我们也看到了代码中这个地址判断了四种不同系统。这里有一个网页版的解析工具可以快速获取。下面以8.0为例。
我在8.0的源码中找到了对应的方法：
7.0方法就明显不同：
我也同时参看了9.0的代码，发现没有变化，所以我的测试机是9.0的也没有问题。
Hook新内存对象分配处理代码：
static bool newArtRecordAllocationDoing24(Class *type, size_t byte_count) {
allocObjectCount++;
//根据 class 获取类名
char *typeName = GetDescriptor(type, &a);
//达到 max
if (allocObjectCount > setAllocRecordMax) {
CMyLock lock(g_Lock);//此处需要 loc 因为对象分配的时候不知道在哪个线程，不 lock 会导致重复 dump
allocObjectCount = 0;
// dump alloc 里的对象转换成 byte 数据
jbyteArray allocData = getARTAllocationData();
// 将alloc数据写入文件
SaveAllocationData saveData{allocData};
saveARTAllocationData(saveData);
resetARTAllocRecord();
LOGI("===========CLEAR ALLOC MAPS=============");
lock.Unlock();
}
return true;
}
Chapter04
通过分析内存文件hprof快速判断内存中是否存在重复的图片，并且将这些重复图片的PNG、堆栈等信息输出。
1.首先是获取我们需要分析的hprof文件，我们加载两张相同的图片：
Bitmap bitmap1 = BitmapFactory.decodeResource(getResources(), R.mipmap.test);
Bitmap bitmap2 = BitmapFactory.decodeResource(getResources(), R.mipmap.test);
imageView1.setImageBitmap(bitmap1);
imageView2.setImageBitmap(bitmap2);
生成hprof文件
// 手动触发GC
Runtime.getRuntime().gc();
System.runFinalization();
Debug.dumpHprofData(file.getAbsolutePath());
2.下来就是利用haha库进行文件分析的核心代码：
// 打开hprof文件
final HeapSnapshot heapSnapshot = new HeapSnapshot(hprofFile);
// 获得snapshot
final Snapshot snapshot = heapSnapshot.getSnapshot();
// 获得Bitmap Class
final ClassObj bitmapClass = snapshot.findClass("android.graphics.Bitmap");
// 获得heap, 只需要分析app和default heap即可
Collection<Heap> heaps = snapshot.getHeaps();
for (Heap heap : heaps) {
// 只需要分析app和default heap即可
if (!heap.getName().equals("app") && !heap.getName().equals("default")) {
continue;
}
for (ClassObj clazz : bitmapClasses) {
//从heap中获得所有的Bitmap实例
List<Instance> bitmapInstances = clazz.getHeapInstances(heap.getId());
//从Bitmap实例中获得buffer数组,宽高信息等。
ArrayInstance buffer = HahaHelper.fieldValue(((ClassInstance) bitmapInstance).getValues(), "mBuffer");
int bitmapHeight = fieldValue(bitmapInstance, "mHeight");
int bitmapWidth = fieldValue(bitmapInstance, "mWidth");
// 引用链信息
while (bitmapInstance.getNextInstanceToGcRoot() != null) {
print(instance.getNextInstanceToGcRoot());
instance = instance.getNextInstanceToGcRoot();
}
// 根据hashcode来进行重复判断
}
}
最终的输出结果：
我们用Studio打开hprof文件对比一下：
可以看到信息是一摸一样的。对于更优处理引用链的信息，可以参看的leakcanary源码的实现。
我已经将上面的代码打成jar包，可以直接调用：
//调用方法：
java -jar tools/DuplicatedBitmapAnalyzer-1.0.jar hprof文件路径
详细的代码我提交到了Github，供大家参考。
Chapter05
尝试模仿ProcessCpuTracker.java拿到一段时间内各个线程的耗时占比
usage: CPU usage 5000ms(from 23:23:33.000 to 23:23:38.000):
System TOTAL: 2.1% user + 16% kernel + 9.2% iowait + 0.2% irq + 0.1% softirq + 72% idle
CPU Core: 8
Load Average: 8.74 / 7.74 / 7.36
Process:com.sample.app
50% 23468/com.sample.app(S): 11% user + 38% kernel faults:4965
Threads:
43% 23493/singleThread(R): 6.5% user + 36% kernel faults：3094
3.2% 23485/RenderThread(S): 2.1% user + 1% kernel faults：329
0.3% 23468/.sample.app(S): 0.3% user + 0% kernel faults：6
0.3% 23479/HeapTaskDaemon(S): 0.3% user + 0% kernel faults：982
...
因为了解linux不多，所以看这个有点懵逼。好在课代表孙鹏飞同学解答了相关问题，看懂了上面信息。同时学习到了一些linux知识。
private void testIO() {
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
File f = new File(getFilesDir(), "aee.txt");
FileOutputStream fos = new FileOutputStream(f);
byte[] data = new byte[1024 * 4 * 3000];// 此处分配一个 12mb 大小的 byte 数组
for (int i = 0; i < 30; i++) {// 由于 IO cache 机制的原因所以此处写入多次 cache，触发 dirty writeback 到磁盘中
Arrays.fill(data, (byte) i);// 当执行到此处的时候产生 minor fault，并且产生 User cpu useage
fos.write(data);
}
fos.flush();
fos.close();
}
});
thread.setName("SingleThread");
thread.start();
}
上述代码就是导致的问题罪魁祸首，这种密集io操作集中在SingleThread线程中处理，导致发生了3094次faults，36% kernel。完全没有很好利用到8核CPU。
最后，通过检测CPU的使用率，可以更好的避免卡顿现象，防止ANR的发生。
前前后后用了两三天的时间，远远没有当初想的顺利，感觉身体被掏空。中间爬了不少坑，虽然没有太深入实现代码，但是中间的体验过程也是收获不小。总不能因为难就放弃了，先做到力所能及的部分，让自己动起来！