前言：这个是个人观点，技术要用在适合的业务场景中能力体现出它的劣势，而不是自觉的去学，去看
解决现今开发的技术痛点
协程
回调天堂，切换线程等性能
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，如有侵权，请分割删除。
转载请注明原文链接：关于an-d-ro-id:什么是好的技术为什么火
