-
Notifications
You must be signed in to change notification settings - Fork 0
⚙ [기술 분석] Image Resizing & Caching
이미지의 경우 데이터 용량이 크기 때문에 필수적으로 리사이징이 필요하다. Porring
은 사진을 기반으로 하는 서비스를 제공하기 때문에 적절한 리사이징 크기를 분석했다.
카메라 화면에서 캡쳐된 이미지를 편집 화면에서 사용하려면 ImageProxy나 Bitmap으로 넘기기에는 데이터의 크기가 너무 크다. 따라서 이미지의 Url을 얻어서 이를 argument로 넘겨야 한다고 판단하였고, 이를 위한 방법이 여러가지 존재하기 때문에 분석을 하였다.
- 장점 : 이미지의 휘발 위험이 낮음. 이후 재사용성이 높음.
- 단점 : 서버 연결이 필요하며 느리다. 데이터 비용이 발생한다.
- 휘발 위험을 고려하지 않으면 오히려 느려지기만 함. 편집 화면에서 사진이 편집된 후에 업로드 되어야 하기 때문에 서버를 사용할 이유가 없다.
- 장점 : 빠르게 접근 가능하여 편집 화면에서 로딩이 빠름.
- 단점 : 메모리를 많이 차지하여 앱이 크래시 나는 경우가 발생할 수 있음.
- 크래시가 나면 안됨. 안정성이 너무 떨어짐.
- 장점 : 임시 파일로 저장하면 캐시가 자동으로 관리되어 편리함.
- 단점 : 저장 공간을 차지한다.
- cacheDir을 사용하여 단기적으로 저장할 수 있고, 저장하고 가져오는 속도가 빠름. 저장 공간이 부족할 때 자동으로 삭제되므로 저장 용량의 문제도 해결 가능함.
fun saveBitmapToCache(context: Context, bitmap: Bitmap, fileName: String): Uri {
val file = File(context.cacheDir, fileName)
file.outputStream().use { out ->
bitmap.compress(Bitmap.CompressFormat.JPEG, 100, out)
}
return Uri.fromFile(file)
}
// 캐시 정리 예시 (오래된 파일 삭제)
fun clearOldCacheFiles(context: Context) {
val cacheDir = context.cacheDir
if (cacheDir.isDirectory) {
cacheDir.listFiles()?.forEach { file ->
if (/* 조건: 오래된 파일 */) file.delete()
}
}
}
가용 메모리에 적합한 예측 가능 크기의 이미지 데이터를 제공하는 소스를 절대적으로 신뢰하지 못한다면, java.lang.OutOfMemory
예외를 방지하기 위해 비트맵 디코딩 전에 비트맵 크기를 확인해야 한다.
이미지를 서브 샘플링하여 더 작은 버전을 메모리에 로드하도록 디코더에 지시하려면 BitmapFactory.Options 객체에서 inSampleSize를 true로 설정하면 됩니다. 예를 들어, 해상도가 2048x1536이고 inSampleSize가 4로 디코딩된 이미지는 약 512x384의 비트맵을 생성합니다. 이 비트맵을 메모리에 로드하면 전체 이미지에 12MB 대신 0.75MB가 사용됩니다(비트맵 구성은 ARGB_8888이라고 가정함). 다음은 타겟 너비와 높이를 기준으로 2의 거듭제곱인 샘플 크기 값을 계산하는 메서드입니다.
즉, 이미지를 화면에 표시할 때 픽셀을 축소해서 보여준다면, 고해상도 이미지를 메모리에 로드할 필요가 없기 때문에 리사이징이 필요하다.
리사이징 후 서버에 업로드하고 다운로드 하면 전송 속도가 빨라진다. 리사이징을 통해서 이미지 파일 크기가 줄어들기 때문이다. 데이터 전송량이 줄어들면 이미지를 업로드하거나 다운로드하는 속도도 빨라지게 된다.
- 고해상도 ⇒ 원본 이미지의 고해상도는 파일 크기가 매우 크다. 리사이징하면 파일의 해상도와 크기가 줄어들면서, 전송할 데이터 양도 줄어든다.
- 서버 비용 ⇒ 서버 입장에서 큰 파일을 저장하고 처리하는 비용이 절감되고, 사용자 데이터 사용량도 줄어들어 사용자 경험이 개선된다.
여기서 리사이징 하는 때는 편집화면으로 넘어갈 때임. 리사이징을 거쳐서 우리가 의도한 해상도를 사용자에게 보여줌으로서 사용자 경험성
을 유지할 수 있도록 하는 게 나을 거라고 판단함.
그리고 업로드 할 때 리사이징을 하면 그만큼 시간을 또 잡아먹히게 되므로 시간 절약을 위함도 있음.
원본은 7360
테스트 결과 460부터 눈에 띄는 화질 저하가 생기기 시작하였다.
720 이상은 육안으로는 확인하기 힘들 정도의 화질 변화가 생겼다.
따라서 resizing은 720 * 900으로 설정하는 것이 가장 적합하다고 판단하였다
인스타에서는 1080
우리의 앱에서는 세로 이미지를 다룸 ⇒ 720으로 결정
Copyright 2024. Team Kolown All Rights Reserved.
- ✅ [기술 결정] Camera
- ✅ [기술 결정] Image Load
- ✅ [기술 결정] UI Toolkit - Copmpose
- ✅ [기술 결정] 데이터 별 UID 생성
- ✅ [기술 결정] Debounce & Paging 사용해서 검색 구현
- ✅ [기술 결정] Google Login
- ✅ [기술 결정] 스켈레톤 UI
- ⚙ [기술 분석] DI
- ⚙ [기술 분석] Image Compress
- ⚙ [기술 분석] 이미지 리사이징
- ⚙ [기술 분석] CameraX API
- ⚙ [기술 분석] Firebase & 랜덤 로딩
- ⚙ [기술 분석] ViewModel 공유
- ⚙ [기술 분석] Firestore 쿼리 전략
- ⚙ [트러블 슈팅] Chip with TextField(Custom with IntrinsicSize)
- ⚙ [트러블 슈팅] WindowInset
- ⚙ [트러블 슈팅] UI 실시간 반영
- ⚙ [트러블 슈팅] IME Padding
- ⚙ [트러블 슈팅] PagingSource reset
- ⚙ [트러블 슈팅] SharedFlow - SnackBar
- ⚙ [트러블 슈팅] Camera와 Lifecycle 동기화