疯子来过

代码修复主要有三个方案，分别是底层替换方案、类加载方案和Instant Run方案。3.1 类加载方案类加载方案基于Dex分包方案，什么是Dex分包方案呢？这个得先从65536限制和LinearAlloc限制说起。 65536限制 随着应用功能越来越复杂，代码量不断地增大，引入的库也越来越多，可能会在编译时提示如下异常：com.android.dex.DexIndexOverflowException:methodIDnotin[0, 0xffff]: 65536 这说明应用中引用的方法数超过了最大数65536个。产生这一问题的原因就是系统的65536限制，65536限制的主要原因是DVM Bytecode的限制，DVM指令集的方法调用指令invoke-kind索引为16bits，最多能引用 65535个方法。 LinearAlloc限制 在安装时可能会提示INSTALL_FAILED_DEXOPT。产生的原因就是LinearAlloc限制，DVM中的LinearAlloc是一个固定的缓存区，当方法数过多超出了缓存区的大小时会报错。为了解决65536限制和LinearAlloc限制，从而产生了Dex分包方案。Dex分包方案主要做的是在打包时将应用代码分成多个Dex，将应用启动时必须用到的类和这些类的直接引用类放到主Dex中，其他代码放到次Dex中。当应用启动时先加载主Dex，等到应用启动后再动态的加载次Dex，从而缓解了主Dex的65536限制和LinearAlloc限制。Dex分包方案主要有两种，分别是Google官方方案、Dex自动拆包和动态加载方案。因为Dex分包方案不是本章的重点，这里就不再过多的介绍，我们接着来学习类加载方案。 在Android解析ClassLoader（二）Android中的ClassLoader中讲到了ClassLoader的加载过程，其中一个环节就是调用DexPathList的findClass的方法，如下所示。 libcore/dalvik/src/main/java/dalvik/system/DexPathList.java publicClass findClass(String name, List suppressed) { for(Element element : dexElements) {//1 Class clazz = element.findClass(name, definingContext,...

这个需要配合说起鸿洋，其实他在慕课网讲过一个这个断点下载，断点上传在app端数据的有记录，其实断点下载是服务，断点上传我认为app这边的做，一些记录

1.通过第三方软件加载。 2.通过压缩工具压缩。 3.加载缓存方式。

HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全，为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。 1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。 2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。 3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。 4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。 最后一点在Android 9.0 如果用http进行传输，需要在application节点下设置 android:usesCleartextTraffic="true"

存储权限 定位权限 无线扫描权限 设备标识符

没有感觉有多大区别，或者我没有那么熟悉

首先我们可以对图片进行二次采样，从本质上减少图片的内存占用。就是将大图片缩小之后放入到内存中，以实现减小内存的目的 2.其次就是采用三层缓存架构，提高图片的访问速度。三层缓存架构是内存-文件-网络。 　　　　内存是访问速度最快的部分但是分配的空间有限，所以不可能占用太多。其中内存缓存可以采用LRU算法（最近最少使用算法），来确定要删除内存中的那些图片，保存那　　　些图片。 　　　　文件就是将图片保存到本地，可以使SD卡中，也可以是手机内部存储中。 　　　　网络就是访问网络下载图片，进行图片的加载。 3.常见的png，JPG，webp等格式的图片在设置到UI上之前需要经过解码过程，而图片采用不同的码率，也会造成对内存的占用不同。 4.最后一点，也是图片优化最重要的一点。重用Bitmap. 5.不使用bitmap要记得实时回收，减小内存的开销

手机直接debug本身没有问题，但是打包的时候会出现Unable to execute dex: method ID not in[0, 0xffff]: 65536)这种问题导致打包失败，这是单个dex文件方法数超过64k导致的，基本上引入过多的依赖都会出现这个问题，解决方法： 1.导入依赖 'com.android.support:multidex:1.0.1' 2.defaultConfig增加这个设置 multiDexEnabled true 3.android下面增加这个设置 dexOptions { incremental true javaMaxHeapSize "4g" } 以上都是在app的buildl.gradle中设置的，编译。 4.打开自定义的Application，继承MultiDexApplication，并重写attachBaseContext方法 @Override protected void attachBaseContext(Context base)...

这是美图webview优化我感觉这是个方法 https://mp.weixin.qq.com/s/-WceVvEKp8bKtIJQsD3Srw

不就是四种们，楼下继续分别是哪几种，优缺点