一直以来发的文章大都是技术的,这次和大家聊点简单点的。
密集输出这几年,因为疫情没能在线下和大家碰面,去年又因为时间原因浪费了 Google IO China 门票。所以,今年的南京本地的 GDG DevFest 2023 活动一经上线,就报了名。
这次如愿见到了不少朋友,进行了面对面交流,非常赞!
跟大家分享下大佬们的演讲,以及值得探讨的技术问答。
遇见大佬 🫡
多次在线上听过叶楠老师的分享,从 Firebase
到 TensorFlow
。这次线下见到了,互留了微信,果然如想象得一样:非常 nice、知识渊博。
叶老师此次分享的是应用出海,无私分享了他多年开发国际化 App 的经验。听的途中我不禁感叹中国市场的特殊性,迫使本土开发者需要做如此之多的更改才能适应国际的环境。
王鹏是我 Android 事业的引路人,我毕业的时候就跟着他共事,教会了我很多技术上的、工作上的东西。时至今日,我们都会针对技术难题、文章细节、求职方向等方方面面进行交流探讨。
说来惭愧,王鹏老师北上之后,与他好多年没见面了。这次我来参加活动有个重要的原因就是想和他碰个面。他还像我毕业那会儿一样:精神饱满、幽默,同时还保持着惊人的发量。
本次他分享的主题是 Kotlin
优势,我也了解到了 Kotlin 在 Android
、Web
以外的领域亦有应用。PS. 他的 PPT 设计真得简洁、高级,和 Kotlin 一样!
张拭心老师的很多文章我都看过,尤其是最新的月度总结、周总结,我很敬佩他的自律和执行力。这次咱们交换了微信,惊奇地发现他也是我的读者,非常荣幸。
张老师本次分享的是 MAD
,现代 Android 开发里念。在介绍这个理念里的多个技术以外,还带大家一起回顾了 Android 的历史、发展和未来。
当他翻到最后一页,呈现出历代 Android 的 logo 时,我感触颇深:这是 Android 的发展史,同时也是咱们 Android 人的青春啊!
朱凯老师的视频,我估计 Android 圈子里大多都看过。他在 Kotlin、Android、Compose 等领域上的讲解通俗易懂、生动有趣。
本次他分享的是 Kotlin 协程,和网上的感觉一样:口才了得、富有感染力。
技术讨论 🤔
因为是在南京大学主办的,所以大多数听众是大学生,但其实也来了很多“像我一样”的 Android 资深开发😄。
活动的间隙,大气热情地交流了几个很不错的技术问题,值得分享给大家。
鸿蒙来势汹汹,咋办?
鸿蒙来势汹汹,NEXT 计划将彻底移除 ART,不再兼容 Android。同时,推出了自己的编程环境、UI 框架。请教诸位 GDE,大公司们是否有鸿蒙这方面的布局,以及如何看待这个新领域?
GDE 回答:
其实都已经和
鸿蒙
的技术人员开始了接触,但进度啊、计划啊还不太清楚。
我的意见:
鸿蒙移除 Android 需要漫长的过渡时间,不是那么快能完成的。虽然鸿蒙上要求采用
JS/C++
编程,但 IDE 仍然是和IntelliJ
差不多的,其 API 设计、开发模式整体上和 Android 体系里很像。所以,即便换了语言,Android 开发者切入进去有不少优势。
总之,不必恐慌,保持关注就行了。
Compose 应用到底咋样了?
Compose
正式发布已经过去了 2 年,如今 Google Play 前 1000 App 中已有 200 多采用了 Compose 商用,想了解下字节等国内大公司在 Compose 上的态度和计划?
(这其实是我提问的🙂,还混到了王鹏老师的亲笔签名赠书,算上新书发售时他送我的、回答拭心问题拿到的,这是我拿到的第 3 本 Jetpack Compose 书籍 😄)
GDE 回答:
已经对 Compose 进行了很多的调研,但大公司往往有自己封装的诸多 UI 框架、UI 效果库,切换到 Compose 成本高,也没有那么高强劲的需求。但一些新立项的 App 有在尝试 Compose 商用。
我的意见:
我印象中,海外像 Twitter 这样的大 App 早就开始部分或全部地改用了 Compose 技术。蛮佩服他们的,像这种级别的 App 同样也存在历史包袱,但他们就是这么勇敢(激进)!
国内大公司用的应该算少的,一些小公司可能会有商用的情况。我所在的公司有切入 Compose 技术的想法,所以我搁置了一段时间的 Compose 内容得重新看起来了💪。
Compose 性能劣化?
早期的 Compose
版本存在性能问题,采用 Scope
限制重组的办法是否有更优雅的方案?
GDE 回答:
Compose 确实在某些重组上存在性能劣化,采用 Scope 限制的做法确实存在,不必担心。
我的意见:
Compose 不断地迭代升级,性能在逐渐变好,估计未来官方会进行优化。
到时候就不用写这些迂回的代码了。
Kotlin 协程性能不佳?
对于 CPU 密集型任务,Kotlin
协程貌似性能并不好,没啥优势。GDE 是否了解,如何解决?
GDE 回答:
Kotlin 协程确实更适合 IO 密集型这种需要切换线程的场景。对于 CPU 密集型的场景,不能说差,只能说相对于 Java 不会有竞争性。
像你提到的性能不佳,极有可能是自己的代码导致的,需要认真分析下写法。
我的意见:
经验告诉我们代码表现不佳往往是调用得不好,逻辑存在问题。
但这不是 100% 绝对的,API 的实现、系统的运行存在 Bug 不是没可能的。
可以在排查自己的代码之后,如果确信没有问题,可以大胆地向
Jetbrains
、
如果看待新技术?
面对 Flutter
、Compose
、MAD
甚至鸿蒙这些层出不穷的新技术,学生、工程师该如何抉择?
GDE 回答:
有些技术只是封装、不同实现,甚至是 KPI。而算法理论、计算机思想、数据结构这些基础的东西才是永恒的东西。
当你时间有限,方向不明的时候,可以问下自己是否基础已经打牢了。
如果确实 OK 了再考虑方向的问题。
我在 MAD
的文章中有过类似总结,贴出来、与你共勉:
面对新技术:
- 不可无视,适当了解,跟上形势:保持关注,防止日后看不懂人家用了什么技术,甚至无法理解别人的代码
- 拥抱变化,勇于尝鲜,有备无患:找个感兴趣的切入点虚心学习、体会新技术的动机
- 不可依赖,了解原理,学习模仿:光使用还不够,需要深入了解其实现,确保坑来临的时候游刃有余
- 是否深入,见仁见智,自行评估:适当取舍、甚至观望,一些技术是昙花一现的
明年再见 🤗
今年是第一次参加线下的 GDG 活动,非常兴奋。结识了一堆大佬和读者之余,还跟 GDG 负责人建立了联系,说不定明年的 GDG Nanjing 会有我的身影。
其实,像 GDG 活动,只要有时间,建议大家尽量参加。在获得新知识的同时,还可以与圈子外的朋友交流,拓展自己的视野和影响力,同时还有一堆礼物可以领取。何乐而不为呢?
关于上述的技术问题,你有什么其他想法,欢迎在评论区留言~