一直以来发的文章大都是技术的，这次和大家聊点简单点的。
密集输出这几年，因为疫情没能在线下和大家碰面，去年又因为时间原因浪费了 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 活动，只要有时间，建议大家尽量参加。在获得新知识的同时，还可以与圈子外的朋友交流，拓展自己的视野和影响力，同时还有一堆礼物可以领取。何乐而不为呢？
关于上述的技术问题，你有什么其他想法，欢迎在评论区留言～