#kotlin

코틀린으로 비동기 프로그래밍을 하다 보면, 코루틴의 일시 중단 지점에서 변수 값을 확인하려 할 때 디버거에서 '최적화로 제거됨(was optimised out)'이라는 메시지를 접하게 되는 경우가 있습니다. 이는 코루틴이 상태 기계(state machine)로 컴파일되면서, 일시 중단 지점 이후에 필요하지 않은 변수들은 성능 최적화를 위해 제거되기 때문입니다. 이러한 상황은 디버깅을 어렵게 만들 수 있어서 당혹스러울 수 있는데요, 빌드 설정을 조정하여 디버깅 시에만 이러한 변수를 유지하도록 설정하는 방법을 알아보겠습니다. 이를 통해 IntelliJ IDEA나 Android Studio에서 코루틴을 디버깅할 때 변수 값을 확인할 수 있으며, 프로덕션 성능에는 영향을 주지 않습니다. 왜 변수들이 '최적화로 제거됨' 상태가 되는가? 코틀린 코루틴은 컴파일 시 상태 기계로 변환됩니다. 이 과정에서 일시 중단(suspend) 지점 이후에 사용되지 않는 변수들은 메모리 사용을 줄이기 위해 제거됩니다. 또한, inline 함수로 표시된 코루틴 함수는 컴파일러가 코드 최적화를 위해 불필요한 변수를 제거할 수 있습니다. 이러한 최적화는 성능 향상에는 도움이 되지만, 디버깅 시에는 변수 값을 확인하지 못하게 만드는 원인이 됩니다. '최적화로 제거됨' 변수를 다시 보이게 만드는 방법 디버깅 시에만 코루틴의 변수를 유지하도록 빌드 설정을 동적으로 변경할 수 있습니다. 이를 위해 idea.active 속성을 활용하여, IntelliJ IDEA나 Android Studio에서 작업할 때만 디버그 친화적인 설정을 적용할 수 있습니다. 1. 코루틴 디버깅 동적 활성화 build.gradle.kts 파일에서 다음과 같이 설정합니다. // Kotlin Multiplatform kotlin { compilerOptions { if (System.getProperty("idea.active") == "true") { println("Enable coroutine debugging") freeCompilerArgs = listOf("-Xdebug") } } } // Kotlin JVM kotlin { compilerOptions { if (System.getProperty("idea.active") == "true") { println("Enable coroutine debugging") freeCompilerArgs.add("-Xdebug") } } } 2. 설정의 작동 원리 System.getProperty("idea.active"): 이 시스템 속성은 프로젝트가 IntelliJ IDEA나 Android Studio에서 열릴 때 자동으로 true로 설정됩니다. 이를 통해 IDE에서 작업할 때만 디버그 관련 설정을 적용할 수 있습니다. -Xdebug: 이 컴파일러 인자는 디버그 친화적인 바이트코드를 생성하여, 디버깅 시 코루틴 변수에 대한 정보를 더 많이 유지합니다. 3. idea.active 사용의 장점 성능 저하 방지: -Xdebug와 같은 디버그 옵션은 애플리케이션의 성능을 저하시킬 수 있습니다. 이를 IDE에서 작업할 때만 활성화하여 프로덕션 빌드에는 영향을 주지 않도록 합니다. 작업 흐름 간소화: IntelliJ IDEA나 Android Studio에서 디버그 설정을 자동으로 활성화하여, 개발 중에 설정을 수동으로 변경하는 번거로움을 줄입니다. 안전한 설정 관리: 이 방법을 통해 빌드 스크립트를 깔끔하게 유지하면서, 필요한 경우에만 디버그 플래그를 적용할 수 있습니다. 마치며 코틀린 코루틴을 디버깅할 때 '최적화로 제거됨' 메시지로 인해 변수 값을 확인하지 못하는 문제는 위와 같은 빌드 설정 조정을 통해 해결할 수 있습니다. 이를 통해 디버깅 효율성을 높이고, 프로덕션 성능에는 영향을 주지 않도록 설정할 수 있습니다. 출처: Debugging Kotlin Coroutines: Making “Optimised Out” Variables Visible

layout(.xml) 파일에서 몇 가지 수정하는데 애뮬레이터나 핸드폰 연결해서 적용해봤는데 변경사항이 저장이 안됐습니다. 그래서 다른 코드가 잘못됐나? 하고 지우고 지우다 그냥 딱 기본 코드만 남겨놓고 변경했는데도 여전히 변화가 없습니다.   사진으로 보면 무슨 말인지 확실히 알 수 있습니다. 왼쪽은 제가 원하는 결과물이고 오른쪽은 애뮬레이터에 표시되는 화면입니다.    그리고 왼쪽과 같이 layout(.xml)파일을 수정하고 애뮬레이터 terminate 시키고 다시 실행시킨게 오른쪽 사진입니다.  동작을 안합니다..   class EditProfileActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_edit_profile) } } 위의 코드는 해당 코틀린 코드입니다. 가장 기본적인 코드만 남겼는데도 위와 같이 문제가 일어납니다.   해당 파일을 지우고 다시 만드는 방법도 있겠지만, 이 layout 말고도 다른 곳에서도 위와 같은 문제가 발생해서 가능하다면 이유를 알아서 삭제하지 않고 해결하고 싶습니다. 왜 이런 문제가 발생하는지 아시는 분 계실까요?

Kotlin Playground: Edit, Run, Share Kotlin Code Online play.kotlinlang.org Kotlin Playground 라는 사이트를 통해 코틀린 코드를 실행하거나 공유할 수 있습니다. https://play.kotlinlang.org/ 로 접속하시면 되구요. https://www.raywenderlich.com/16929465-kotlin-playground-getting-started 로 가시면   Kotlin Playground 시작하기 튜토리얼도 볼 수 있습니다.        

5G Connectivity Almost exactly one year ago, I published a post on how to monitor changes in connectivity status. Since then, 5G networks have started to become more common. Also, I have found some improvements in h blog.stylingandroid.com 5G는 높은 전송 속도를 제공하지만 5G 관련 기능은 사용자의 앱이 5G인 상태에서만 실행되도록 해야합니다. 여기 코틀린에서 5G를 감지하는 방법이 있습니다. 겸사 종량제 네트워크인지 감지하는 방법도 뽀너스로~😁

Getting Started | Spring Boot with Kotlin Coroutines and RSocket Build a chat application with Reactive Web services from Spring, Kotlin, WebFlux and RSocket spring.io Spring Boot와 Kotlin을 사용하여 간단한 채팅 애플리케이션을 빌드하는 튜토리얼

Why are Java server-side developers not adopting Kotlin? The Java server-side community hasn’t adopted Kotlin heavily yet, and the resistance doesn’t always arise from actual language merits. medium.com 오랜 자바 개발자로서 수년간 코틀린을 사용하고 그것을 서버에 적용해보면서 코틀린에 재미를 느낀 개발자가 쓴 글인데요 자바 서버 개발자들이 코틀린으로 서버 개발을 하지 않는 이유에 대해 본인의 관점에서 정리한 글입니다. 다시 말해 코틀린을 서버에 적용해도 좋다는 입장에서 항목별로 정리한 글 같습니다. 그 내용을 요약해 보았습니다. (물론 블로그의 내용일 뿐 제 의견은 아닙니다^^) --------------------------------------   "새로운 언어를 배울 시간이 없다" 새로운 학습의 시간이 필요하긴 하지만 좋은 소프트웨어는 시간 투자가 필요하며 숙련된 자바 개발자는 금방 학습할 수 있다.   "자바는 릴리즈할 때마다 좋아지고 있다" 자바도 릴리즈할 때마다 좋아지고 있는 것은 사실이지만 생산성에는 코틀린에 뒤쳐지고 있다   "자바 개발자인 것이 행복하다" 프로그래머는 하나의 언어에만 머무르는 것은 좋지 않다. 자바 개발자는 코틀린을 사용함으로써 뒤쳐지지 않을 수 있다.   "코틀린은 미래를 알 수 없는 언어이다" 2017년부터 나왔던 이슈이지만 구글은 그 해 안드로이드에 코틀린을 채택했다. Spring과 Micronaut같은 인기 프레임워크에서도 점점 수용하고 있다.   "이클립스를 사용하고 있는데 InteliJ로 전환하고 싶지 않다" 이클립스의 코틀린 환경이 JetBrains IDEA와 일치하지 않을 수 있다. JetBrains의 비지니스 모델에는 개발자 도구 판매도 있어서 쉽게 바뀔 것 같지 않긴 하다. 코틀린이 이클립스를 지원할 수 밖에 없는 상황이 오는 것도 좋긴 하지만 InteliJ가 자바 개발 용도로만 볼 때 더 나은 IDE이므로 전향하는 것도 나쁘지 않다.   "코틀린 개발자는 너무 비싸고 구하기 어렵다" 코틀린 개발자가 자바 개발자보다는 약간 비싼 것 처럼 보이기는 하다. 팀에서 코틀린을 우선으로 두는 것 자체가 채용 시 자바 개발자들이 새로운 것을 배울 수 있는 기회로 보일 수도 있다.   "코틀린은 너무 복잡하다" 코틀린은 사용성과 고급 기능 사이에서 균형을 유지하는 것이 목적인 언어이다. 코틀린을 자바 언어처럼 사용하려고하면 어려워질 수 있다.   "하나의 코드베이스에서 두 가지 언어를 사용하는 것은 혼란스럽다" 두 언어가 공존하는 것을 애초부터 염두해 두면 그렇게 혼란스럽지 않다. 자바가 남아있다고 코드가 안 돌아가는 것은 아니므로 코틀린을 우선으로 해서 바꿔가면 된다.   "우리는 자바가 더 편하다" 보통은 시간 부족으로 꺼리게 된다. 직무와 연관시키는 학습법을 통해 이 문제를 해결할 수 있다.   "코틀린이 가져오는 이점을 모르겠다" 몇몇 자바 개발자들은 코틀린을 시도하기 전에 시도하지 않을 이유부터 찾곤 한다.   결론적으로, 변화에 대한 저항은 있을 수 있지만 더 많은 자바 개발자들이 기회가 있을 때 코틀린을 접해보길 바란다. -------------------------------