Java8에서부터, 그리고 Kotlin에도 lambda를 지원하면서, 익명 함수를 쓰는 경우가 대폭 늘어났다.

분명 작성해야 하는 code의 양을 줄여준다는 장점이 있지만, 익명 함수, 그리고 익명 클래스를 쓰는 건 VM입장에서 봤을 때 좋은 습관은 아니다.

이번에도 예를 들어, 달력 UI component를 만들 때 달력의 각 날짜에 onTouchListener를 붙인다고 가정해보자.

// 1월부터 그 달의 마지막 날까지
int lastDateOfTheMonth = getLastDateOfTheMonth();
for(int date = 1; date <= lastDateOfTheMonth; date++) {
	Date dateUI = new Date(date); // "날"에 해당하는 새로운 UI component를 만들고
    dateUI.setColor(...); // 기타 등등 설정을 하고
    dateUI.setOnClickListener((v) -> { parent.onTouchDate(date); });
    this.addDate(dateUI);
}

확실히 짧아서 좋은데, 문제는 이 code가 완전한 functional language 기반 위에서 수행되는 것이 아니라, JVM 위에서 수행된다는 점이다.

JVM 구현에 달려있긴 하지만, 위의 code는 일반적으로 아래와 같이 수행되는 셈이다.

// 1월부터 그 달의 마지막 날까지
int lastDateOfTheMonth = getLastDateOfTheMonth();
for(int date = 1; date <= lastDateOfTheMonth; date++) {
	Date dateUI = new Date(date); // "날"에 해당하는 새로운 UI component를 만들고
    dateUI.setColor(...); // 기타 등등 설정을 하고
    dateUI.setOnClickListener(new OnTouchListener() {
    	public void onTouch(View v) {
    		parent.onTouchDate(date);
        }
    });
    this.addDate(dateUI);
}

즉, setOnClickListener를 한 번 부를 때 마다 객체를 하나씩 생성한다.

위의 예에서는 달력이니까 30개 정도의 OnTouchListener를 만든다.

JVM에서 객체를 하나 만들면 거기에 따른 비용을 고려해야 한다.

더군다나 위의 예에서는 그냥 setOnClickListener(this)로 처리해도 되는 code인데....

게다가 요새는 UI 요구사항에 따라 하나의 class안에서 여러 개의 익명 함수, 익명 클래스를 만드는데, 간단한 code도 좋지만 성능도 성능이고, debugging 용이성에 미치는 영향도 잘 고려하는 게 필요하다.

물론, code 읽기도 편하고 쓰기도 편하겠지만, 어차피 같은 생명주기를 가지는 code들이라면 차라리 성능에 초점을 맞추는 걸 추천하는 편이다.