저도 전문가가 아닌지라 확신하기는 어렵습니다만, 요즘 나오는 랙픽스 패치들을 보면서 약간의 의문이 생겨 글을 써봅니다.
랙픽스 제작하여 배포하시는 분들 모두 수고 많으신데, 제 글 때문에 기분 나빠하지 않으셨으면 좋겠습니다.
그리고 틀린 부분이 아주 많을 수 있으니, 전문가분들께서도 많이 지적해주셨으면 좋겠습니다.
그리고 이 글은 옵티머스 G에 대한 이야기로만 한정합니다. 다른 폰에서는 작동한다는 등의 반박은 받지 않겠습니다.
저는 옵티머스 G 젤리빈 사용자입니다.
나름 전에 갤스 쓸 때부터 속도에 좋다는 건 이것저것 다 설치해보고 패치해본 사람으로서 이번에 새로 구매한 옵쥐의 속도도 어떻게 하면 끌어올릴 수 있을까 고민하고 있었습니다. 때맞추어 여러 능력자 분들께서 속도향상 패치를 제작해 배포하셔서, 저도 따라서 설치했습니다. 그런데 효과가 있다고 하시는 많은 분들의 폰과는 달리, 제 폰은 그다지 성능이 향상되었다고 느껴지지 않았습니다.
또, 여러 패치를 중복 적용하다 보니 같은 스크립트가 반복되는 경우도 발생했고, 심지어는 다른 분들은 아무 문제없이 사용하고 계실 은행 어플을 사용할 때에도 루팅을 해제한 상태의 폰을 루팅 폰으로 감지하는 문제까지 발생했습니다.
은행 어플 문제를 먼저 해결하려고 여러 군데를 뒤적거리다가 든 생각이, 내가 은행 어플을 포기해가면서까지 패치를 사용할 정도로 패치의 효과가 큰 것일까 하는 생각이었습니다. 궁금증을 해결하기 위해 패치 파일을 하나하나 열어보기로 했습니다.
대부분의 패치가 bat 파일로 adb push하는 방식으로 진행되기 때문에, bat 파일을 텍스트에디터로 열어보면 어떤 패치 파일이 시스템의 어떤 위치에 있는지 정도는 알 수 있습니다. 대부분이 init.d에 트윅 파일을 넣어서 부팅 시에 스크립트를 작동시키는 방식으로 성능 향상을 꾀하고 있었습니다.
스크립트의 종류로는
등 크게 네 가지로 나눌 수 있었습니다. 이제 실제로 이 스크립트들이 작동을 하는지 살펴보도록 하겠습니다.
0. init.d에 넣은 스크립트가 작동되기는 하는가?
대부분의 속도패치가 init.d에 스크립트를 삽입하는 방식으로 이루어진다는 것을 생각하면, init.d에 넣어둔 스크립트가 활성화되는지를 살펴보는 것이 가장 중요합니다.
기본적으로 옵티머스 G에서는 init.d 스크립트가 작동하지 않습니다. init.d를 사용하기 위해서는 /system/etc/usf_post_boot.sh 파일에 'busybox run-parts /system/etc/init.d'라는 문구를 삽입해야 하고, busybox라는 문구에서 알 수 있듯이 busybox도 설치되어 있어야 합니다. 이 과정을 생략한 채 그냥 init.d 폴더에 스크립트를 집어넣으셨다면 그 스크립트들은 비활성화되어 실제로 작동하지 않습니다. 그런데도 속도가 향상되었다고 느끼신다면 그건 단지 플라시보 효과 때문일지도 모릅니다.
그렇다면 저 busybox 문구를 삽입한 후에는 init.d가 작동하는지 알아보겠습니다. /system/etc/usf_post_boot.sh 맨 아랫줄에 'busybox run-parts /system/etc/init.d'를 삽입하고, init.d 폴더에 파일을 하나 만들었습니다. 파일 내용은 다음과 같습니다.
busybox mount -o remount,rw -t auto /system
busybox mount -o remount,rw -t auto /data
echo "00" > /data/test.log
init.d가 작동되는지만 확인하면 되기 때문에 간단하게 log 파일을 만드는 스크립트만 삽입했습니다. 그 후 폰을 재부팅해보면 data 폴더에 test.log라는 파일이 생성되어 있음을 알 수 있습니다. 이를 통해 busybox 문구를 삽입하면 init.d가 활성화된다는 사실까지는 알 수 있었습니다. 지금까지 가장 중요한 것은 'busybox run-parts /system/etc/init.d' 문구입니다.
그런데 이게 다가 아닙니다. init.d의 퍼미션 설정도 매우 중요합니다. 파일에 접근할 권한을 설정해주는 것이 permission입니다. 기본적으로 퍼미션은 read, write, execute의 세 가지 권한을 의미합니다. 누가 권한을 갖느냐에 따라 그 값이 4, 2, 1로 나뉘는데, 이에 대한 자세한 설명은 이 글과 큰 관계가 없으니 예전에 제가 블로그에 썼던 글(http://julians.tistory.com/44)로 대체합니다.
init.d 스크립트는 실제로 실행되는 것들이기 때문에 퍼미션을 줄 때 755 이상을 주어야 스크립트가 제대로 작동한다는 것을 알 수 있습니다. 최소한 execute 권한은 누구에게나 주어야 한다는 것이지요.
한 줄 요약 : init.d 활성화 문구와 함께 퍼미션 설정을 잘 해주면 init.d 스크립트를 이용할 수 있다.
1. setprop을 통한 property 수정 방식은 실제로 작동하는가?
가끔씩 기기 모델명이나 dpi등을 수정하고자 할 때 우리는 대부분 직접 build.prop을 수정하는 과정을 거칩니다. 그런데 이 파일을 건드리는 것은 위험 부담도 크고, 또 이미 존재하는 코드를 트윅에서 중복 적용하는 경우도 발생할 수 있습니다. 그래서 build.prop 파일을 직접 수정하는 대신에 사용되는 방법이 setprop 명령을 사용한 system property 수정 방식입니다. 그런데, 이 방식이 실제 옵티머스 G에서 작동이 되는지도 의문이 들었습니다.
이를 확인해보기 위해 adb를 사용해 폰으로 접속했습니다. 그 후 getprop 명령을 사용했습니다. getprop 명령은 폰의 properties 전부를 화면에 출력해주는 기능을 합니다.
>adb shell
root@android:/ # getprop
...(전략)...
[ro.product.board]: [gee]
[ro.product.brand]: [lge]
[ro.product.cpu.abi2]: [armeabi]
[ro.product.cpu.abi]: [armeabi-v7a]
[ro.product.device]: [geehrc]
[ro.product.locale.language]: [ko]
[ro.product.locale.region]: [KR]
[ro.product.manufacturer]: [LGE]
[ro.product.model]: [LG-F180K]
[ro.product.name]: [geehrc_kt_kr]
...(후략)...
root@android:/ #
이 명령을 사용하면 폰의 설정 전부가 위와 같이 화면에 출력됩니다. 그런데 이 설정들 속에 우리가 setprop을 이용하여 삽입한 문구들이 들어있는지 살펴보면, 없습니다. 그래서 제가 하나하나씩 adb shell에 setprop명령을 직접 넣어 property를 추가한 뒤, 다시 getprop을 실행해 보았습니다. 그랬더니 비로소 property들이 나타났습니다. 이는 부팅 과정에서 실행되는 init.d를 통해서는 property가 추가되지 못했다는 것을 암시합니다. 그래서 저는 setprop을 통한 property의 수정이 과연 실제로 이루어지는지 의구심이 들었습니다.
그리고 xda의 이 글(http://forum.xda-developers.com/showthread.php?t=997521)에서는, 적어도 ro. 로 시작하는 property는 이 방법으로 수정할 수 없다고 이야기합니다. ro는 Read-Only의 약자로서, 말 그대로 읽기 전용 property이기 때문에 setprop을 통해 수정이 불가능하다는 것입니다.
이를 종합했을 때 제가 낸 결론은, setprop을 이용하는 스크립트는 그 영향이 매우 미미하거나, 심지어는 아예 없을 수도 있다는 것입니다.
2. echo "foo bar" > /system/proc/sys/... 의 방식으로 파일 내용을 수정하는 방식은 제대로 작동하는가?
결론만 먼저 말씀드리자면, 아이스크림 샌드위치 이후의 OS에서 이 방식의 스크립트는 아무 효과가 없습니다.
우선 echo "foo bar" > /system/proc/sys/... 문구의 의미부터 말씀드리자면, "foo bar"라는 문구를 넣은 파일을 /system/proc/sys/에 ...라는 파일로 생성하라는 의미입니다. 그런데 여기서 중요한 점이 하나 있습니다. 그것은 바로 아이스크림 샌드위치 이후로 /system/proc 디렉토리와 /system/proc/sys 디렉토리는 모두 쓰기 권한이 없다는 점입니다. 아무리 foo bar라는 문구를 쓰고 싶어도 권한이 없기 때문에 실제로는 헛발질에 그치게 됩니다. 때문에 이러한 방식으로 구성된 스크립트는 적어도 옵티머스 G에서는 작동되지 않을 가능성이 매우 높습니다.
3. nicelevel을 상승시키는 방법을 통한 속도 트윅은 제대로 작동하는가?
nicelevel을 활용하는 코드를 포함한 많은 init.d 스크립트들은 xda에서 가져와 그대로 사용하신 경우가 많을 것입니다.
구글에 Loopy Smoothness Tweak이라 검색하면 수많은 스크립트들이 검색됩니다. 대포적인 것이 http://forum.xda-developers.com/showthread.php?t=1205744에 있는 스크립트인데, 이 코드를 그대로 가져와 사용하는 경우도 여럿 있는 것으로 추측됩니다.
그런데 이 코드는 이 코드 자체로 완성된 코드가 아닙니다. 링크를 따라가 보시면 알겠지만, USER_LAUNCHER 환경 변수에는 사용자가 어떤 런처 앱을 사용하는지에 따라 다른 값이 들어가야합니다. 그리고 이 값의 디폴트 값은 null입니다. 이 상태의 코드를 그대로 옮겨다 쓰면 런처를 지정해주지 않았기 때문에 런처에 적용되는 트윅은 작동하지 않게 되는 것입니다. 또한, 그 이후에 나타나는 코드들에도 빈 칸이 다수 존재합니다. 이는 사용자 개개인에 맞추어 스크립트를 수정해 사용하라는 의미를 담고 있습니다. 런처의 경우에도 순정을 사용하지 않는 분들도 많으실테고, sms 어플의 경우도 go sms 등 여러 앱을 사용하고 있으실텐데, 이러한 점은 전혀 반영되어 있지 않습니다.
스크립트가 전혀 작동하지 않는 것은 아니지만, 개개인에 맞춘 최적화가 부족하기 때문에 큰 효과를 기대하기는 어려울 것입니다.
4. zipalign을 통한 메모리 효율성 증대
이 부분이 메모리와 관련하여 가장 큰 효과를 볼 수 있는 부분일 것입니다. Aligning이란, 32비트 컴퓨터의 1word가 4byte로 이루어졌다는 점에 착안하여 apk의 내부 파일 배치 구조를 4의 배수에 맞추어 재배치함으로써 메모리가 word 단위로 앱을 읽어들이도록 만드는 것을 말합니다. Align을 하면 좋은 점은, 데이터를 word 단위로 배치함으로써 메모리가 앱을 읽어들이는 속도가 증가한다는 점과, 또 이러한 방식으로 앱을 읽으들인다면 메모리를 절약하는 데에도 도움이 된다는 점입니다.
따라서 zipalign은 어느 정도 속도 향상에 도움이 된다고 볼 수 있습니다.
5. Miscellaneous
이외에도 스크립트 오타나 busybox에 탑재된 명령어를 사용할 때는 명령어 앞에 busybox를 붙여주어야 하는데 이를 무시하여 명령이 실행되지 않는 경우 등의 문제점도 추가로 존재했습니다.
쓰다보니 쓸데없이 글이 길어졌네요.
다시 한 번 말씀드리지만, 저는 전문가가 아닙니다. 오히려 허접에 가깝습니다. 그냥 많은 분들이 하시는 말씀을 눈동냥 귀동냥해서 얻은 잡지식으로 끄적여 본 것이니, 틀린 점은 많이 지적해주세요. 하지만 근거없는 비방이나 폭언은 제발 삼가주셨으면 좋겠습니다.
감사합니다.
