捕获与解析Android NativeCrash

目录
  • 一、NE 简介
    • 1.1、so 组成
    • 1.2、查看 so 状态
    • 1.3、获取 strip 和未被 strip 的 so
  • 二、NE 捕获与解析
    • 2.1、logcat捕获
    • 2.2、通过DropBox日志解析--适用于系统应用
    • 2.3、通过BreakPad捕获解析--适用于所有应用
      • 2.3.1、BreakPad的实现功能
      • 2.3.2、BreakPad的捕获原理
      • 2.3.3、解析dump文件
      • 2.3.4、获取崩溃堆栈
  • 三、so符号表的提取
    • 3.1、提取 so 的符号表
    • 3.2、符号表分析
      • 3.2.1、直接分析
      • 3.2.2、工具解析
      • 3.2.3、偏移位置简析
  • 四、总结

一、NE 简介

NE全称 NativeException,就是C或者C++运行过程中产生的错误,NE不同于普通的 Java 错误,普通的logcat无法直接还原成可阅读的堆栈,一般没有源码也无法调试。

所以日常应用层的工程师,即使我们内部有云诊断的日志,一般也会忽略NE的错误,那么遇到这些问题,作为应用层、对C++不甚了解的工程师能否解决还原堆栈,能否快速定位或者解决NE的问题呢?

下面将着重介绍:

1.1、so 组成

我们先了解一下 so 的组成,一个完整的 so 由C代码加一些 debug 信息组成,这些debug信息会记录 so 中所有方法的对照表,就是方法名和其偏移地址的对应表,也叫做符号表,这种 so 也叫做未 strip 的,通常体积会比较大。

通常release的 so 都是需要经过一个strip操作的,这样strip之后的 so 中的debug信息会被剥离,整个 so 的体积也会缩小。

如下图所示:

如下可以看到strip之前和之后的大小对比。

如果对 NE 或者 so 不了解的,可以简单将这个debug信息理解为Java代码混淆中的mapping文件,只有拥有这个mapping文件才能进行堆栈分析。

如果堆栈信息丢了,基本上堆栈无法还原,问题也无法解决。

所以,这些debug信息尤为重要,是我们分析NE问题的关键信息,那么我们在编译 so 时候务必保留一份未被strip的so 或者剥离后的符号表信息,以供后面问题分析,并且每次编译的so 都需要保存,一旦产生代码修改重新编译,那么修改前后的符号表信息会无法对应,也无法进行分析。

1.2、查看 so 状态

事实上,也可以通过命令行来查看 so 的状态,Mac下使用 file 命令即可,在命令返回值里面可以查看到so的一些基本信息。

如下图所示,stripped代表是没有debug信息的so,with debug_info, not stripped代表携带debug信息的so。

file libbreakpad-core-s.so

libbreakpad-core-s.so: *******, BuildID[sha1]=54ad86d708f4dc0926ad220b098d2a9e71da235a, stripped

file libbreakpad-core.so

libbreakpad-core.so: ******, BuildID[sha1]=54ad86d708f4dc0926ad220b098d2a9e71da235a, with debug_info, not stripped

如果你是 Windows系统的话,那么我劝你装一个 Linux子系统,然后在 Linux执行同样的命令,同样也可以得到该信息。

接下来看下我们如何获取两种状态下的so。

1.3、获取 strip 和未被 strip 的 so

目前Android Studio无论是使用mk或者Cmake编译的方式都会同时输出strip和未strip的so,如下图是Cmake编译so产生的两个对应的so。

strip之前的so路径:build/intermediates/transforms/mergeJniLibs

strip之后的so路径:build/intermediates/transforms/stripDebugSymbol

另外也可以通过Android SDK提供的工具aarch64-linux-android-strip手动进行strip,aarch64-linux-android-strip这个工具位于/Users/njvivo/Library/Android/sdk/ndk/21.3.6528147/toolchains目录下。

这个工具有多种版本,主要针对不同的手机CPU架构,如果不知道手机的CPU架构,可以连接手机使用以下命令查看:

adb shell cat /proc/cpuinfo

Processor   : AArch64 Processor rev 12 (aarch64)

如上图可以看到我的手机CPU用的是aarch64,所以使用aarch64对应的工具aarch64-linux-android-strip,由于NDK提供了很多工具,后续都依照此原则使用即可:

aarch64架构

/Users/njvivo/Library/Android/sdk/ndk/21.3.6528147/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin/aarch64-linux-android-strip

arm架构

/Users/njvivo/Library/Android/sdk/ndk/21.3.6528147/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-android-strip

使用如下命令可以直接将debug的so进行strip

aarch64-linux-android-strip --strip-all libbreakpad-core.so

使用Cmake进行编译的时候,可以增加如下命令,可以直接编译出strip的so

#set(CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE} -s")

#set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -s")

使用mk文件进行编译的时候,可以增加如下命令,也可以直接编译出strip的so

-fvisibility=hidden

二、NE 捕获与解析

NE解析顾名思议就是堆栈解析,当然所有的前提就是需要保存一份带符号表、也就是未被strip的so,如果你只有strip之后的so,那就无能为力了,堆栈基本无法还原了。

一般有以下三种方式可以捕获和还原堆栈。

2.1、logcat捕获

顾名思义,就是通过logcat进行捕获,我们通过Android Studio打开logcat,制造一个NE,只能看到很多类似#00 pc 00000000000161a0的符号,并没有一个可以直接阅读的日志,我们想通过logcat直接输出一份可以直接阅读的log。

可以使用Android/SDK/NDK下面提供的一个工具ndk-stack,它可以直接将NE输出的log解析为可阅读的日志。

ndk-stack一般是位于ndk的工具下面,Mac下的地址为

/Users/XXXX/Library/Android/sdk/ndk/21.3.6528147/ndk-stack

然后在该目录下执行控制台命令,或者在 Android Studio的terminal中执行也可

adb shell logcat | androidsdk绝对路径/ndk-stack -sym so所在目录

如此控制台在应用发生NE的时候便会输出如下日志,由日志可以看出,崩溃对应的so以及对应的方法名,如果有c的源码,那么就很容易定位问题。

promote:~ njvivo$ adb shell logcat | ndk-stack -sym libbreakpad-core.so

********** Crash dump: **********

Build fingerprint: 'vivo/PD1809/PD1809:8.1.0/OPM1.171019.026/compil04252203:user/release-keys'

#00 0x00000000000161a0 /data/app/com.android.necase-lEp0warh8FqicyY1YqGXXA==/lib/arm64/libbreakpad-core.so (Java_com_online_breakpad_BreakpadInit_nUpdateLaunchInfo+16)

#01 0x00000000000090cc /data/app/com.android.necase-lEp0warh8FqicyY1YqGXXA==/oat/arm64/base.odex (offset 0x9000)

Crash dump is completed

其实ndk-stack这个工具原理就是内部集成利用了addr2line来实时解析堆栈并且显示在控制台中。

看到这里有的小伙伴就觉得那这个不是很简单,但是实际的崩溃场景一是不容易复现,二是用户的场景有时候很难模拟,那么线上的NE崩溃又该如何监测和定位呢,有两种方式。

2.2、通过DropBox日志解析--适用于系统应用

这个很简单,DropBox会记录JE,NE,ANR的各种日志,只需要将DropBox下面的日志传上来即可进行分析解决,下面贴上一份日志示例。

解析方案1:

借助上述的ndk-stack工具,可以直接将DropBox下面的日志解析成堆栈,从中可以看出,崩溃在breakpad.cpp第111行的Crash()方法中。

ndk-stack -sym /Users/njvivo/Desktop/NE -dump data_app_native_crash@1605531663898.txt

********** Crash dump: **********

Build fingerprint: 'vivo/PD1809/PD1809:8.1.0/OPM1.171019.026/compil04252203:user/release-keys'

#00 0x00000000000161a0 /data/app/com.android.necase-lEp0warh8FqicyY1YqGXXA==/lib/arm64/libbreakpad-core.so (Java_com_online_breakpad_BreakpadInit_nUpdateLaunchInfo+16)

Crash()

/Users/njvivo/Documents/project/Breakpad/breakpad-build/src/main/cpp/breakpad.cpp:111:8

Java_com_online_breakpad_BreakpadInit_nUpdateLaunchInfo

/Users/njvivo/Documents/project/Breakpad/breakpad-build/src/main/cpp/breakpad.cpp:122:0

#01 0x00000000000090cc /data/app/com.android.necase-lEp0warh8FqicyY1YqGXXA==/oat/arm64/base.odex (offset 0x9000)

Crash dump is completed

解析方案2:

还是利用Android/SDK/NDK提供的工具linux-android-addr2line,这个工具位于/Users/njvivo/Library/Android/sdk/ndk目录下,有两个版本。

aarch64架构

/Users/njvivo/Library/Android/sdk/ndk/21.3.6528147/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin/aarch64-linux-android-addr2line

arm架构

/Users/njvivo/Library/Android/sdk/ndk/21.3.6528147/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-addr2line

命令使用方法如下,结合未被strip的so以及日志里面出现的堆栈符号00000000000161a0,同样可以解析出崩溃地址和方法

aarch64-linux-android-addr2line -f -C -e libbreakpad-core.so 00000000000161a0

Crash()

/Users/njvivo/Documents/project/Breakpad/breakpad-build/src/main/cpp/breakpad.cpp:111

基于以上,看似也很简单,但是有一个致命的问题就是DropBox只有系统应用能访问,非系统应用根本拿不到日志,那么,非系统应用该怎么办呢?

2.3、通过BreakPad捕获解析--适用于所有应用

非系统应用可以通过google提供的开源工具BreakPad进行监测分析,CrashSDK也是采用的此种方式,可以实时监听到NE的发生,并且记录相关的文件, 从而可以将崩溃和相应的应用崩溃时的启动、场景等结合起来上报。

下面简单介绍一下BreakPad的使用方式。

2.3.1、BreakPad的实现功能

BreakPad主要提供两个个功能,NE的监听和回调,生成minidump文件,也就是dmp结尾的文件,另外提供两个工具,符号表工具和堆栈还原工具。

  • 符号表工具:用于从so中提取出debug信息,获取到堆栈对应的符号表。
  • 堆栈还原工具:用于将BreakPad生成的dump文件还原成符号,也就是堆栈偏移值。

这两个工具会在编译BreakPad源码的时候产生。

编译完之后会产生minidump_stackwalk工具,有些同学不想编译的话,Android Studio本身也提供了这个工具。

这个minidump_stackwalk程序在Android Studio的目录下面也存在,可以拿出来直接使用,如果不想编译的话,直接到该目录下面取即可,Mac路径为:

/Applications/Android Studio.app/Contents/bin/lldb/bin/minidump_stackwalk

2.3.2、BreakPad的捕获原理

由上述可以得知,BreakPad在应用发生NE崩溃时,可以将NE对应的minidump文件写入到本地,同时会回调给应用层,应用层可以针对本次崩溃做一些处理,达到捕获统计的作用,后续将minidump文件上传之后结合minidump_stackwalk以及addr2line工具可以还原出实际堆栈,示意图如下:

在应用发生NE时,BreakPad会在手机本地生成一个dump文件,如图所示:

得到了以上文件,我们只能知道应用发生了NE,但是这些文件其实是不可读的,需要解析这些文件。

下面着重讲一下如何分析上面产生的NE:

2.3.3、解析dump文件

1、获取NE崩溃的dump文件,将刚才得到的minidump_stackwalk和dump文件放在同一个目录,也可以不放,填写路径的时候填写绝对路径即可。

然后在该目录下的终端窗口执行以下命令,该命令表示用minidump_stackwalk解析dump文件,解析后的信息输出到当前目录下的crashLog.txt文件。

./minidump_stackwalk xxxxxxxx.dmp >crashLog.txt

2、执行完之后,minidump_stackwalk会将NE的相关信息写到crashLog.txt里面,详细信息如图所示:

3、根据解析出的NE信息,关注图中红框,可以得知,这个崩溃发生的libbreakpad-core.so里面,0x161a0代表崩溃发生在相对根位置偏移161a0的位置

2.3.4、获取崩溃堆栈

1、利用之前提到的addr2line工具,可以根据发生Crash的so文件以及偏移地址(0x161a0)可以得出产生crash的方法、行数和调用堆栈关系。

2、在其根目录对的终端窗口运行以下命令。

arm-linux-androideabi-addr2line -C -f -e ${SOPATH} ${Address}

-C -f           //打印错误行数所在的函数名称

-e                //打印错误地址的对应路径及行数

${SOPATH}         //so库路径

${Address}        //需要转换的堆栈错误信息地址,可以添加多个,但是中间要用空格隔开,例如:0x161a0

3、如下图是真实运行的示例

aarch64-linux-android-addr2line -f -C -e libbreakpad-core.so 0x161a0

Crash()

/Users/njvivo/Documents/project/Breakpad/breakpad-build/src/main/cpp/breakpad.cpp:111

由上图可以知道,该崩溃发生在breakpad.cpp文件的第111行,函数名是Crash(),与真实的文件一致,崩溃代码如下:

void Crash() {
    volatile int *a = (int *) (NULL);
    *a = 1; //此处在代码里是111行
}

extern "C"
JNIEXPORT void JNICALL
Java_com_online_breakpad_BreakpadInit_nUpdateLaunchInfo(JNIEnv *env, jobject instance,
                                                        jstring mLaunchInfoStr_) {

    DO_TRY
    {
        Crash();
        const char *mLaunchInfoStr = env->GetStringUTFChars(mLaunchInfoStr_, 0);
        launch_info = (char *) mLaunchInfoStr;
//        env->ReleaseStringUTFChars(mLaunchInfoStr_, mLaunchInfoStr);
    }
    DO_CATCH("updateLaunchInfo");

}

基于以上,便可以通过应用收集的dump文件解析的NE的详细堆栈信息。

三、so符号表的提取

3.1、提取 so 的符号表

通过以上内容,我们知道,so中包含了一些debug信息,又叫做符号表,那么我们如何将这些debug信息单独剥离出来呢,ndk也给我们提供了相关的工具。

aarch64架构

/Users/njvivo/Library/Android/sdk/ndk/21.3.6528147/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin/aarch64-linux-android-objdump

arm架构

/Users/njvivo/Library/Android/sdk/ndk/21.3.6528147/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-android-objdump

如下是命令运行的方式,通过此命令,可以将so中的debug信息提取到文件中。

promote:~ njvivo$ aarch64-linux-android-objdump -S libbreakpad-core.so > breakpad.asm

3.2、符号表分析

3.2.1、直接分析

如下图所示就是输出的符号表文件,结合上面的log以及下面的符号表文件,我们同样可以分析出堆栈。

如log中所示,已经表明了崩溃地址是161a0,而161a0对应的代码是*a=1,由上面的分析我们已经知道该崩溃是在breakpad.cpp的111行,也就是*a=1的位置,完全符合预期。

backtrace:

#00 pc 00000000000161a0 /data/app/com.android.necase-lEp0warh8FqicyY1YqGXXA==/lib/arm64/libbreakpad-core.so (Java_com_online_breakpad_BreakpadInit_nUpdateLaunchInfo+16)

#01 pc 00000000000090cc /data/app/com.android.necase-lEp0warh8FqicyY1YqGXXA==/oat/arm64/base.odex (offset 0x9000)

3.2.2、工具解析

google提供了一个Python的工具,将符号表和log结合起来可以直接分析出堆栈

执行命令,就可以解析出相关堆栈,该工具可以用于服务端批量进行解析,此处不再详细说明。

python parse_stack.py <asm-file> <logcat-file>

3.2.3、偏移位置简析

上面文章提到了一个偏移位置的概念,笔者对此了解也不多,不过大致有一个概念,C代码有一个根位置的代码的,每行代码相对根代码都有一个偏移位置。

如上图示例log中有一行语句(Java_com_online_breakpad_BreakpadInit_nUpdateLaunchInfo+16),+16就是代表相对nUpdateLaunchInfo方法的位置往后偏移16。

由上图可以看到,nUpdateLaunchInfo方法的位置是16190,偏移16,也就是16190+10(10进制的16转化16进制后为10)=161a0,同日志输出的一样。

四、总结

以上就是本篇文章的所有内容,主要简述了so的一些基础知识,以及Android中NE的崩溃,捕获解析方案,希望通过该文档对涉及到NE相关的小伙伴带来帮助,同时后续CrashSDK也会支持相关NE的解析功能。

以上就是捕获与解析Android NativeCrash的详细内容,更多关于Android NativeCrash的资料请关注我们其它相关文章!

(0)

相关推荐

  • native.js获取手机硬件基本信息实例代码android版

    为大家分享一些android公共方法native.js实现代代码,如获取手机MAC地址,手机内存大小,手机存储空间大小,手机CPU信息等手机硬件基本信息 native.js获取手机MAC地址 /*得到手机MAC地址*/ function getMac() { var mac = "xxx-xxx-xxx-xxx"; if (plus.os.name == "Android") { //WifiManager var Context = plus.android.im

  • Windows下React Native的Android环境部署及布局示例

    搭建基础环境 JDK(必须,不解释) SDK(建议使用Android Studio,集成SDK以及模拟器) genymotion(如果是使用真机或者Android Studio自带的模拟器,可以选择不装) NVM(node版本控制器,需要node4.0以上版本) 以上配置不是必须,可自行选择适合自己的环境,部分安装过程可能会涉及到翻墙,需要配置代理 配置踩坑记录 genymotion 这里选择genymotion模拟器来讲解,也会提一下Android Studio自带的模拟器的一些注意点,使用真

  • Android Native 内存泄漏系统化解决方案

    导读:C++内存泄漏问题的分析.定位一直是Android平台上困扰开发人员的难题.因为地图渲染.导航等核心功能对性能要求很高,高德地图APP中存在大量的C++代码.解决这个问题对于产品质量尤为重要和关键,高德地图技术团队在实践中形成了一套自己的解决方案. 分析和定位内存泄漏问题的核心在于分配函数的统计和栈回溯.如果只知道内存分配点不知道调用栈会使问题变得格外复杂,增加解决成本,因此两者缺一不可. Android中Bionic的malloc_debug模块对内存分配函数的监控及统计是比较完善的,但

  • react-native android状态栏的实现

    react-native 开发App的时候难免会遇到状态栏的,背景颜色和字体颜色与App内容页面,色调适配,间言之就是将状态栏颜色与App颜色一致,使用户界面更加整体. 1.android设备系统元素 导航栏:就是设备顶部的网络.时间.电量等信息栏 ActionBar: 返回按钮以及系统默认的header区域,RN开发中一般不会用到,RN中在navigation中进行定制 导航栏: 设备下方的物理返回.回桌面.选择应用程序等系统导航栏 2.状态栏的呈现形式 默认展示,一直显示手机系统的状态栏 透

  • Android使用google breakpad捕获分析native cash

    Android 开发高手课 课后练习(1) 一.Chapter01 崩溃 https://time.geekbang.org/column/article/70602 https://github.com/AndroidAdvanceWithGeektime/Chapter01 1.遇到native cash时,生成.dmp文件 先检查sdk/ndk环境 在local.properties配置sdk/ndk 打包运行效果 点击CRASH按钮后生成的.dmp文件 2.利用breakpad的mini

  • Android实现H5与Native交互的两种方式

    前言 大家都知道在Android WebView使用中,经常需要H5页面和Native页面进行交互,比如在网页上点击分享按钮,调用本地分享接口进行分享,分享成功后本地调用网页的JavaScript代码展示一条分享成功的消息.下面来看看一起看看两种实现方式是什么? 一.Url拦截的方式 重写ShouldOverrideUrl进行Url拦截,这种方式通过H5和Native协商好的Url格式来表明H5页面想要Native进行的操作,比如拨打电话,播放视频,查看某个用户的信息等操作,每种操作对应一种ur

  • Native.js获取监听开关等操作Android蓝牙设备实例代码

    Native.js开启关闭蓝牙 var main = plus.android.runtimeMainActivity(); var Context = plus.android.importClass("android.content.Context"); var BManager = main.getSystemService(Context.BLUETOOTH_SERVICE); plus.android.importClass(BManager);//引入相关的method函数

  • Android Native库的加载及动态链接的过程

    Native库的装载过程 我们从一个简单的NDK Demo开始分析. public class MainActivity extends AppCompatActivity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); // Example of a call t

  • 捕获与解析Android NativeCrash

    目录 一.NE 简介 1.1.so 组成 1.2.查看 so 状态 1.3.获取 strip 和未被 strip 的 so 二.NE 捕获与解析 2.1.logcat捕获 2.2.通过DropBox日志解析--适用于系统应用 2.3.通过BreakPad捕获解析--适用于所有应用 2.3.1.BreakPad的实现功能 2.3.2.BreakPad的捕获原理 2.3.3.解析dump文件 2.3.4.获取崩溃堆栈 三.so符号表的提取 3.1.提取 so 的符号表 3.2.符号表分析 3.2.1

  • 通过实例解析android Activity启动过程

    注:只是说明启动activity的过程(ActivityThread如何与ActivityManagerService简称AmS进行进程间通信调用全过程),不解析android从zygote(受精卵)到整个系统服务的启动 具体来讲,启动activity的方式有以下几种: 在应用程序中startActivity()或startActivityForResult()方法启动指定activity 在HOME(桌面)程序中单击应用图标,启动新的activity 按"BACK"键结束当前acti

  • 解析Android框架之OkHttp3源码

    OkHttp流程图 OkHttp基本使用 gradle依赖 implementation 'com.squareup.okhttp3:okhttp:3.11.0' implementation 'com.squareup.okio:okio:1.15.0' /** *这里拿get请求来 * 异步的get请求 */ public void okhttpAsyn() { //设置超时的时间 OkHttpClient.Builder builder = new OkHttpClient.Builder

  • 解析Android框架之Volley源码

    Volley简单使用 我这里是以依赖架包的形式 ,大家也可以以gradle的形式进行依赖. 好了,接下来上代码了..... //获取volley的请求对象 RequestQueue requestQueue = Volley.newRequestQueue(getApplicationContext()); StringRequest stringRequest = new StringRequest(StringRequest.Method.GET, "http://www.baidu.com

  • 全面解析Android之ANR日志

    目录 一.概述 二.ANR产生机制 2.1 输入事件超时(5s) 2.2 广播类型超时(前台15s,后台60s) 2.3 服务超时(前台20s,后台200s) 2.4 ContentProvider 类型 三.导致ANR的原因 3.1 应用层导致ANR(耗时操作) 3.2 系统导致ANR 四.分析日志 4.1 CPU 负载 4.2 内存信息 4.3 堆栈消息 五.典型案例分析 5.1 主线程无卡顿,处于正常状态堆栈 5.2 主线程执行耗时操作 5.3 主线程被锁阻塞 5.4 CPU被抢占 5.5

  • 解析Android ANR问题

    一.ANR介绍 ANR 由消息处理机制保证,Android 在系统层实现了一套精密的机制来发现 ANR,核心原理是消息调度和超时处理.ANR 机制主体实现在系统层,所有与 ANR 相关的消息,都会经过系统进程system_server调度,具体是ActivityManagerService服务,然后派发到应用进程完成对消息的实际处理,同时,系统进程设计了不同的超时限制来跟踪消息的处理. 一旦应用程序处理消息不当,超时限制就起作用了,它收集一些系统状态,譬如 CPU/IO 使用情况.进程函数调用栈

  • 全面解析Android系统指纹启动流程

    本章主要整理Android 指纹启动流程,侧重于hal和framework部分. 一.从Android系统启动流程看指纹启动流程 下图图片出处  → 第一阶段 Boot ROM,Android设备上电后,首先会从处理器片上ROM的启动引导代码开始执行,片上ROM会寻找Bootloader代码,并加载到内存.主要就是上电让系统启动. 第二阶段 Bootloader开始执行,首先负责完成硬件的初始化,然后找到Linux内核代码,并加载到内存. 启动过程中,bootloader(默认是bootable

  • 解析Android AIDL的实例与原理

    目录 一.概述 二.创建 .aidl 文件 三.生成 .java 文件 四.传输复杂数据 五.建立 service 六.获取服务 七.分析调用过程 一.概述 简单来说,AIDL 就是定义一个接口,客户端(调用端)通过 bindService 来与远程服务端建立一个连接,在该连接建立时会将返回一个 IBinder 对象,该对象是服务端 Binder 的 BinderProxy.在建立连接时,客户端通过 asInterface 函数将该 BinderProxy 对象包装成本地的 Proxy,并赋值给

  • 实例解析Android中使用Pull解析器解析XML的方法

    1.Pull简介 Pull解析器是Android系统内置的的,Pull解析器与SAX解析器类似,他提供了类似的事件,如开始元素和介绍元素的事件,使用parser.next()可以进入下一个元素并触发相应的事件,然后进行相应的处理,当元素开始解析时,调用perser.nextText()方法就可以获取到下一个Text类型元素的值. 2.pull特点 (1)简单的结构,一个接口,一个另外,一个工厂组成了Pull解析器 (2)简单易用,Pull解析器只有一个重要的方法next(),他被用来检索下一个事

  • 深入解析Android中View创建的全过程

    前言 吸进这几天在看View的尺寸是怎样计算出来的,于是看了整个View被初始化的过程,结合系统源码总结了一下分享出来,方便需要的朋友或者自己以后有需要的时候看看,下面话不多说了,来看看详细的介绍吧. 从布局文件到LayoutParams 首先从Activity的setContentView(int)方法开始,只要设置了R.layout的布局文件,那么界面上就会显示出来对应的内容.所以以这个方法为初发点,然后往后跟踪代码. public void setContentView(@LayoutRe

随机推荐