什么是“好”的技术,为什么“火”
前言:这个是个人观点,技术要用在合适的业务场景中才能体现出它的优势,而不是盲目的去学,去看
解决现今开发的技术痛点
协程
回调地狱,切换线程等功能
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就好了、
还有就是网上目前对于协程使用出错纠正的文章很少,之后有机会可以记录下常见的错误。
我认为的技术趋势在这里:
没错,就是上面讲的那两个哈哈: 协程 插件化
最后,前几天在群里看到大佬说的一句话觉得不错,分享给大家:
技术是不断变化的,卷是不变的。
哈哈: 协程 插件化
最后,前几天在群里看到大佬说的一句话觉得不错,分享给大家:
技术是不断变化的,卷是不变的。
[外链图片转存中…(img-Od24qPzh-1645704957517)]
最后
有小伙伴私信问Compose的问题,好不好用啊,现在要不要学啊?
其实答案很简单,自从谷歌2019年公布了声明式UI框架Jetpack Compose后,两年多的时间,各种大力宣传,和大量资源的倾斜,API功能都趋于稳定了。
至于好不好用,各种用过的同行都是持肯定态度的。优势大概就是这四点:
强大的工具和直观的Kotlin API
简化并加速了Android上的UI开发
可以帮助开发者用更少更直观的代码创建View
有更强大的功能,以及还能提高开发速度
这么大的优势,毋庸置疑,肯定是要学的嘛,而且越快掌握越好。别等刀架到脖子上了,才去练金钟罩。
至于怎么快速上手,可以给大家免费分享一份**《Jetpack Compose 完全开发手册》**,手把手教大家从入门到精通。
第一章 初识 Jetpack Compose
-
为什么我们需要一个新的UI 工具?
-
Jetpack Compose的着重点
加速开发
强大的UI工具
直观的Kotlin API
- API 设计
- Compose API 的原则
一切都是函数
顶层函数(Top-level function)
组合优于继承
信任单一来源
- 深入了解Compose
Core
Foundation
Material
- 插槽API
第二章 Jetpack Compose构建Android UI
- Android Jetpack Compose 最全上手指南
Jetpack Compose 环境准备和Hello World
布局
使用Material design 设计
Compose 布局实时预览
……
- 深入详解 Jetpack Compose | 优化 UI 构建
Compose 所解决的问题
Composable 函数剖析
声明式 UI
组合 vs 继承
封装
重组
……
- 深入详解 Jetpack Compose | 实现原理
@Composable 注解意味着什么?
执行模式
Positional Memoization (位置记忆化)
存储参数
重组
……
第三章 Jetpack Compose 项目实战演练(附Demo)
- Jetpack Compose应用1
开始前的准备
创建DEMO
遇到的问题
- Jetpack Compose应用2
- Jetpack Compose应用做一个倒计时器
数据结构
倒计时功能
状态模式
Compose 布局
绘制时钟
- 用Jetpack Compose写一个玩安卓App
准备工作
引入依赖
新建 Activity
创建 Compose
PlayTheme
画页面
底部导航栏
管理状态
添加页面
- 用Compose Android 写一个天气应用
开篇
画页面
画背景
画内容
……
- 用Compose快速打造一个“电影App”
成品
实现方案
实战
不足
……
由于篇幅限制,文档的详解资料太全面,细节内容太多,所以只把部分知识点截图出来粗略的介绍,每个小节点里面都有更细化的内容!
有需要的话可以点下面二维码免费领取↓↓↓