1. new 연산자를 이용한 방식 ( String str = new String(""); )
- new 연산자를 쓰면 Heap 영역에 할당된다. 그래서 같은 문자열이라도 다른 객체라서 선언한 만큼의 새로운 객체가 메모리에 올라간다.
2. 리터럴을 이용한 방식 ( String str = ""; )
- String constant pool (상수 영역)이라는 영역에 할당된다.
- String을 리터럴로 선언하면 내부적으로 String의 intern() 메소드가 호출된다. intern() 메소드는 주어진 문자열이 string constant pool에 존재하는지 검색한다. 있다면 그 주소값을 반환하고 없다면 string constant pool에 넣고 새로운 주소값을 반환한다. 그래서 메모리에는 하나만 올라가게 된다. 그래서 메모리에는 하나만 올라가게 된다.
Java6까지 string constant pool의 위치가 perm이었지만 java7 이후 Heap으로 변경되었다. perm은 고정사이즈고 runtime에 사이즈가 확장되지 않아서 변경됐다고 한다.
cf) 리터럴(literal) : 변수 및 상수에 저장되는 값 자체. 즉, 공간이 아니라 그 값. 정수 리터럴, 문자열 리터럴, 배열 리터럴 등등이 있다.
* String 객체의 hashCode() 메소드
Java에서 참조형 변수의 메모리 주소를 파악하는 방법 => Object 객체의 hashCode()
=> hashCode()의 값은 실제 메모리 주소가 아닌 메모리 주소 값을 해싱된 값이다.
하지만, String 객체는 hashCode() 메소드가 immutable 오버라이딩 되어있어, 주소가 아닌 문자열을 해싱한 값을 가지고 있다.
String str1 = new String("hello");.
System.out.println(str1.hashCode()); // 99162322
String str2 = new String("hello");
System.out.println(str2.hashCode()); // 99162322
위의 두 String 객체 s1, s2는 다른 객체이기 때문에 주소값은 다를 것입니다.
일반적인 객체였다면 hashcode() 결과값이 달라야 하지만, String 객체이므로 hashCode()의 결과 값이 같다는 것을 확인할 수 있습니다.
참고
- 이펙티브자바 아이템 6. 불필요한 객체 생성을 피하라 다음 코드는 하지 말아야 할 극단적인 예이니 유심히 한번 살펴보자. String s =. new String("bikini"); 이 문장은 실행될 때마다 String 인스턴스를 새로 만든다. 완전 쓸데없는 행위다. 생성자에 넘겨진 "bikini" 자체가 이 생성자로 만들어내려는 String과 기능적으로 오나전히 똑같다. 이 문장이 반복문이나 빈번히 호출되는 메서드 안에 있다면 쓸데없는 String 인스턴스가 수백만 개 만들어질 수도 있다. String s = "bikini"; 이 코드는 새로운 인스턴스를 매번 반드는 대신 하나의 String 인스턴스를 사용한다. 나아가 이 방식을 사용한다면 같은 가상 머신 안에서 이와 똑같은 문자열 리터럴을 사용하는 모든 코드가 같은 객체를 재사용함이 보장된다.
네이버 테크 콘서트(NAVER TECH CONCERT : MOBILE 2019.07.11 Android)에 다녀왔습니다. 네이버가 주관하는 행사인 테크 콘서트는 올해 7월엔 모바일이란 주제로 진행되었습니다. 올해 4월엔 웹 프런트엔드로 진행되었는데 최근 관심사가 웹이라 참석하지 못해 좀 아쉽더라고요. 이번 행사는 친구의 권유로 신청하게 되었습니다. 작년에 안드로이드 앱 개발을 해본 적이 있는 저는 안드로이드로, 친구는 iOS를 신청해서 이번엔 혼자 갔다 오게 되었습니다. 주니어 개발자를 위한 행사다 보니 경쟁률은 치열하지 않은 것 같았습니다! 떨어지진 않을까 걱정했었는데 너무 멋진 강연 들을 수 있어서 좋았습니다. 네이버 테크 콘서트에 초대해주시고 강연해주신 많은 분들께 감사인사를 드립니다.
1회: NAVER TECH CONCERT : ANDROID 2018
2회: NAVER TECH CONCERT : FRONT END 2019
3회: NAVER TECH CONCERT : MOBILE 2019
지금까지 위와 같이 진행된 것 같습니다. 다음번엔 어떤 주제로 프로그램이 진행될지 궁금하고 다음번에도 기회가 된다면 참석하고 싶습니다!
이번 행사는 6월 18일부터 6월 30일까지 참가 신청을 받았고, 7월 2일에 초대메일을 받았습니다.
강의는 위와같이 진행되었습니다.
정자역에서 10분정도 걸어가면 네이버 그린팩토리를 발견할 수 있습니다. 쉽게 찾으시는 방법은 정자역 3번 출구에서 대학생으로 보이는 사람을 따라가면 네이버 앞에 있습니다. 12시 40분쯤 도착했는데 자리가 많이 꽉 차 있었습니다. 원하는 자리에 앉고 싶으신 분은 일찍 가시길 추천드립니다. 의자 오른쪽 아래 콘세트가 있어 노트북을 충전하면서 강의를 들을 수 있었습니다. 아쉬웠던 점은 와이파이가 잘 되지 않았습니다. (와이파이에 비밀번호가 걸려있어서 사용하지 못했는데... 비번을 다른 곳에서 알 수 있었나요ㅠㅠ 여하튼 저는 와이파이를 사용하지 못했습니다.) 인터넷이 필요한 강의는 없어서 굳이 필요하진 않았습니다. 개인적으로 아쉬웠던 건, 코틀린으로 설명해주시는 강사분이 계셔서 자바만 알고 있던 저에겐 코틀린을 조금 알고 갔으면 좋았을 것 같다는 생각을 했습니다. 물론, 코틀린을 몰라도 세미나를 듣는 데에는 지장이 없었습니다. 시간이 애매하게 진행되는 행사(12:30~18:30)는 아니었지만 학교나 집에서 판교까지의 거리가 멀어서 밥시간이 애매해서 개인적으로 힘들었지만, 간식과 물, 커피를 제공해주셔서 당 보충하며 강의를 들을 수 있었습니다.
# 네이버 테크 콘서트 강의별 후기
1. Android Studio 설정 -노현석(네이버)
소개: Android Studio 3.6 버전까지 오면서 놓치고 있던 Studio 설정들을 공유합니다. 라이브로 설정을 조작하면서 정보를 진행하는 시간을 가집니다.
1. 있었지만 몰랐던 설정 정보
2. 조금 더 생산성 올리는 방법
>> Quick list
>> Notifications
>> File Colors
>> File Format
>> Break Point
>> Language
>> Layout Editor
>> Live Template
을 안드로이드 스튜디오에서 추가하거나 변경하는 방법을 알려주셨는데 어디서도 들을 수 없는 강의라 정말 재밌게 들었습니다. 개인적으로는 break point에서 condition(조건)을 추가하는 방법이 정말 신기했고 Language에서는 예제를 들어 설명해주셨는데(JSON 형식을 저장한 String에 language를 JSON로 클릭해주면 변하는 내용) 개인적으로 많이 사용할 거 같은 안드로이드 설정이었습니다. 그리고 Notifications을 설명해주면서 이런 것도 있다며 체크하셨을때, 갑자기 안드로이드 스튜디오에서 gradle sync 알람을 팝업으로 띄우는 것이 아니라 소리 알람으로 나와서 진짜 놀랐습니다. 라이브로 설정을 조작하면서 설명해 주셔서 한결 쉽게 볼 수 있었습니다.
2. 예제에서는 알려주지 않는 Model 이야기 -김범준(레이니스트)
소개: 아키텍쳐, 패턴에서 모델은 빠지지 않고 등장합니다. 쉬워 보이지만 또 어렵기도 한 모델에 관하여 예제에는 잘 보이지 않는 내용들을 공유하려 합니다.
며칠 전, 뱅크 샐러드란 어플을 깔았는데 그 서비스를 개발한 개발자분이셔서 진짜 놀랐습니다.
모델에 대해서 알려주실 때 김신입이 개발하는 과정(코드 작성-> 리뷰-> 리뷰 반영)을 통해서 어떻게 개발해야 하는지에 대한 틀을 배웠습니다. 코드 언어가 코틀린이었던 거 같은데 자바만 공부한 저에겐 코드가 직관적으로 들어오지 않아서 코드 부분에서 이해가 조금 힘들었습니다.
아래는 강의를 들으면서 작성한 노트입니다.
1. 레포지토리 패턴(추상화)를 사용하라. 레포지토리? -디자인 패턴 중의 하나 -데이터를 불러오는 로직을 분리시켜 관리하는 것이 목적 -하나의 레포지토리는 하나의 도메인(모델)을 담당한다. -추상화를 통해 테스트에 용이해진다.
소스? 데이터를 불러올 수 있는 모든 외부, Server(Http, socket), Local(db, cache)
데이터를 불러오고 처리하는 역할을 분리 추상화를 통화여 테스트가 용이해지게 되었다.
2. 비지니스 로직(business Logic)을 분리하라. 비즈니스 로직 유저의 행동에 따라 서비스에서 보여주고자 하는 결과를 나타내기 위해 뷰에서 원하는 어떠한 데이터를 만들어 주는 것 >> 비지니스 로직을 프레젠테이션 로직에서 분리해야 하는 이유 프레젠테이션 코드가 커지므로 프레젠테이션의 역할을 분리해줄 필요성이 생김.
=> 프레젠테이션에 집중할 수 있도록 비지니스 로직을 분리 >> 그래서 어떻게 분리할건데? 서비스> 서비스 레이어 패턴 비즈니스 로직의 집합소 개념. 재사용이 용이함. 서비스에서 비즈니스 로직을 통해 데이터를 처리하려면 레포지토리로 데이터를 가져오거나 보냄 다른 서비스를 물고 있을 수도 있음. 재활용이 쉬움. 서비스란 개념은 여러 비즈니스 로직의 집합소 개념이지만 다른 서비스에 따라서 코드가 수정되어야 하므로 유지보수의 어려움이 있을 수 있음. 서비스를 사용할 때는 설계에 있어서 유용하게 사용해야 한다. >>>>Use Case = 하나의 유저 행동에 대한 서비스의 비지니스 로직이 담겨있는 객체. 서로에게 독립적이고 비지니스 로직들 간의 의존성이 없음. 서비스와 마찬가지로 설계가 중요하지만 유지보수, 변경 등의 비용이 적다. > 유즈 케이스를 잘못 사용하는 경우 1. 레포지토리처럼 사용하는 경우 > 기존에 있는 것을 재활용해서 2. 서비스처럼 사용했을 경우 >>>!!! 보통의 경우에는 유저의 행동(비즈니스 로직)과 1:1로 매칭 된다!!!! >> 프레젠테이션에서 비지니스 로직을 분리
3. Exception handling (예외 처리) 예외처리 자체도 비지니스 로직으로 생각할 수도 있다. 도메인 유즈케이스에서 사용할 수 있도록 관련된 곳(데이터)에서 예외를 변환해주어야 할 필요가 있다.
=>>모델을 데이터와 소스로 나눌 수 있고 프레젠터도 도메인으로 나눌 수 있다. CLEAN ARCHITECTURE
3. 안드로이드 개발자 로드맵 -안중환(네이버 웹툰)
소개: 네이버 안드로이드 개발자 3년 차가 되는 과정에서 졸업생은 무엇을 준비하고, 어떤 걸 공부해야 하는지 키워드와 노하우를 공유합니다.
강의 시작하실때 적지 마시고 들어 달라고 하셔서 편하게 들었던 강의입니다. T자형 개발자로 가기 위한 레벨들로 설명해주셨습니다.
DB+OS+네트워크+알고리즘+자료구조를 전부다 "연관 지으며" 공부해야 한다.
Android Developer를 이용하자.
라고 말하셨던 부분이 저에게 가장 필요한 부분이라고 생각했으며 안드로이드 디벨로퍼 문서가 진리라고 거듭 강조하신 것을 보고 나중에 프로젝트를 할 때나 개발을 할 때 그 문서를 중심으로 해야겠다고 생각했습니다. 또, 뒤에 있었던 패널 톡에서 개발자분이 "스택오버플로우는 멀리하고 안드로이드 디벨로퍼 API 문서를 가까이하자"라고 강조해주셔서 치열하게 공부해야겠다고 다짐했습니다.
재밌었던 건 T자형(?) 개발자에서 혼종 개발자(ㅋㅋ)로 변화하는 과정을 거쳐야 한다는 부분이 엄청 다가왔습니다. 아직 T자형 개발자도 아니지만(ㅠㅠ) 어떻게 공부해야 하는지에 대해서 같이 고민해주셔서 많은 도움이 되었습니다.
4. 쪼개지고 나누어지는 안드로이드 -양찬석(Google)
소개: 다양성은 안드로이드 생태계의 핵심 가치입니다. 안드로이드 디바이스 종류는 정말 다양하며, 5G 등 새로운 모바일 기술은 오픈된 안드로이드 생태계를 기반으로 빠르게 발전할 수 있었습니다. 하지만, 안드로이드 다양성은 앱 개발자에게는 영원한 숙제로 남겨졌습니다. 구글은 안드로이드 생태계의 다양성을 유지하면서도 앱 개발자의 수고를 줄이고 사용자가 최적의 경험을 할 수 있도록 많은 노력을 기울이고 있습니다. 다양성과 호환성이라는 두 마리 토끼를 모두 잡기 위해 구글이 힘쓰고 있는 안드로이드 플랫폼 모듈화 및 앱 모듈화 프로젝트를 소개하고 앱 개발 시 염두에 둘 내용을 살펴봅니다.
"안드로이드의 미래를 알기 위해선 안드로이드의 과거를 알아야 한다."란 말씀으로 시작한 세션이었습니다.
안드로이드 프레임워크의 2010년도 원칙 - 사용자가 앱을 종료할 필요가 없음 - 메모리 사용량을 최소화 - 앱 실행 및 다른 앱으로 전환이 빨라야 함 - 선 탑재되는 앱과 동일한 수준의 API 제공
빠른 앱 전환 vs 한정된 메모리라는 굴레에서 "어떤 것을 선택해야 하나"에 대한 숙제가 있었고
그것을 어떻게 해결해왔는지에 대한 설명이었습니다.
10년 후 지금은 "상대방의 앱을 믿을 수 없다...." 제약되는 부분이 생기고 있음. 반 정도의 성공과 실패로 프레임워크가 진행되고 있다.
안드로이드 디바이스 종류 24,000개 폰, 태블릿, 티브이 등등ㅠㅠㅠ >> 호환성 지옥 >>>IT "MAY" WORK ON YOU MACHINES에 도달하게 되고 이를 어떻게 해결할 것인지에 대한 설명도 해주셨습니다.
이로 인해, 안드로이드가 발전하면 장점도 있겠지만 사실 더 무서운 호환성 지옥에 빠질 것이며 많은 개발자들은 이것을 결국 해결할 것이다. 와 같은 주제의 세션이었습니다.
소개: 모바일 서비스에 대해 궁금한 모든 것을 현업 개발, 기획, 디자이너에게 물어보고 답하는 시간입니다.
물어보고 답하는 시간이었는데, 저는 질문을 하지 않아서 다른 사람들의 질문과 해답을 듣는 시간이었습니다. 편하게 들을 수 있어서 너무 좋았고 안드로이드 디자인과 iOS 디자인이 다른데 그에 따른 개발자의 힘든 점을 들었을 때, 뭔가 웃펐습니다. 대학생으로서 프로젝트를 할 때 개발뿐만 아니라 디자인 영역, 기획 영역도 필요한 부분이었는데 패널 톡을 통해서 다양한 이야기를 들을 수 있어서 좋았습니다.
6. 예제로 배우는 안드로이드 카메라
소개: 단순한 사진 촬영부터 사진 편집, 바코드 인식, 얼굴 감지, 영상통화, AR 등 다양한 분야에서 카메라를 이용한 앱을 만들고 있습니다. 구글의 Camera-Basic 예제를 통해 Camera 2 API 구조와 관련 용어에 대해 알아보고, Preview, Image Processing, Capture 등 Use-case 기반으로 이야기합니다. *이런 분이 들으시면 좋습니다. 카메라를 사용하는 앱을 만들고 싶은데 Camera를 쓸 수는 없고, Camera 2를 사용하자니 어려움이 있으신 분
작년 말에 프로젝트를 할 때, camera 2 API를 사용하여 캡처 기능을 만들고자 하였으나 결국 완성하지 못했습니다. 이 세션을 통해서 그때의 프로젝트가 무엇이 잘못되었는지 생각해보면서 들었습니다.
7. 20분 만에 만들어보는 라이브 방송 앱
소개: 크리에이터가 당당히 어린이들의 장래희망으로 등극한 시대. 유튜브, 트위치, 아프리카 TV 등을 통해 시청하는 라이브 방송은 우리 삶의 일부가 되었습니다. 안드로이드 플랫폼에서 '라이브 스트리밍' 앱을 내 손으로 직접 개발해보는 시간을 갖습니다. 이에 필요한 카메라, 미디어 코덱, 미디어 프로토콜에 대해 함께 살펴봅니다.
20분 만에 라이브 방송 앱을 만들기는 쉽지 않은데 빠르게 코드 리뷰를 하며 라이브 방송 앱이 어떻게 구현되어 있는지 볼 수 있어서 직접 만들지 못해서 아쉬웠지만 흐름을 이해할 수 있었습니다.
# 마무리하며
집에 도착해보니 메일로 발표자료 업로드 예정 링크와 설문조사 링크를 보내주셨습니다. 짧지만은 않았던 시간 동안 알찬 강연을 들으면서 안드로이드 개발에 대해 학교에서는 배우지 못한 다양한 팁들을 들을 수 있었습니다!
개인적으로 가장 좋았던 강연은 안드로이드 개발자 로드맵이었습니다! 대학생이라 웹, 앱에 국한되지 않고 자유롭게 배우고 있어 아직 개발자 노선을 정하지 못한 저에겐 실질적인 도움이 되는 시간이었습니다! 또, 팀 프로젝트를 진행하면서 팀원들과 의견 충돌이 났을 때 어떻게 협력하여 진행해야 하는지에 대해서 많은 고민이 있었는데 대학교 프로젝트와는 다른 회사에서의 디자인팀, 개발팀, 기획팀이 회의를 걸쳐 어떻게 실제 프로그램이 만드는지를 직접 들을 수 있어 패널 톡도 정말 재밌게 들었습니다.
NAVER에서 진행하는 행사와 기술 블로그 포스팅은 d2.naver.com에서 볼 수 있다고 합니다. 다음 테크 콘서트는 어떤 주제로 진행될지 확인해보시면 좋을 것 같습니다.
댓글 개