Android最全Android targetSdkVersion 升级到 26 总结(2)，Android体系化进阶学习图谱

最新推荐文章于 2024-08-04 03:33:58 发布

2401_84562377

最新推荐文章于 2024-08-04 03:33:58 发布

阅读量319

点赞数 4

分类专栏：程序员文章标签： android 面试学习

本文链接：https://blog.csdn.net/2401_84562377/article/details/138607842

版权

程序员专栏收录该内容

194 篇文章 2 订阅

订阅专栏

最后

今天关于面试的分享就到这里，还是那句话，有些东西你不仅要懂，而且要能够很好地表达出来，能够让面试官认可你的理解，例如Handler机制，这个是面试必问之题。有些晦涩的点，或许它只活在面试当中，实际工作当中你压根不会用到它，但是你要知道它是什么东西。

最后在这里小编分享一份自己收录整理上述技术体系图相关的几十套腾讯、头条、阿里、美团等公司2021年的面试题，把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，这里以图片的形式给大家展示一部分。

还有 高级架构技术进阶脑图、Android开发面试专题资料，高级进阶架构资料帮助大家学习提升进阶，也节省大家在网上搜索资料的时间来学习，也可以分享给身边好友一起学习。

【Android核心高级技术PDF文档，BAT大厂面试真题解析】

【算法合集】

【延伸Android必备知识点】

【Android部分高级架构视频学习资源】

Android精讲视频领取学习后更加是如虎添翼！进军BATJ大厂等（备战）！现在都说互联网寒冬，其实无非就是你上错了车，且穿的少（技能），要是你上对车，自身技术能力够强，公司换掉的代价大，怎么可能会被裁掉，都是淘汰末端的业务Curd而已！现如今市场上初级程序员泛滥，这套教程针对Android开发工程师1-6年的人员、正处于瓶颈期，想要年后突破自己涨薪的，进阶Android中高级、架构师对你更是如鱼得水，赶快领取吧！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

AndPermission 这个库的动态权限请求具体过程大伙可以看下 AndPermission 这个库的源码。（https://github.com/yanzhenjie/AndPermission）使用方式如下：

从 API 调用来看是十分简单好用的。然后我又仔细看了一下它的实现过程，发现了有些不符合我们产品需求的地方：

业务方接入需要简单，需要有一套默认的权限申请失败提示框
弹框提醒权限必须是 Activity 的。但是 AndPermission 是支持 Application 传入的，那么就会有问题
比如我用户点击某个按钮导致后面的方法链中有可能连续调用多次的权限请求，那么就可能一次会弹出很多个框

这样我们就需要在 AndPermission 基础上进行改造，做出适合自己的动态权限库。我们自定义了默认的 onDenied (申请权限失败后的回调)。这样业务方就不需要关心失败后怎么提示了，只要关心成功后把之前的业务逻辑放到成功后这里执行就好了。

权限申请失败提示框，用来启动一个 Activity 来 show 这个 Dialog，这样即使在前面传入的是 Application 的 context 也是没有问题了。对于多次请求权限导致多次弹框的问题，我们在 AndPermission 的基础上添加的请求队列，只有上一个权限请求处理完成后，才进行下一次权限请求，这样的话，即使用户一次行为的方法链过程中有很多次请求也不会多次弹框。

然后当我用队列管理请求权限的时候，很怕某个权限阻塞了，或者出了未知异常，所以我对每次权限加入过程做了超时处理。以上几点是对于自己业务场景的几点考虑，进行的改造。

修改各个 SDK 和 App

U51AndPermission SDK 已经生成了，那接下来就是怎么集成到各个 SDK 和 App 中了。首先我们要知道，我们的 App 哪些地方有可能调用到了需要权限请求的 API。如果要人工去看效率实在是太低了。

我们有 100 多个库，不可能把库看完且不出错。所以我们使用了之前同事的一个插件去扫描相关的 API，用来定位到可能出现权限的类在哪里，用的是哪个库。这样就提高了准确率和效率。

这个是我们插件需要搜索的 API

以下是部分搜索结果

按照这种方法，我们本需要处理 100 多个类库的，现在只有 20 个不到。一下子少了 4 倍的工作量，而且相对准确。

App 「必选权限」方案选择和问题处理

很多 App 启动的时候需要一些必选权限的，我们的 App 也是一样的，需要在 App 启动的时候验证一个必选权限。如果有必选权限，那么提示用户授权，如果不授权，那么就不能够继续使用我们的产品了。所以进入 App 主要功能前，需要一个前置的拦截。考虑过 2 种方案：

方案一、在 Applicaiton 的 onCreate 方法中去申请必选权限，让启动 Activity 等待 Application 中权限申请好了，再用消息(EventBus) 通知启动 Activity 继续走下去的流程
方案二、新建一个新的启动 Activity，在这个 Activity 中做申请权限，申请完后再去启动之前老的启动 Activity

和对接的业务方讨论，他们选择了第一种方案，这么做的原因也是因为我们很多 SDK 的初始化代码在 Appliction 中，我们必须要在初始化 SDK 之前就应该把必要权限拿到。如果选择第二种，那么我们的初始化代码需要移动到新的启动 Activity 中，这样改动风险有点高。

接入代码如下：

对接完后有几个我们遇到的问题需要提下：

问题一、因为在 App 启动的时候，如果没有必要权限，那么就会有弹框让用户设置权限，这时候用户点击 “设置”，就会跳转到 App 设置权限页面，当用户授权回来的时候，有部分手机会出现黑屏。

导致黑屏的原因是 U51Permission 传入进去的 context 是 Application。如果是 Activity 就不会黑屏。所以解决方法是使用 Activity 去请求权限，回调方式是使用 Application.registerActivityLifecycleCallbacks，如下：

问题二、因为我们有些逻辑是放到前后台切换的代码里面的，前后切换的主要用主要用到 Application.registerActivityLifecycleCallbacks 这个回调，根据 Activity 的生命周期统计来切换前后台(前后台的切换逻辑是使用统计 activity 的个数来实现的)；所以 Application.registerActivityLifecycleCallbacks 这个操作应该是在启动 Activity 之前就应该被注册。

但是在申请必要权限的时候，我先启动 Activity 后再去注册这个 callback 的，所以导致启动 Activity 不在计算范围内，导致前后台的调用逻辑不准确，业务逻辑处理时机不对的问题。后来我们使用一个自己的 registerActivityLifecycleCallbacks，命名 MyActivityLifecycleCallbacks，在 Application 一开始启动的时候就注册了，然后把后面其他需要注册的地方放到 MyActivityLifecycleCallbacks 中，由它统一通知其他需要前后台的回调。

替换之前