출처: Android Open Source code, dalvik/doc/dexopt.hml

Dalvik Optimization and Verification


Dalvik Optimization and Verification with dexopt


  • class 데이터(특히 bytecode), 는 시스템 메모리 사용을 최소화하기 위해 프로세스간 공유함
  • app을 띄울때 응답성을 높이기 위해 overhead를 줄임
  • class 데이터를 각 개개별의 파일에 저장할 경우 낭비가 심하여, 이를 방지함
  • class 데이터 파싱을 하면 class 로딩 시에 많은 overhead가 발생하므로, C 타입의 data value로 처리하는게 유리함
  • Bytecode verification은 필요하나 느리므로, app의 실행외에 verify 하는 방향으로 추진
  • Bytecode 최적화는 속도와 배터리 수명을 위해 매우 중요함
  • 보안을 위해 프로세스는 공유 코드를 못 고침

일반적인 VM implementation은 compressed archive 에서 (uncompressed) individual classes를 꺼내와 heap에 저장함.
이는 곧, 모든 프로세스마다 각 class들의 카피를 가지고 있고, app이 시작할때 코드의 압축을 풀어야 하기 때문에 느림.  반면에 로컬 heap에 bytecode를 가지고 있으면, rewrite 하기 쉽다는 장점이 있음
 

결론적으로 다음과 같은 결과물이 필요하다.


  • multiple class들은 하나의 "DEX" file로 통합됨
  • DEX 파일은 read-only로 맵핑되며 프로세스간에 공유됨
  • Byte ordering 과 word alignment는 local system에 맞게 변경가능함
  • Bytecode verification은 필요하나 "pre-verify"를 함
  • bytecode를 rewrite해야 하는 최적화는 반드시 선행되어야 함

VM Operation


어플리케이션 코드는 어플이름.jar 혹은 어플이름.apk 로 시스템이 전달되는데, 이는 단지 어플이름.zip 에 meta-data를 첨가한 것이다.  Dalvik DEX data 파일은 항상 clases.dex라고 표기된다.

bytecode는 zip 형태로 데이터가 압축되어 있고, 파일의 시작이 word-aligned가 아닐 수 있으므로, 메모리 맵핑되거나 zip 파일로부터 곧바로 실행이 불가능하다.  그러므로 classes.dex를 압축해제 하고 필요한 다른 액션(예를 들어 realignment, optimization, verification등)을 취해줘야 한다.  그럼 누가 이런 결과물을 만들어내고 저장해야 하는가??


Preparation


"preapred" DEX file을 생성하는데는 적어도 3가지의 방법이 있다.


  1. VM 이 'Just-In-Time'(보통 JIT)을 통해 dalvik-cache 디렉터리에 결과물을 저장. desktop이나 engineering-only 디바이스에 적합하다.(dalvik-cache의 퍼미션 문제로 양산품에는 적용불가함)
  2. dalvik-cache에 쓸 권한을 가진 시스템 인스톨러가 어플리케이션이 처음 추가되었을 때 한다. 
  3. classes.dex를 제외한 관련 jar나 apk파일들을 이용해  빌드시스템이 선행적으로 진행한다. optimized DEX 파일은 오리지널 zip 아카이브 옆에 놓이며, 시스템 이미지의 일부분이 된다.

dalvik-cache 디렉터리는 $ANDROID_DATA/data/dalvik-cache이다.  이 디렉터리 안의 파일 이름은 source DEX의 full path를 사용하며, 이 디렉터리는 system을 owner로 0771 권한을 가지고 있다.  안의 optimized DEX 파일들은 system이 owner이며 application 이 gropu으로, 0644 권한을 가지고 있다.




'안드로이드 > 프레임워크' 카테고리의 다른 글

Bionic libc (2)  (0) 2012.11.08
Bionic libc  (0) 2012.10.30
안드로이드 init.rc (oom_adj값)  (0) 2012.09.27
안드로이드 바인더 ipc  (0) 2011.10.23
안드로이드 프레임워크 *Java에서 전처리기 사용하기*  (0) 2011.06.06
Posted by code cat
안드로이드/포팅2012. 4. 7. 17:15

출처: http://developer.sonymobile.com/wp/2012/03/30/learn-about-the-technical-differences-between-gingerbread-and-ics/


Learn about the technical differences between Gingerbread and ICS [Updated]



Ever thought about how Gingerbread (GB) and Ice Cream Sandwich (ICS) platforms differ on a technical level? In this blog post, we’ll describe some of the technical differences between GB and ICS, and what the differences in the user experience might be. This way you can decide if ICS is right for you, or if you prefer to stay on Gingerbread. Maybe you will prefer the new UI in ICS, or do you give a higher priority to the extreme stability of the Gingerbread platform? Read more after the jump!


Now as you might have seen, we’ve continuously kept you updated on our work with the ICS upgrade, and we started by telling you about what we do to get the latest software release from Google working on our Xperia™ smartphones in the article Ice Cream Sandwich – from source code release to software upgrade. Then we released ICS alpha and ICS beta versions of the coming software upgrade.

However, although ICS is new and compelling in many ways, we would like all of our users to make an informed decision when selecting what Android™ software to use. We are actually proud to say that our Gingerbread software is very stable and has great performance, so it’s not a bad idea to stay on this release. Ice Cream Sandwich is more intensive, for example in terms of resource usage. As smartphones become more capable, our own applications, as well as the Google Mobile Services (GMS) applications, are becoming more advanced, which means that they require more CPU power, run more network activities and use more RAM. On the other hand, ICS brings a refined UI and some nice new features as described below.


Comparison of the look and feel in Gingerbread (left) and Ice Cream Sandwich (right).

New features in ICS
From a UI perspective, ICS is based on a new look and feel, the Holo theme. In order to accommodate the new look of Android, we decided to do an extensive touch up of our own assets, since the graphical assets of the Holo theme cannot be changed in any way as stated in the Android Compatibility Definition Document (CDD). New looks have been added in the platform layer as well as in the application layer. All in all, well over a thousand icons have been modified. In addition, we have deployed new wallpapers and application backgrounds, which harmonise more with the flatter graphical structures of ICS.

In ICS, the activity manager has a completely new UI, where all running apps are shown as thumbnails in a list. To close an activity, you can simply swipe it out of the list. ICS also introduces a face recognition app as a way to unlock the phone, called Face Unlock. Face Unlock uses the front-facing camera and advanced object recognition algorithms. It is included in our ICS upgrade for all phones that have a front-facing camera.

The contact list will show more information about the contacts, including updates from social networks. In the calendar, colour coding has been added and it is now possible to zoom. There is also support for a new type of voicemail that is more visual, offering transcriptions of voice messages.

When it comes to ICS, it’s a major upgrade of Android™, and there are a lot of things that have changed compared to the Gingerbread release. Some of these changes affect the performance and stability of the system, for example by using more CPU power and RAM. ICS was developed with Galaxy Nexus in mind, which is based on a TI platform with dual-core processor and 1GB RAM. We are now adapting ICS to run on our 2011 Xperia™ smartphones, which are all built on a Qualcomm platform with single core and 512 MB RAM. This means that in some cases, the resource usage in ICS is heavier on the system compared to Gingerbread. The following sections identify some key areas where there is a difference between ICS and Gingerbread.

Increased RAM usage
In general, it can be said that the RAM is the working memory in the phone, used by running processes in contrast to the flash memory, which is mainly used to store things. As you might understand, this is a simplified explanation and might not be entirely true in all cases. However, it can serve as a help to understand the difference between the RAM and the flash memory of the phone. To see how much RAM is currently used, go to Applications in the Settings app of your Xperia™ phone.

Now, let’s look at how the RAM is used. Out of our 512MB RAM, about a third is used for functions that require a dedicated memory slot to operate fast enough. For example, this is the case for certain multimedia functions. The remaining space, which is at least 340MB, is reserved for the Linux user space, as required in the Android Compatibility Definition Document (CDD). Within the Linux user space, functions like the activity manager and Home screen app are running.

Another interesting thing is that many apps use slightly more RAM in ICS. For example, the web browser is quite intensive, and our measurements indicate that it uses 20-30MB more in ICS compared to Gingerbread. All in all, there are a lot of changes that together result in greater RAM requirement.


Illustration of the RAM usage.

When running low on RAM, typically with less than approximately 40MB left, the activity manager will start to close processes according to priority. At first, idle background activities are killed. The last thing to be closed down is the foreground activity. We have described this briefly in the table below. For more information, check out Android developers. (Please note that all figures mentioned about RAM usage are approximations and will differ depending on phone model and use case.)


Table showing different types of processes. When running out of RAM, the activity manager starts shutting down processes from the bottom and up, so that the last things to close are foreground and persistent activities.

Processes that are closed will obviously have to be restarted when the user enters the app again, which takes time and slows the system down. For example, when running a heavy game that uses all available RAM, the activity manager will be forced to kill all processes running in the background. This might include vital functions like the dialler and even the Home screen application. When you exit your game, there is a risk that the phone is perceived as slow, since the Home screen app will have to be restarted, just like every other activity you access afterwards.

Slower interaction with the SQL database
Another change in ICS compared to Gingerbread is that Google has moved a lot of the SQL handling from the native to the Java layer. In our internal studies, we have seen that read and write operations to the SQL database takes longer time, which slows down the apps. Many applications perform a lot of SQL operations when started, which greatly impacts the start-up time.

According to good practice, database operations or http requests should not be performed in the main thread. However, we know that there are quite a few applications that perform these kinds of operations directly in the main thread, which might cause them to hold up other operations. Also, when reading feedback on ICS software out on the market now, we’ve seen comments about people having problems with some applications and games.

If an operation takes too long, there is a risk of getting an Application Not Responding (ANR) as a result. An ANR occurs when an application doesn’t answer an intent, or responds to an input event, within a certain time limit. In case of intent, the time out is set to five seconds. For the input event, such as screen touch or button click, it’s ten seconds.

This can result in a user experience that is perceived as slower and less stable, due to longer response times and increased ANRs.

Introducing full hardware acceleration
Yet another change in ICS, is that the graphics hardware acceleration is on by default for all apps from API level 14. For apps at lower API levels, it can be turned on in the manifest with the attribute android:hardwareAccelerated=”true”. Hardware acceleration means that the GPU is used to render graphics, which enables a smooth user interface. However, it also results in at need to load additional graphic libraries for certain apps, which makes them use even more RAM.

When we performed internal tests on our applications, we saw that the Settings app consumed 1-2MB more RAM, and actually took longer time to start with HW acceleration, compared to without. Once the app is running, the UI is HW accelerated, but unless the app performs advanced graphics, the user will not see the difference.

Another effect of the hardware acceleration is that it can make the battery drain faster in some cases. An example of this is video playback, where the hardware acceleration requires every video frame to be run through the GPU, thus making the system use more power than it would have without HW acceleration.

As a developer, you should therefore evaluate if HW acceleration is required or not, as it comes with a cost in terms of RAM usage, start-up time and possibly even battery duration which can have negative effects on the user experience. You can read more about hardware acceleration in Ice Cream Sandwich on the Android Developers blog.

So, what will be your platform of choice? We hope this article clarifies some of the aspects to consider when making the decision. As always, we are eager to hear your opinion, so drop us a comment below and let us know! For more details on timing and practicalities on the ICS upgrade, check out this latest post on the Sony Xperia™ Product Blog.

Updated – comment from the Developer World team:

We we would like to clarify that above mentioned “challenges” have already been addressed by our SW engineering teams. For instance, we have not only optimised the RAM management by making the RAM usage for internal apps as good as possible, but we will also introduce a Performance assistant at start up when running ICS. In this Performance assistant, you can enable and disable certain services that you might not want to run on your phone, in order to optimise the performance of your phone.

We have also worked with quite a few partners in regards to architecture optimisations for SQL handling. In addition, we have also optimised the hardware usage. And as a result of this article, a number of app developers have notified us that they are evaluating if HW optimisation will be needed or not for their apps.

The aim of this article was to share our knowledge regarding the different characteristics for ICS and Gingerbread in an open way, as we strive to have an open communication with the developer community. All in all, we would like to point out that it’s our clear aim to deliver an as good ICS update as ever possible. As you might have seen on the Sony Xperia Product Blog, we’re not far from releasing it now. Thanks for all the feedback!

Posted by code cat
안드로이드/포팅2012. 4. 5. 14:58


Android 소스를 다운 받고 환경 구축을 할 때, jdk를 깔아야 한다.


Android 웹사이트에는 다음과 같이 하라고 나와 있다.

Installing the JDK

The Sun JDK is no longer in Ubuntu's main package repository. In order to download it, you need to add the appropriate repository and indicate to the system which JDK should be used.

Java 6: for Gingerbread and newer
$ sudo add-apt-repository "deb http://archive.canonical.com/ lucid partner"
$ sudo apt-get update
$ sudo apt-get install sun-java6-jdk

Java 5: for Froyo and older
$ sudo add-apt-repository "deb http://archive.ubuntu.com/ubuntu hardy main multiverse"
$ sudo add-apt-repository "deb http://archive.ubuntu.com/ubuntu hardy-updates main multiverse"
$ sudo apt-get update
$ sudo apt-get install sun-java5-jdk

Note: The lunch command in the build step will ensure that the Sun JDK is used instead of any previously installed JDK.


위와 같은 방법은 우분투 10.x 에서는 잘 되나, 11.x(11.04 특히)에서는 되지 않는다.


그럴 땐 다음과 같이 하면  jdk6을 깔 수 있다.


sudo add-apt-repository ppa:ferramroberto/java
sudo apt-get update
sudo apt-get install sun-java6-jdk sun-java6-plugin


Posted by code cat
안드로이드/포팅2012. 3. 18. 15:25
안드로이드 일을 하다보면 안드로이드에서 필요로 하는 ramdisk.img 쪽에 대한 디버깅이 필요할 때가 있다.  이럴 때는, 간단하게, 다음과 같이 하자.

1. 우선 ramdisk.img를 자신의 리눅스 환경으로 카피해 오고 백업을 만들자.
cp ramdisk.img  ramdisk.img.back
mkdir mytemp
cd mytemp

2. ramdisk.img를 풀자.
gunzip -c ../ramdisk.img | cpio -i

3. 디버깅을 하던 파일을 바꾸던 필요한 작업을 하자.

4. 다시 ramdisk.img로 패킹하자.
find . | cpio -o -H newc | gzip > ../ramdisk.img

mkbootimg로 아마 다시 패킹해야 할 텐데, mkbootimg 치면 사용법 나오니 그건 알아서 하자.

Posted by code cat
출처: 인사이드 안드로이드(위키북스출판)

RPC code & RPC data
서비스 클라이언트는 서비스서버에 존재하는 서비스의 함수를 사용하기 위해,
각 함수에 해당하는 식별자를 바인더 IPC데이터에 담아 전달 <-- RPC 코드
함수의 인자 역시 IPC데이터에 담아 전달                           <-- RPC 데이터

즉, 서비스 서버가 가진 서비스의 함수를 호출할려면, PRC코드를 알아야 함.

바인더 어드레싱
context manager : 다양한 서비를 모두 목록화해서 관리함.  서비스마다 핸들(바인더 IPC의 목적지 주소로 사용)이라는 번호값을 할당. 서비스의 추가/검색등의 관리기능을 수행.  %context manager의 핸들값은 0으로 지정되어 있음
바인더 드라이버는 IPC 데이터의 핸들을 가지고 서비스 서버를 찾는데, 이러한 과정을 바인더 어드레싱이라 함.

바인더 어드레싱을 위해 서비스 서버는 자신이 가진 서비스에 대한 접근 정보를 컨텍스트 매니저에 등록해야함.
서비스서버는 ADD_SERVICE라는 RPC코드와 등록할 서비스 이름(RPC데이터), 그리고 핸들을 0으로 지정하고IPC데이터에 실어 바인더 드라이버에 전달함.
바인더 드라이버는 먼저 핸들 0에 해당하는 바인더 노드를 찾음. 핸들 0에 해당하는 바인더 노드를 context manager를 의미하기 때문에 서비스 서버는 IPC데이터를 context manager에 전달함.
이후 바인더 드라이버는 서비스서버의 서비스 A에 해당하는 바인더 노드를 하나 생성함.  그리고 contenxt manager가 생성된 바인더 노드를 알수 있게 바인더 노드 참조 데이터를 생성해 해당 노드를 연결함.
참조 데이터는 생성된 순서대로 번호가 매겨지고, 이 번호는 ipc데이터에 담겨 context manger로 전달됨
context manager는 ipc데이터에 들어있는 서비스 이름과 바인더 노드의 번호를 서비스 리스트에 등록.

 %바인더 노드는 바인더 드라이버내 자료구조이며, 서비스마다 하나씩 존재함. 그리고 프로세스마다 바인더 노드들을 리스트로 가진다.(바인더 노드는 ipc의 대상이 되는 프로세스를 찾기 위한 식별자 정도로 이해하면 됨)

프로세스 관점에서의 서비스 사용
클라이언트던 서버 입장이던 다음과 같은 공통 작업을 거친다.
1. 바인더 드라이버 열기 open()함수 호출
2. IPC 데이터/응답 데이터 수신 버퍼 확보 mmap()함수 호출
3. 데이터 송신을 위한 ioctl()함수 호출

바인더 드라이버 관점에서의 서비스 사용
...

'안드로이드 > 프레임워크' 카테고리의 다른 글

Bionic libc (2)  (0) 2012.11.08
Bionic libc  (0) 2012.10.30
안드로이드 init.rc (oom_adj값)  (0) 2012.09.27
Dalvik Virtual Machine 와 odex  (0) 2012.08.13
안드로이드 프레임워크 *Java에서 전처리기 사용하기*  (0) 2011.06.06
Posted by code cat
애플리케이션용 자바 프로그래밍이나 일반 자바 프로그래밍 관련은 다른 방법으로 컴파일 가능하다. 그러나..

안드로이드 프레임워크단이고, ant 아닌 android용 make라면 다음과 같은 방법으로 가능하다.

자바 단에서

public static final boolean TARGET_PRODUCT = flase;


로 정의하고,

 분기컴파일이 필요한 부분에 가서,

if (TARGET_PRODUCT) {

// 코드 내용, 이 부분은 false로 남아있을 경우, 컴파일 할때 사라짐.

}



그리고 해당 make 파일에서 해당 product에 따라 간단히 awk  나 sed로 저기 fasle 부분만 바꿔주는 경우로 하면 된다.  자바도 컴파일할때 최적화를 하기에 저렇게 절대로 실행이 안되는 부분(상기 TARGET_PRODUCT이 적용 안되는 경우) 컴파일 할 때 생략한다.

/* 커맨트 추가
 원래는 안드로이드에서 쓰는 property_get() (system/core/include/cutils/properties.h 에 정의)를 product에 맞는 프로퍼티를 설정해 놓고 거기에 맞게 쓸까 했는데, 이러면 전처리기라기보단 그냥 분기실행 같기도 하고, 프로퍼티를 저런 식으로 써도 되는지 몰라서 안했습니다.

 이 방법에 문제라면 product종류가 2개 이상이면 조금 복잡해지는거 같습니다.  안드로이드가 아닌 그냥 자바라면 디펜던시 인젝션 하는 방법으로 하면 간단히 해결 되는 걸로 알고 있습니다.(이 부분은 해당업무가 바뀌면 올리겠습니다 ㅎㅎ)
*/

'안드로이드 > 프레임워크' 카테고리의 다른 글

Bionic libc (2)  (0) 2012.11.08
Bionic libc  (0) 2012.10.30
안드로이드 init.rc (oom_adj값)  (0) 2012.09.27
Dalvik Virtual Machine 와 odex  (0) 2012.08.13
안드로이드 바인더 ipc  (0) 2011.10.23
Posted by code cat
안드로이드/포팅2011. 4. 24. 16:03

하드웨어 설정 
cat /proc/version : 커널 버전
cat /proc/cpuinfo : 프로세서 정보. CPU 타입, 모델, 제조사 등
cat /proc/meminfo : 메모리 정보. 실제 메모리 및 가상 메모리
cat /proc/devices : 현재 커널에 설정되어 있는 장치 목록
mount : 마운트된 모든 장치 정보
df : 하드디스크 사용량
cat /proc/filesystems : 커널에 설정되어 있는 파일시스템 목록
cat /proc/swaps : 스왑 파티션의 크기와 사용량
cat /proc/interrupts : 장치가 사용중인 인터럽트(IRQ) 목록 표시
cat /proc/ioports : 현재 사용중인 Input/Output 포트
cat /proc/loadavg : 시스템의 평균부하량
cat /proc/partitions : 파티션 정보
cat /proc/uptime : 시스템이 얼마나 살아있었는지.
cat /proc/stat : 시스템 상태에 관한 다양한 정보. CPU 사용통계, 부팅이후 page fault 발생횟수 등
cat /proc/zoneinfo : ZONEINFO ?
dmesg : 시스템 부팅시 나왔던 메시지
ps : 실행중인 프로세스 정보
ps -p -t : 프로세스와 쓰레드 목록
set 또는 printenv : 환경설정값 출력

시스템 리소스 사용 현황
vmstat : 시스템의 리소스 상황 모니터링. CPU, I/O, 메모리 등
cat /proc/diskstats : 디스크 utilization과 throuthput. 즉 디스크 IO 현황
top : 시스템의 프로세스 상황 모니터링. 프로세스별 CPU 사용량, 메모리와 스왑 사용량 등
procrank : 프로세스별 메모리(VSS,RSS,USS, PSS)
dumpsys meminfo [PID] : 해당 프로세스의 메모리 상세 정보
cat /proc/[PID]/stat : 해당 프로세스에 대한 정보. 시작시간, 상태, CPU 사용량 등
cat /proc/[PID]/maps : 해당 프로세스의 메모리 맵 정보
cat /proc/vmstat : 버추얼 메모리 통계?
librank : 라이브러리별 메모리 사용량?

네트워크 관련
cat /proc/net/netlink : 네트워크 정보
netcfg : 네트워크 인터페이스와 IP주소 목록
netstat : 네트워크 연결상태 확인
nc : 네트워크용 cat 명령어(netcat)
ifconfig : 네트워크 인터페이스 설정 정보. 장치명을 파라미터로 받음. IP 주소, 서브넷마스크 등
tcpdump : 실시간 패킷 모니터링
iftop : 네트워크를 위한 top
route : 해당 호스트까지 연결하는 중간 경로 정보인 라우팅 테이블 표시
ping : 원격 호스트와의 연결 테스트
cat /proc/net/route : Routes

안드로이드 제공
logcat : 로그캣 보기
pm : package manager의 약자. 패키지/permission/instrumentation/feature 목록, 패키지 설치/제거 등
am : activity manager의 약자. 액티비티 시작, Intent 브로드캐스팅, Instrumentation 시작, profiling 시작/중지 등
service : 안드로이드 서비스 목록 표시, 서비스에 명령 전달
monkey : 애플리케이션에 랜덤 이벤트 발생시킴. 사용자 이벤트, 시스템 이벤트의 무작위 발행
cat /data/anr/traces.txt : VM TRACES (쓰레드 덤프)
cat /proc/binder/proc/[PID] : 바인더 프로세스 상태
cat /proc/binder/xxx : 바인더 관련 정보(xxx는 transactions, transaction_log, failed_transaction_log, stats 등)
cat /data/system/packages.xml : 설치된 패키지 세팅 정보
setprop : system property 세팅
getprop : 세팅된 system property 목록 출력


종합 리포트
dumpsys [service]: app/service 상태정보 덤프. 서비스별로 추가 파라미터 받을 수 있음
dumpstate : device 상태정보 덤프(cpu,mem,ps 등). 상태정보를 추출하는 여러 명령어들의 조합으로 구성
dumpcrash : 애플리케이션이 crash될 때의 상태정보 덤프?
bugreport : logcat+dumpsys+dumpstate

출처: http://ecogeo.tistory.com/256
 
Posted by code cat