只是！特斯拉推出了历史上最快的计算机和神秘的机器人，真正的“钢铁侠”要来了吗？
06-21
简介 回首过去，似乎过得很快。不敢相信自己从事Android开发已经两年了，不禁感叹。
那么，Android上还会有什么技术趋势吗？或者说有什么[新]技术值得学习？或者对我来说，现在[值得]学习什么？本文将用我个人的技术学习经历来分析我们应该如何选择某项技术。希望能够对大家有所帮助。
回顾过去，让我们回到过去。这几年我给自己补充了哪些技术点？ Kotlin、Coroutine MVP、Hilt、MVVM、JetPack 相关热修复 Flutter 简单测试自动化、持续集成相关 JetPack ComposeEpoxy+Mvrx、MVI 看完这个列表，你是不是很惊讶，天哪，你小子什么都没学到？说来惭愧，我在翻阅博客记录的时候，也曾有过这样的感叹。
我确实好像没怎么读过【新技术】，所以在年终总结的时候，我发出了这样的感叹，今年用的组件我以前都学过，但是我忘记了，所以我拿出来我的笔记并看了看它们。但仔细想想，新技术似乎确实不多。
对于Android端来说，Compose是一个沉重的打击，而MVI最近也因为Compose而被正式启用为Google推荐的[新]架构标准。其他人似乎并非如此。
如果我们只将技术定义为【技术组件】，可能就太狭隘了，所以我们来列出今年Google推送的技术文章：如何找到它们，那么Android开发者公众号就是重中之重。所以我们对Android发表的文章做了一个粗略的总结。
我列出了Android官方给我们的建议，大致如下：JetPackNavigation、Hilt、WorkManager、ActivityResultCompose、Wear OS-Compose、Wear Os-Card Library WindowsManager、Room、Paging3.0、Glance - Alpha 折叠屏幕、大屏适配已多次推荐，KotlinFlow、Vocabulary、协程Android12行为变化、隐私和安全更新、新的widget安全数据也在Android12上多次推广。加密和生物识别、App合规性 Android启动相关App启动、延迟初始化Camera 不难发现，JetPack依然是Android官方推荐，其次是折叠屏和适配不同屏幕，其次是Kotlin和Android12。
当然，今年由于各种合规问题，Android团队也提到了安全性。最后只是一些与性能和 UI 相关的建议。
趋势预测：严格来说，折叠屏向大屏的适配并不是一项技术，而是一项适配工作。但长期以来，Android在适配大屏幕方面做得很少。
自从三星推出首款可折叠屏幕以来，这种适配就开始受到关注。厂商方面，目前OPPO、华为、小米也都推出了自己的折叠屏手机，以满足高端市场。
在官方支持方面，如果你看过今年的IO大会，你会发现折叠屏适配已经被放到了专门的专栏中并进行了专门的解释，而且官方公众号也多次宣传过。所以我们可以姑且认为折叠屏适配应该是一种趋势，但目前适配折叠屏的主流应用并不多。
大部分都是做了相关适配的厂商，app开发专门针对的，实际上并没有做太多改变。因此可以看出，随着折叠屏手机型号的不断增多，对于某些关键服务也会进行全面的适配工作，而不仅仅是折叠时同时有两个APP，或者某个页面显示在另一个屏幕上。
在技??术支持方面，Android团队为此专门准备了一个新的JetPack组件——JetPack WindowManager。其主要功能是监控屏幕的折叠状态以及当前对应的屏幕信息。
目前主要针对可折叠设备，但未来将会支持。更多的屏幕类型和窗口功能现在都在rc版本中，当然今年肯定会推出稳定版本。
自从JetPack Compose第一个稳定版本发布以来，Compose在今年的IO大会上也有专门的版块来谈论它。它是一个用于构建原生 Android 的工具包。
它采用声明式方式编写，并与 Kotlin 搭配使用，可以极大地简化和加速原生 UI 开发工作。目前Compose已经支持以下几个方面：Android UI支持Wear、可穿戴设备支持Android Widget、widgets支持非官方方面。
Jetbrains 还支持桌面版本和网页。详情请参见：Compose Multiplatform Desktop Version 目前已经发布了正式版本 1.0.1。
得益于Compose的声明式开发，适配折叠屏相对简单。 Compose 还为与本机视图交互提供了非常好的支持。
所以我们可以认为，如果你是从事原生开发的话，那么Compose必然是一项更适合你学习的新技术。上手并不难。
只要熟悉Kotlin，就可以快速上手。不过，目前在 IDE 上的预览功能比较慢，未来需要优化。
Kotlin 协程实际上在过去几年得到了广泛的应用。我第一次使用协程是在2008年，也见证了它逐渐取代AsyncTask及相关线程池工具。
FlowFlow今年已经多次被Android团队推荐。它主要是基于协程构建的。
从某种意义上来说，我个人感觉它似乎是RxJava的替代品。得益于 Kotlin 的强大功能和简单性，今年 Flow 最常见的场景是 Android 团队建议它替换 LiveData，以增强其在某些情况下的使用。
当然，Flow 并不止于此。如果你正在使用 Kotlin 并且大量使用协程，那么 Flow 绝对是一个绕不开的话题。
所以我们可以估计协程和Flow还是值得学习的，而且也是能够很快感受到好处的组件。但与协程相比，Flow 其实还有很长的路要走。
毕竟，在常见的开发场景中，LiveData就可以了，但Flow似乎就没那么必要了。 ASM技术其实并不新鲜，但由于它需要很多先决知识，比如Android打包流程、APK打包流程、字节码、自定义Gradle插件、Transform API等，所以被细分为很多领域。
小伙子们还在追我，但我这样的新手仍然看起来像个傻子。那么为什么我认为这是一种技术趋势呢？主要是受到合规性的影响。
在大环境下，我们以后打包时可能会监听相应的权限声明和隐私调用。否则如何保证后续的变更不会导致违规？但如何判断某个sdk没有被调用呢？而我们也不可能每次都要求相关第三方来检测。
因此，在大环境下维护相应的监控组件是必要的。实现上述插件最好的方式就是Hook或者ASM，所以如果你处于比较高级的阶段，ASM仍然是你无法回避的技术话题。
什么对你来说[值得]学习？这个副标题其实有点夸张，但是仔细想想，其实是这样的。我们应该了解什么更适合我们当前的学习。
以我为例，你可以感受一下你应该关注哪些技术。当然，我的个人经验只能作为像我这样的同学的参考：正如我一开始所说的，其实我已经使用过很多这样的新组件了。
我用过或者记录过。前两年，我一直在追求更新更好的组件之路，所以每当有新的组件发布时，我总会在项目中实践、尝试。
但我也逐渐发现了一些问题。经历了【使用工具】这个阶段后，当我想解决某些情况下的问题时，我突然发现我似乎什么都不懂，或者只知道基础知识，比如：在集成一些gradle插件时，如果你想要满足CI下的一些便利，需要编写一些Task来满足动态集成。
不过，我对Android与Gradle仅处于普通使用阶段。这个时候我就需要学习相关的东西；我自己也会维护一些组件库。
随着使用的学生逐渐增多，提到的问题也越来越多。如何解决这些问题，如何优雅兼容，如何组合组件，如何使用合适的设计模式进行优化等等，这是我需要考虑的另一个问题；当我们开始关联音视频组件的时候，这时候就出现了很多方向，而最终的方案选择也需要你再次进入一个未知的领域，从0到0.1；新技术会让我现在对编码感到满意，这可以为我节省很多事情，但是它无法解决一些非编码或复杂的问题，而这些问题是每个学生在前进的路上都会遇到的，所以我们经常看到做Android真的很困难，你必须什么都知道。
总体来说，对于我来说，今年会重点关注以下几个方面：第三方库中Gradle相关设计模式的使用、Android相关源码的理解和总结、技术在不断的变化和迭代，我们会发现为什么有些技术已经过时了好几年。 ，看似今年特别受到关注，其实也是因为在一定的情况下，它的作用逐渐显现出来。
这些技术是成为一名优秀的Android工程师必须具备的基本技能。当我们追求【新】科技、享受速度的同时，别忘了【停下来】看看我们身边的风景。
我是 Petterp，一名三流开发人员。如果本文对您有帮助，请点赞支持。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-18
06-18
06-18
06-18
最新文章
【玩转GPU】ControlNet初学者生存指南
【实战】获取小程序中用户的城市信息（附源码）
包雪雪简单介绍Vue.js：开学
Go进阶：使用Gin框架简单实现服务端渲染
线程池介绍及实际案例分享
JMeter 注释 18 - JMeter 常用配置组件介绍
基于Sentry的大数据权限解决方案
【云+社区年度征文集】GPE监控介绍及使用