前言
我们程序员之所以担心35岁被裁员，是因为自己的经验和实力能力不符合，国内IT现状，大多数程序员都在外包公司工作，框架老化，代码就是为了完成任务而写，刚定好需求你做一半产品突然让你改需求……一切的一切，导致你每天都在重复基础的增删改查和简单业务处理，身边的人不如你甚至比你更烂，你找不到一个方向去提升自己，日复一日，虽然你工作好久，但是你对深一层次的代码依然一无所知，看不懂源码，写不出好的代码，该会的都会了，该不会还是不会，三年前是这样，三年后还是这样，没什么变化。
正文
1.图片的三级缓存中,图片加载到内存中,如果内存快爆了,会发生什么？怎么处理？
参考回答：
首先我们要清楚图片的三级缓存是如何的
如果内存足够时不回收。内存不够时就回收软引用对象
2.内存中如果加载一张500X500的png高清图片.应该是占用多少的内存?
参考回答：
- 不考虑屏幕比的话：占用内存=500 * 500 * 4 = 1000000B ≈ 0.95MB
- 考虑屏幕比的的话：占用内存= 宽度像素 x （inTargetDensity / inDensity） x 高度像素 x （inTargetDensity / inDensity）x 一个像素所占的内存字节大小
- inDensity表示目标图片的dpi（放在哪个资源文件夹下），inTargetDensity表示目标屏幕的dpi
3.WebView的性能优化 ?
参考回答：
一个加载网页的过程中，native、网络、后端处理、CPU都会参与，各自都有必要的工作和依赖关系；让他们相互并行处理而不是相互阻塞才可以让网页加载更快：
- WebView初始化慢，可以在初始化同时先请求数据，让后端和网络不要闲着。
- 常用 JS 本地化及延迟加载，使用第三方浏览内核
- 后端处理慢，可以让服务器分trunk输出，在后端计算的同时前端也加载网络静态资源。
- 脚本执行慢，就让脚本在最后运行，不阻塞页面解析。
- 同时，合理的预加载、预缓存可以让加载速度的瓶颈更小。
- WebView初始化慢，就随时初始化好一个WebView待用
- DNS和链接慢，想办法复用客户端使用的域名和链接。
4.Bitmap如何处理大图，如一张30M的大图，如何预防OOM？
参考回答：避免OOM的问题就需要对大图片的加载进行管理，主要通过缩放来减小图片的内存占用。
- BitmapFactory提供的加载图片的四类方法（decodeFile、decodeResource、decodeStream、decodeByteArray）都支持BitmapFactory.Options参数，通过inSampleSize参数就可以很方便地对一个图片进行采样缩放
- 比如一张10241024的高清图片来说。那么它占有的内存为102410244，即4MB，如果inSampleSize为2，那么采样后的图片占用内存只有512512*4,即1MB（注意：根据最新的官方文档指出，inSampleSize的取值应该总是为2的指数，即1、2、4、8等等，如果外界输入不足为2的指数，系统也会默认选择最接近2的指数代替，比如2）
综合考虑。通过采样率即可有效加载图片，流程如下
- 将BitmapFactory.Options的inJustDecodeBounds参数设为true并加载图片
- 从BitmapFactory.Options中取出图片的原始宽高信息，它们对应outWidth和outHeight参数
- 根据采样率的规则并结合目标View的所需大小计算出采样率inSampleSize
- 将BitmapFactory.Options的inJustDecodeBounds参数设为false，重新加载图片
5.内存回收机制与GC算法(各种算法的优缺点以及应用场景)；GC原理时机以及GC对象
参考回答：
1.内存判定对象可回收有两种机制
- 引用计数算法：给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。然而在主流的Java虚拟机里未选用引用计数算法来管理内存，主要原因是它难以解决对象之间相互循环引用的问题，所以出现了另一种对象存活判定算法。
- 可达性分析法：通过一系列被称为『GCRoots』的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。其中可作为GC Roots的对象：虚拟机栈中引用的对象，主要是指栈帧中的本地变量*、本地方法栈中Native方法引用的对象、方法区中类静态属性引用的对象、方法区中常量引用的对象
2.GC回收算法有以下四种：
-
分代收集算法：是当前商业虚拟机都采用的一种算法，根据对象存活周期的不同，将Java堆划分为新生代和老年代，并根据各个年代的特点采用最适当的收集算法。
-
新生代：大批对象死去，只有少量存活。使用『复制算法』，只需复制少量存活对象即可
- 复制算法：把可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用尽后，把还存活着的对象『复制』到另外一块上面，再将这一块内存空间一次清理掉。实现简单，运行高效。在对象存活率较高时就要进行较多的复制操作，效率将会变低
-
老年代：对象存活率高。使用『标记—清理算法』或者『标记—整理算法』，只需标记较少的回收对象即可。
-
标记-清除算法：首先『标记』出所有需要回收的对象，然后统一『清除』所有被标记的对象。标记和清除两个过程的效率都不高，清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
-
标记-整理算法：首先『标记』出所有需要回收的对象，然后进行『整理』，使得存活的对象都向一端移动，最后直接清理掉端边界以外的内存。标记整理算法会将所有的存活对象移动到一端，并对不存活对象进行处理，因此其不会产生内存碎片
-
《设计思想解读开源框架》
第一章、 热修复设计
-
第一节、 AOT/JIT & dexopt 与 dex2oat
-
第二节、 热修复设计之 CLASS_ISPREVERIFIED 问题
-
第三节、热修复设计之热修复原理
-
第四节、Tinker 的集成与使用（自动补丁包生成）
第二章、 插件化框架设计
-
第一节、 Class 文件与 Dex 文件的结构解读
-
第二节、 Android 资源加载机制详解
-
第三节、 四大组件调用原理
-
第四节、 so 文件加载机制
-
第五节、 Android 系统服务实现原理
第三章、 组件化框架设计
-
第一节、阿里巴巴开源路由框——ARouter 原理分析
-
第二节、APT 编译时期自动生成代码&动态类加载
-
第三节、 Java SPI 机制
-
第四节、 AOP&IOC
-
第五节、 手写组件化架构
第四章、图片加载框架
-
第一节、图片加载框架选型
-
第二节、Glide 原理分析
-
第三节、手写图片加载框架实战
第五章、网络访问框架设计
-
第一节、网络通信必备基础
-
第二节、OkHttp 源码解读
-
第三节、Retrofit 源码解析
第六章、 RXJava 响应式编程框架设计
-
第一节、链式调用
-
第二节、 扩展的观察者模式
-
第三节、事件变换设计
-
第四节、Scheduler 线程控制
第七章、 IOC 架构设计
-
第一节、 依赖注入与控制反转
-
第二节、ButterKnife 原理上篇、中篇、下篇
-
第三节、Dagger 架构设计核心解密
第八章、 Android 架构组件 Jetpack
-
第一节、 LiveData 原理
-
第二节、 Navigation 如何解决 tabLayout 问题
-
第三节、 ViewModel 如何感知 View 生命周期及内核原理
-
第四节、 Room 架构方式方法
-
第五节、 dataBinding 为什么能够支持 MVVM
-
第六节、 WorkManager 内核揭秘
-
第七节、 Lifecycles 生命周期
本文包含不同方向的自学编程路线、面试题集合/面经、及系列技术文章等，资源持续更新中…
第六节、 WorkManager 内核揭秘** -
第七节、 Lifecycles 生命周期
[外链图片转存中…(img-aJtfMtue-1648225331656)]
本文包含不同方向的自学编程路线、面试题集合/面经、及系列技术文章等，资源持续更新中…
[外链图片转存中…(img-jmOjtq55-1648225331656)]
