“新”for me,2022一起来看看这些技术

3,058 阅读6分钟

2022 年什么会火?什么该学?本文正在参与“聊聊 2022 技术趋势”征文活动 」

什么是“好”的技术,为什么“火”

前言:这个是个人观点,技术要用在合适的业务场景中才能体现出它的优势,而不是盲目的去学,去看

解决现今开发的技术痛点

协程

回调地狱,切换线程等功能

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工程师写的,选用的数据结构和算法也必然是优秀的,从中又可以学到不少知识。

image.png

性能

协程是官方推荐的,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就好了、

还有就是网上目前对于协程使用出错纠正的文章很少,之后有机会可以记录下常见的错误。

我认为的技术趋势在这里:

没错,就是上面讲的那两个哈哈: 协程 插件化

最后,前几天在群里看到大佬说的一句话觉得不错,分享给大家:

技术是不断变化的,卷是不变的。

image.png