Shared Preference 패키지를 쓰지말아야하는 이유

 
소셜로그인을 구현하면서 사용자가 두번째 로그인부터는 생체인증으로 간단하게 메인으로 진입하게 구현하기위해 사용자 로그인 기록을 로컬 DB에 넣어야했다. 보통 이런정보는 보안이 딱히 중요하지 않고 간단한 정보라 생각해서 iOS의 경우 Userdefault에 저장했고 플러터에서는 Userdefault 랩핑하고있는 Shared Preference 패키지를 사용하려고 했다.
 
하지만 안드로이드 진영 SharedPreference에 이슈가 있다는 것을 알게되어 공식문서를 들여다 보게 되었다.
 

 
shared preferences 는 위와 같이 iOS의 userdefaults를, 안드로이드의 SharedPreferences를 랩핑하고 있는 패키지이다. Userdefaults는 iOS에서 단순한 DB저장 도구로 키-밸류형식으로 저장되고 보안수준이 낮아서 앱의 다크모드라든지 등의 사소한 설정을 저장하는 편이다. 그렇다고 애플에서 직접 오피셜로 쓰지 말라고 하지는 않는다. 문제는 안드로이드에서 SharedPreferences를 쓰지말 것을 공식문서에서 강조하고 있다.
 

코드링크: https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/app/SharedPreferencesImpl.java
 
이유는 몇가지가 있는데 가장 큰 문제는 동시성 환경에 취약하다는 것이다. 자바코드로 작성된 안드로이드 SharedPref 내부코드를 보면 commit 메서드를 통해 로컬 DB에 저장하는데 iOS와 다르게 쓰기 작업을 호출된 같은 스레드에서 작업을 진행한다. (iOS는 따로 코드를 적지 않아도 자동으로 쓰기작업을 다른 큐에 보내어 non-blocking 방식으로 작업한다.) 물론 SharedPref를 통해 작은 정보만 저장하기는 하지만 플러터에서 구현하면 잠깐이나마 메인 스레드를 블로킹할 수도 있다.
 

 
플러터 이슈에 올라온 Don't Use SharedPreferences 에서도 이러한 비동기 이슈를 가장 첫번째 이유로 언급하고 있다. 흠 그래서 유저 로그인 정보 유무를 Shared pref 대신 flutter_secure_storage 패키지를 사용하기로 의사결정을 내렸다.
 
 
한 줄요약
플러터 프로젝트에서 안드로이드를 타겟팅하고 있다면 Shared Preference 패키지를 쓰지말자!