什么是“好”的技术（为什么“火”？） an-d-ro-id

前言：这个是个人观点，技术要用在合适的业务场景中才能体现出它的优势，而不是盲目的去学，去看
解决现今开发的技术痛点协程
回调地狱，切换线程等功能

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，如有侵权，请联系删除。