androidload

❶ 【Android】Android中的类加载

前文： 【java】ClassLoader与双亲委派机制

Android中的类加载器有三种， DexClassLoader 、 PathClassLoader 、 BootClassLoader 。
其中 BootClassLoader 是系统启动时预加载常用类的，一般使用不到。 DexClassLoader 、 PathClassLoader 都是继承自 BaseDexClassLoader 。
但 DexClassLoader 和 PathClassLoader 并没有重写 BaseDexClassLoader 中的任何方法，所以源码只需要看 BaseDexClassLoader 即可。

由于Android SDK并没有包含 BaseDexClassLoader ，所以需要到源码查询网站查询源码，如下：

复制这个java文件到对应源码文件夹下就可以在Android Studio中查看了。

通过调试可以看到，Android中普通类的加载器其实是 PathClassLoader 。追踪 PathClassLoader.findClass 方法，即可获取Android的类加载过程：

PathClassLoader.findClass -- 继承自 --> BaseDexClassLoader.findClass()
-> BaseDexClassLoader.pathList.findClass()
-> DexPathList.dexElements.foreach { element.findClass() }
-> Element.findClass()
-> Element.dexFile.loadClassBinaryName()
-> DexFile.defineClass()

即类加载过程通过 BaseDexClassLoader.findClass 、 DexPathList.findClass 、 Element.findClass 、 DexFile.loadClassBinaryName ，最终会落到 DexFile.defineClass 方法中，然后就交给native层了。

其中需要注意的是，在 BaseDexClassLoader.findClass 的开头有这么一段：

这段是在Android 10新加入的，据称是为了实现 shared library 功能的，在之前的版本中没有这一段。

在上一节中知道了，类加载的流程如下：
BaseDexClassLoader.findClass() ->
BaseDexClassLoader.pathList.findClass() ->
DexPathList.dexElements.foreach { element.findClass() } ->
Element.findClass() -> ...

看 DexPathList.findClass 方法：

可以发现， DexPathList 加载类的方法是遍历 dexElements 数组依次加载，知道获取到值为止。所以可以通过修改这个数组，把新的dex文件放在数组的前面，使其加载修改后的类，从而实现热修复。

根据以上原理，写下这个工具类，有效性待验证：

❷ android 的native方法，在哪使用System.loadLib()方法

不是loadLib，是

static{
System.loadLibrary("你的库名");
}

这个是在类被加载的时候加载的，也就是你的Test。你说的有些没有使用load，是因为在系统启动的时候so已经被加载了。你可以通过命令行看到系统里面的很多so：

如果so被加载了，你就不需要再使用加载代码，可以直接用native接口

❸ android loaddatawithbaseurl 和loarl的区别

在开发Android平台的互联网应用时，经常会使用到WebView，好处主要有两个，一是可以更改要展现的内容（包括样式），二是可以实现部分功能的跨平台。

Android的WebView组件使用非常简单，可以使用loadUrl()加载一个Url地址，也可以使用loadData()或 loadDataWithBaseURL()加载一段HTML代码片段。loadUrl()的使用大家应该都没有什么问题，但是loadData()和 loadDataWithBaseURL()在使用上的差异可能有些人还不太清楚。
首先，从方法的定义来看：
public void loadData (String data, String mimeType, String encoding)
public void loadDataWithBaseURL (String baseUrl, String data, String mimeType, String encoding, String historyUrl)
loadDataWithBaseURL()比loadData()多两个参数，可以指定HTML代码片段中相关资源的相对根路径，也可以指定历史Url。两个方法的其余三个参数相同。

其次，两个方法加载的HTML代码片段有些不同，loadData()中的html data中不能包含'#', '%', '\', '?'四中特殊字符，这就为我们内嵌css等制造了些许麻烦，因为css中经常用'#', '%'等字符，需要如何处理呢？我们需要用UrlEncoder编码为%23, %25, %27, %3f 。
/**
* Loads the given data into this WebView using a 'data' scheme URL.
* <p>
* Note that JavaScript's same origin policy means that script running in a
* page loaded using this method will be unable to access content loaded
* using any scheme other than 'data', including 'http(s)'. To avoid this
* restriction, use {@link
* #loadDataWithBaseURL(String,String,String,String,String)
* loadDataWithBaseURL()} with an appropriate base URL.
* <p>
* If the value of the encoding parameter is 'base64', then the data must
* be encoded as base64. Otherwise, the data must use ASCII encoding for
* octets inside the range of safe URL characters and use the standard %xx
* hex encoding of URLs for octets outside that range. For example,
* '#', '%', '\', '?' should be replaced by %23, %25, %27, %3f respectively.
* <p>
* The 'data' scheme URL formed by this method uses the default US-ASCII
* charset. If you need need to set a different charset, you should form a
* 'data' scheme URL which explicitly specifies a charset parameter in the
* mediatype portion of the URL and call {@link #loadUrl(String)} instead.
* Note that the charset obtained from the mediatype portion of a data URL
* always overrides that specified in the HTML or XML document itself.
*
* @param data a String of data in the given encoding
* @param mimeType the MIME type of the data, e.g. 'text/html'
* @param encoding the encoding of the data
*/
public void loadData(String data, String mimeType, String encoding) {
checkThread();
mProvider.loadData(data, mimeType, encoding);
}
/**
* Loads the given data into this WebView, using baseUrl as the base URL for
* the content. The base URL is used both to resolve relative URLs and when
* applying JavaScript's same origin policy. The historyUrl is used for the
* history entry.
* <p>
* Note that content specified in this way can access local device files
* (via 'file' scheme URLs) only if baseUrl specifies a scheme other than
* 'http', 'https', 'ftp', 'ftps', 'about' or 'javascript'.
* <p>
* If the base URL uses the data scheme, this method is equivalent to
* calling {@link #loadData(String,String,String) loadData()} and the
* historyUrl is ignored.
*
* @param baseUrl the URL to use as the page's base URL. If null defaults to
* 'about:blank'.
* @param data a String of data in the given encoding
* @param mimeType the MIMEType of the data, e.g. 'text/html'. If null,
* defaults to 'text/html'.
* @param encoding the encoding of the data
* @param historyUrl the URL to use as the history entry. If null defaults
* to 'about:blank'.
*/
public void loadDataWithBaseURL(String baseUrl, String data,
String mimeType, String encoding, String historyUrl) {
checkThread();
mProvider.loadDataWithBaseURL(baseUrl, data, mimeType, encoding, historyUrl);
}

❹ android webview中的loadUrl方法是get请求还是post

get请求，因为查询api可以看到有个postUrl方法。查看源码可以确定

❺ android webview中的loadUrl方法是get请求还是post请求

我写过的一般是get请求 因为一般这个loadUrl就是请求的完整地址 如果其实也很容易看 ，请求的时候接口端给你的接口是拼接了参数 的是get 请求 如果没有拼接参数的话 可以是get也可以是post 这个咨询下你们的写接口的那个人也可以的 ，

❻ android loadjs是同步还是异步

是同步加载的。

❼ android在用System.load()加载so文件时出现已经加载到内存错误，如何解决

这要看你在c++代码里有没有没释放的内存了。毕竟能成功运行一次，说明编译没错误，配置也没错误。看检察一下你的c++代码。

❽ Android类加载机制

Android手写热修复（一）--ClassLoader

我们平时编写的 .java 文件不是可执行文件，需要先编译成 .class 文件才可以被虚拟机执行。所谓类加载是指通过 类加载器 把class文件加载到虚拟机的内存空间，具体来说是方法区。类通常是按需加载，即第一次使用该类时才加载。

首先，Java与Android都是把类加载到虚拟机内存中，然后由虚拟机转换成设备识别的机器码。但是由于二者使用的虚拟机不同，所以在类加载方面也是有所区别的。Java的虚拟机是JVM，Android的虚拟机是dalvik／art(5.0以后虚拟机是art，是对dalvik的一种升级)。 Java虚拟机运行的是class文件，而Android 虚拟机运行的是dex文件。 dex其实是class文件的集合，是对class文件优化的产物，是为了避免出现重复的class。

从上面的讲解中，我们已经知道我们平时写的类是被 类加载器 加载尽虚拟机内存才能运行。下面就通过Framework源码来为大家讲解Android中最主要的5个类加载器。

在Activity做个简单验证：

结果：

可以看出系统类由BootClassLoader加载，apk中的类由PathClassLoader加载，PathClassLoader的父类加载器是BootClassLoader。如果暂时不能理解父类加载器是什么，没关系，后面讲双亲委托机制的时候会理解的。

下面的源码解析基于 Android SDK API28 ，这几个类加载器（除了ClassLoader）没办法直接在AS上查看源码，AS搜索到的是反编译的class的内容，是不可信的，为大家推荐一个在线工具查看， 在线查看Android Framework源码 。

用来加载本地文件系统上的文件或目录，通常是用来加载apk中我们自己写的类，而像 Activity.class 这种系统的类不是由它加载。注意：这里，并不像很多网上文章说的那样只能加载apk，本地的其他目录的文件也是可以的，这一点我会在后面验证说明。

也是被用来加载 jar 、apk、dex，通常用来加载未安装到应用中的文件。注意，它需要一个应用私有的可写的目录来存放优化后的dex文件。千万不要选择外部存储路径，因为这样可能会导致你的应用遭到注入攻击。

关于dex文件优化，可能很多人还是不理解，水平有限，我简单解释一下，

构造器参数解释：

关于optimizedDirectory：
1、这是dex优化后的路径，它必须是一个应用私有的可写的目录否则会存在注入攻击的风险；
2、这个参数在API 26（8.0）之前是有值的，之后的话，这个参数已经没有影响了，因为在调用父构造器的时候这个参数始终为null，也就是说Android 8.0 以后DexClassLoader和PathClassLoader基本一样的来；
3、在加载app的时候，apk内部的dex已经执行过优化了，优化之后放在系统目录/data/dalvik-cache下。

这个构造器的关键是初始化了一个DexPathList对象，这个是后面加载class的关键类。

这个构造方法等关键是通过 makeDexElements() 方法来获取Element数组，这个Element数组非常关键，后面查找class就会用到它，也是热修复的关键点之一。

splitDexPath(dexPath) 方法是把dexPath目录下的所有文件转换成一个File集合，如果是多个文件的话，会用 : 作为分隔符。

makeDexElements()

小结一下，这个方法就是把指定目录下的文件apk／jar／zip／dex按不同的方式封装成Element对象，然后按顺序添加到Element[]数组中。

DexPathList#loadDexFile()

可以看到 DexFile 最终是调用了openDexFile、native方法openDexFileNative去打开Dex文件的，如果outputName为空，则自动生成一个缓存目录，具体来说是 /data/dalvik-cache/[email protected] 。openDexFileNative这个native方法就不具体分析了，主要是对dex文件进行了优化操作，将优化后得odex文件通过mmap映射到内存中。感兴趣的同学可以参考：
《DexClassLoader和PathClassLoader加载Dex流程》

现在在回头看看DexClassLoader与PathClassLoader的区别。DexClassLoader可以指定odex的路径，而PathClassLoader则采用系统默认的缓存路径，在8.0以后没有区别。

ClassLoader是一个抽象类，有3个构造方法，最终调用的还是第一个构造方法，主要功能是保存实现类传入的parent参数，也就是父类加载器。ClassLoader的实现类主要有2个，一个是前面讲过的BaseDexClassLoader，另一个是BootClassLoader。

BootClassLoader是ClassLoader的内部类，而且继承了ClassLoader。

这是加载一个类的入口，流程如下：
1、 先检查这个类是否已经被加载，有的话直接返回Class对象；
2、如果没有加载过，通过父类加载器去加载，可以看出parent是通过递归的方式去加载class的；
3、如果所有的父类加载器都没有加载过，就由当前的类加载器去加载。

通常我们自己写的类是通过当前类加载器调用 findClass 方法去加载的，但是在 ClassLoader 中这是个空方法，具体的实现在它的子类 BaseDexClassLoader 中。

BaseDexClassLoader # findClass

可以看到是通过pathList去查找class的，这个对象其实之前讲过，它是在BaseDexClassLoader 的构造方法中初始化的，它实际上是一个 DexPathList 对象。

DexPathList # findClass()

对Element数组遍历，再通过Element对象的 findClass 方法去查找class，有的话就直接返回这个class，找不到则返回null。 这里可以看出获取Class是通过DexFile来实现的，而各种类加载器操作的是Dex。Android虚拟机加载的dex文件，而不是class文件。

1、加载一个类是通过双亲委托机制来实现的。
2、如果是第一次加载class，那是通过 BaseDexClassLoader 中的findClass方法实现的；接着进入 DexPathList 中的findClass方法，内部通过遍历Element数组，从Element对象中去查找类；Element实际上是对Dex文件的包装，最终还是从dexfile去查找的class。
3、一般app运行主要用到2个类加载器，一个是PathClassLoader：主要用于加载自己写的类；另一个是BootClassLoader：用于加载Framework中的类；
4、热修复和插件化一般是利用DexClassLoader来实现。
5、PathClassLoader和DexClassLoader其实都可以加载apk／jar／dex，区别是 DexClassLoader 可以指定 optimizedDirectory ，也就是 dex2oat 的产物 .odex 存放的位置，而 PathClassLoader 只能使用系统默认位置。但是在8.0 以后二者是没有区别的，只能使用系统默认的位置了。

这张图来源于：
Android虚拟机框架：类加载机制

在类加载流程分析中，我们已经知道，查找class是通过DexPathList来完成的，实际上DexPathList最终还是遍历其Element数组，获取DexFile对象来加载Class文件。 由于数组是有序的，如果2个dex文件中存在相同类名的class，那么类加载器就只会加载数组前面的dex中的class。如果apk中出现了有bug的class，那只要把修复的class打包成dex文件并且放在 DexPathList 中Element数组`的前面，就可以实现bug修复了 。下一篇为大家带来的手写热修复。

Android类加载机制的细枝末节
从JVM到Dalivk再到ART（class,dex,odex,vdex,ELF）
类加载机制系列2——深入理解Android中的类加载器
Android 热修复核心原理，ClassLoader类加载