이래저래 뒤져보면 findViewById의 비용이 높아서 성능개선을 위해
findViewById를 통하여 가져다 사용하게 되는 하위 view를 wrapper를 만들어
row item view에 setTag를 이용하여 별도로 보관해놓고 사용하는 팁이 매우 많다.
하지만 하나 의문이 드는 것이, 정말 저 비용이라는 것이 wrapper를 만들고 생성하고 유지하는데 필요한
개발자의 노력과 (적겠지만) 추가로 발생하는 객체생성비용이 그렇게까지 유용할 정도일까 싶다.
findViewById 메소드의 소스를 직접 까보진 못했지만, map이든 set이든 list든 array든 상관없이
껏 해봐야 몇 개의 하위 view를 가지니까 full linear search를 하더라도 비용이 그다지 클 것 같지는 않다.
이에 대해 확실한 판단을 하려면 결국 소스를 내려받아서 까보는 수밖에 없을 듯 하다.
정말 효과가 크다면 당연히 사용해야하는 패턴일 수도 있겠지만
미미하다면 개발자의 작업시간 증가와 소스 코드의 가독성 저하를 감수할 필요가 있나 싶다.
일단 소스코드를 다운 받아야 확인이 될텐데 시간이 되려나;;
findViewById를 통하여 가져다 사용하게 되는 하위 view를 wrapper를 만들어
row item view에 setTag를 이용하여 별도로 보관해놓고 사용하는 팁이 매우 많다.
하지만 하나 의문이 드는 것이, 정말 저 비용이라는 것이 wrapper를 만들고 생성하고 유지하는데 필요한
개발자의 노력과 (적겠지만) 추가로 발생하는 객체생성비용이 그렇게까지 유용할 정도일까 싶다.
findViewById 메소드의 소스를 직접 까보진 못했지만, map이든 set이든 list든 array든 상관없이
껏 해봐야 몇 개의 하위 view를 가지니까 full linear search를 하더라도 비용이 그다지 클 것 같지는 않다.
이에 대해 확실한 판단을 하려면 결국 소스를 내려받아서 까보는 수밖에 없을 듯 하다.
정말 효과가 크다면 당연히 사용해야하는 패턴일 수도 있겠지만
미미하다면 개발자의 작업시간 증가와 소스 코드의 가독성 저하를 감수할 필요가 있나 싶다.
일단 소스코드를 다운 받아야 확인이 될텐데 시간이 되려나;;
