yline

gif图实际上就是多帧合并的图 参考Fresco内部实现： 1，View层使用一个Drawable，包含bitmap，并依据gif的信息不断的更新并绘制bitmap 2，C层提供api功能，例如：输入gif数据流，提供解析gif信息、更新bitmap等功能

加载机制： 1，缓存机制，先从缓存区搜索 2，全盘负责，当一个类加载器负责加载某个class，则Class所依赖和引用的其他的Class也由它负责，除非显示使用另一个。 3，双亲委派，先让父加载器试图加载，只有当父加载器无法加载时，才尝试从自己的路径加载 加载过程：[2,3,4统一称为连接] 1，加载：获取到Class文件、转化为方法区的数据结构，并创建一个引用对象 2，验证：验证Class文件的合法性 3，准备：分配类变量内存，并设置"初始化值"；(static 为0，static final 为ContentValue值) 4，解析：将符号引用转化为直接引用 5，初始化：将直接引用的类变量执行clinit方法，进行赋值

1，通过URL的schema协议，定位共享的实现类和内容 2，基于系统的IBinder，实现了一个代理模式，使用者拿到代理对象，提供者实现具体的实现对象。使用者的操作最终都是通过提供者实现的 具体的通信过程，就是binder的跨进程通信内容了

1，针对长图和超大图：采用局部加载 + option的配合 2，针对大图：设定option，增大采样率 + 减少单个像素占用的内存 3，针对大量的图：设置cache，内存读取 -> 磁盘读取 -> 网络读取的缓存顺序 4，其它：采用webp的文件格式，占用磁盘大小更小

1，加入基本的混淆规则：优化配置、activity+Fragment等不混淆、序列化的类不混淆这些常见基础配置 2，查看代码中有哪些第三方，将第三方的库对应的代码进行不混淆配置 3，测试，混淆后，将各个模块的代码跑一次，再一个模块一个模块检查

1-1，「appt」将资源文件，编译成R.java文件 1-2，「aidl」将 .aidl接口，转换成 .java接口 1-3，「javac」将 java文件、R.java文件、.java接口，编译成.class文件 2-1，「dex」将 项目编译的.class、三方.class，转换成 .dex文件 3-1，「apk builder」将.dex文件、图片资源、assets资源打包成.apk文件 4-1，「jarsigner」将.apk文件进行签名 5-1，「zipalign」对齐.apk文件，增大内存开销，提高运行速度 .java -> .class -> .dex -> .apk -> 签名+对齐

特性： 1，新的Notification 2，多窗体支持（分屏模式），并行运行两个应用 3，VR支持 性能和效率： 1，随时随地的低耗电模式，省电 2，高速的应用安装路径，提高安装应用和系统更新速度 安全： 1）私有文件夹，限制访问 2）应用间共享文件，需要通过FileProvider 3）Https的抓包，网络安全性配置，将粒度缩小到应用级别

系统自带的拦截器： 1，重试和重定向 2，请求头+响应头处理 3，缓存 4，dns + 三次握手 5，CallServer，读写数据流 常用的自定义拦截器： 1，日志拦截器 2，自定义缓存规则拦截器 3，重试机制等等

配上代码来说，统一的key，依据key去找；代码在Engine中 1，Hashmap，从弱引用中获取，直接内存缓存。系统内存不足时，允许gc 2，Lrucache，Lrucache缓存，超过缓存额度时，将最久未使用的内存删除。使用内存缓存，强引用 3，Hashmap，从网络中获取图片，同时如果多个相同的图片请求触发，避免相同的网络重复请求 4，创建新的LoadStatus(cb, EngineJob)，从网络中获取图片 总结：弱引用 -> Lrucache -> 网络防重复请求 -> 网络请求

遇到过一次，禁用的结果就是导致Http的请求无效了。 我们的现象就是，http的图片展示不出来了。 最直接的解决方案： 1，让后台换链接，也应该要换 2，target 设置在27及以下。