共计 2689 个字符，预计需要花费 7 分钟才能阅读完成。
前言：这个是个人观点，技术要用在适合的业务场景中能力体现出它的劣势，而不是自觉的去学，去看
解决现今开发的技术痛点
协程
回调天堂，切换线程等性能
a()// 耗时工作
b()
当两个办法 a，b 执行的代码块没有依赖关系时，执行耗时工作采纳异步的形式来解决，通过开线程或者通过 handler post 一个 Runnable 来执行 a 办法这个耗时操作，b 不须要期待 a 完结就能够间接运行。
然而如果 a 和 b 是有依赖关系的，b 办法须要用到 a 办法返回的数据进行解决，然而又为了不影响 b 之后的代码阻塞，所以会在 a 办法中传入一个回调，等到 a 办法执行完后回调接口，在回调办法外面在执行 b 办法
如果业务的依赖关系非常复杂，就会陷入到回调天堂中，这种形式 一是不够优雅，二是代码不够直观（逻辑太过简单）
相对来说：
协程在这方面比拟“优雅”；切换线程也只需一行 withContext（）; 代码更加直观（森有领会，以前都是点到这而后点那，点的点的发现晕了，歇菜【本人进行时序图整顿】）
插一句，这些性能并不是协程特有的，其余工具或者本人造轮子都能够实现。然而技术的功能性尽管很重要，然而其平台型和人造原生的 api 也是必不可少的（这部分前面在讲技术生态的时候探讨）。
插件化
这项技术尽管曾经不怎么“新”了，大家也都晓得了它的劣势和解决的痛点：
1.动静更新 app
(是整个 APP 都更新，不是热修复那种补丁包独自批改某个问题。实现办法目前是云端寄存最新的插件 apk，每次进行检测版本号等察看是否须要更新，当然保障 apk 的安全性也是必要的，可通过一些加密解密来保障)
2. 缩小包体积
（宿主只须要很小的空间，宿主只有一个目标，拉起 assets 上面的 apk，而后动静加载插件中的四大组件和插件代码）
3. 当业务规模越来越大，加载的可能不只是咱们的 app，须要把他人的 app 也加载起来。
上家公司重构代码之前是应用的插件化计划，不过这个插件化计划对 SDK 的版本有限度，只能用低版本的 SDK 来开发，而且整体上来说并没有对这个的强依赖（只有四个模块没必要独自都搞成一个 app），所以之后重构的时候放弃了插件化。所以还是要依据理论我的项目来看的。
从这项技术中能够学到什么
俗话说的话：知其然知其所以然。如果一味的独自拿来当做工具用，而漠视了其外部实现的神秘；当然并不是不可，只是感觉有些可惜。
选用适合的数据结构，选用适合的算法，切合实际场景的设计模式
譬如协程中存储上下文的数据结构（链表），异样解决机制中用到的树的构造 …… 等等（为什么这个这么少呢，因为我只学到了皮毛 ….）
插件化这个能学到什么呢？这个学到的货色可就多了，
如果你是采纳的 HOOK 形式实现的话，你可能学到四大组件的启动机制，启动流程，Android 原生资源解决机制，类加载机制，APK 装置流程 ….. 等等。
如果你是采纳的字节码转换 Transform 的机制来实现的话，你可能学到 Gradle 的构建流程，Gradle 自定义 TASK，Android 打包机制流程，字节码转换用到的 ASM,JavaAssist 框架，Class 构造体，Dex 构造体.. 等等。
怎么样？看着这些常识，是不是曾经蠢蠢欲动了哈哈，而且零碎源码可是 Google 工程师写的，选用的数据结构和算法也必然是优良的，从中又能够学到不少常识。
性能
协程是官网举荐的，Kotlin 官网文档下面尽管在说比线程更好，然而实际上你会发现在单线程的状况下，其实并没有区别。（多线程的话有区别记着先看一下他们用的线程池）。
对于插件化，不同的实现形式必定性能也体现不一样。通过 Hook 的形式因为用到了反射所以比用 Transform 转换要节约一些性能；在运行时遍历清单文件 xml 中读取 ContentProvider 的性能要比编译时提前将清单文件中的 ContentProvide 内容变为清单文件中的 metadate 由原生的 api 来反对查找更节约一些性能，等等这些实现的形式不同其性能也就不一样。
开发效率
用协程一个字爽，这也是他的长处同步写异步代码，然而并不只是它有，其余工具也能够提供。然而，flow，kotlin 语言等等这些都能够和协程配合，封装了底层操作，更敌对的反对。
插件化的效率这个并没有太大感触，可能还没有领会到。
弱小的平台反对
协程对于 kotlin 语言更加敌对，用 java 来写尽管也能够实现，然而在编写代码体验上就没有那么敌对了（你每次调用挂起函数都要进行传参等等）。
和热修复一样，Android 下面的补丁包降级在 ios 下面是没有的，通过 Hook 来玩 FrameWork 也是十分高兴的。
丰盛的 api
协程中很多 api 在应用的时候如果不理解它外面的一些原理机制，呈现问题的几率是十分大的 … 这里给大家贴一下之前遇到的一个坑（简化版）：
//withTimeoutOrNull 这个办法的意思是指定超时工夫完结后将返回 null（我返回的是 0）val result= withTimeoutOrNull(指定超时工夫为 5 秒){
// 创立一个协程
suspendCoroutine{// 在这里进行阻塞代码}
}?:0
// 代表之后的操作
val a=0
这个时候他不会返回 0，也就是阻塞住了，a= 0 始终不会走到。这是为什么呢？这里波及到协程的异样勾销机制了。
协程中创立了子协程后，会默认建设父子关系。当父协程勾销后，须要把它所有的子协程全副勾销掉，才算勾销实现。刚刚创立的子协程是不反对勾销的，所以始终梗塞住了。
怎么解决的呢？把这个子协程换成能够勾销的就能够了，也就是换成 suspendCancellableCoroutine 就好了、
还有就是网上目前对于协程应用出错纠正的文章很少，之后有机会能够记录下常见的谬误。
我认为的技术趋势在这里：
没错，就是下面讲的那两个哈哈：协程 插件化
最初，前几天在群里看到大佬说的一句话感觉不错，分享给大家：
技术是一直变动的，卷是不变的。
相干教程
Android 根底系列教程：
Android 根底课程 U - 小结_哔哩哔哩_bilibili
Android 根底课程 UI- 布局_哔哩哔哩_bilibili
Android 根底课程 UI- 控件_哔哩哔哩_bilibili
Android 根底课程 UI- 动画_哔哩哔哩_bilibili
Android 根底课程 -activity 的应用_哔哩哔哩_bilibili
Android 根底课程 -Fragment 应用办法_哔哩哔哩_bilibili
Android 根底课程 - 热修复 / 热更新技术原理_哔哩哔哩_bilibili
本文转自 https://juejin.cn/post/7053404649197895711，如有侵权，请分割删除。
