code cat

출처: 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!

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

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

위와 같은 방법은 우분투 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

정적 라이브러리

컴파일 시 링커로 라이브러리의 오브젝트 코드를 만들고자 하는 타겟 바이너리에 추가된다.

동적 라이브러리

컴파일 시, 라이브러리가 사용된 곳에 공유 라이브러리를 쓴다고 해놓고, 런타임시 동적링크로 링크한다.

정적 라이브러리 만들기

언제나와 같이 예제로 살펴보자.
우선 foo1.c라는 파일을 하나 만들어 다음과 같이 넣어보자.

#include <stdio.h> void foo1() { printf("Hello World\n"); }

자 이제는 foo2.c를 만들어 다음과 같이 만들자.

#include <stdio.h> void foo2() { printf("It's foo2 greeting!\n"); }

마지막으로 이 둘을 interface해 줄 역활의 foolib.h을 만들자.

void foo_1(void); void foo_2(void);

코드 입력을 다 끝냈으면 이제 foo1.c와 foo2.c를 컴파일 하자.

그러면 foo1.o 와 foo2.o라는 오브젝트 파일이 만들어지는데, 이 둘을 다음과 같이 묶어주자.

그러면 libfoo.a라는 파일이 생성된다.  이 파일이 이제 우리가 쓸 수 있는 정적라이브러리 파일이다. 제대로 동작하나 보기 위해, example.c를 만들자.

#include <stdio.h> #include "foolib.h" int main() { foo1(); foo2(); return 0; }

컴파일은 다음과 같이 한다.

-L 은 gcc에게 라이브러리를 찾을 디렉터리를 지정한다.

-l은 링크할 라이브러리를 지정한다. l뒤에 붙은 이름은 라이브러리 이름에서 lib을 뗀(libfoo의 경우 foo만 남는다) 것이며, -l 옵션은 컴파일 할 대상의 소스가 지정되는 뒤에 두면 된다.

동적 라이브러리 만들기

동적 라이브러리를 살펴 볼때도 위에서 나열한 소스를 쓰자. (재활용은 위대하다.)

-fPIC은 컴파일러에게 위치에 상관없이 수행할 수 있는 코드로 컴파일 하라고 하는 것이다. 이제 이렇게 해서 나온 오브젝트 파일을 정적 라이브러리와 합쳐(?)보자.

다음과 같이 쳐보자.

-shared는 동적 라이브러리를 우선 시해서 링크 하라고 지시한다.

-soname은 정적 라이브러리의 soname을 정한다.

자 이제 gcc 링크와 동적 링크를 위한 심볼릭 링크만 생성해 주자.

libfoo.so는 컴파일 시에 실행 파일들을 링크 할 때 링커가 찾을 수 있게 만든 것이며, libfoo.so.0은 실행 시에 동적 링커가 soname으로 찾을 수 있게 soname을 파일명으로 하는 libfoo.so.0.0.0파일의 심볼릭 링크를 만든 것이다. 

동적 링크에 대한 작업도 필요하다.  libfoo.so.0.0.0파일이 있는 디렉터리를 /etc/ld.so.conf에 추가해 줘야 하며, ldconfig로  /etc/ld.so.cache를 새로 생성한다.

마지막으로 다음과 같이 실행하여 컴파일 하자.

sscanf에 이어 이번에는 sprintf의 사용법에 대해서 알아보자 (sscanf에 대한 사용법은 여기를 참조http://codecat.tistory.com/entry/sscanf-사용법)

sprintf는 man page에 다음과 같이 선언되어 있다.

int sprintf(char *str, const char *format, ...);

sscanf 사용법에서, scanf가 standard input stream, stdin, 에서 input을 읽어오는 반면, sscanf는 str이라는 문자열(character string)에서 입력을 받아온다라고 했는데, sprintf 또한 input<->output이라는 점만 제외하면 이와 유사하다.

즉 printf가 standard output stream, stdout에 output을 출력한다면, sprintf는 str이라는 문자열에 출력을 한다고 생각하면 된다.

sscanf 사용법에 썼던 예제를 다시 한번 보면, (예제출처: 초보자를 위한 Linux & Unix C 프로그래밍)

#define MAX 100 main() { int i = 123; float j = 23.456; char buff1[MAX]; char buff2[MAX]; sprintf(buff1, "%d", i); sprintf(buff2, "%.3f", j); sscanf(buff1, "%o", &i); printf("%d\n", i); sscanf(buff2, "%e", &j); printf("%e\n", j); }

sprintf(buff1, "%d", i) 라는 부분이 있다.  이는 위에서 이미 정의된 i를 %d에 맞게 buff1에 출력(저장이라고 보는게 맞겠다)한다고 보면 된다.  (포맷에 관련해서는 sscanf 사용법을 참조하자.)

그럼 이걸 언제 써먹냐면은... 물론 여러가지 용도가 있겠지만, 대표적으로 생각나는게 여러가지 옵션을 모아서 하나의 커맨드를 만들어서 실행시킬 때 사용할 수 있겠다. 

다음과 같이 실행 커맨드와 옵션들을 긁어 모아서 system()으로 한방에 실행시킬 수 있다.

sscanf는 manpage에 다음과 같이 정의되어 있다.

#include <stdio.h>
int sscanf(const char *str, const char *format, ...);



scanf가 standard input stream, stdin, 에서 input을 읽어오는 반면, sscanf는 str이라는 문자열(character string)에서 입력을 받아온다
즉, 메모리에서(const char *str) 받은 값을 포맷 형식에 맞게 읽어오는 것이다.
간단한 예제를 보자.

 
예제출처: 초보자를 위한 Linux & Unix C 프로그래밍

위의 예제에서는 이미 정의되어 있는 값을 sprintf를 이용해 buff에 넣어두었다가, sscanf를 통해 포맷에 맞게 읽어오는 예제이다.

가끔 이 포맷으로 간편한 작업을 해낼 수도 있는데, 다음의 예제를 보면,

예제출처: Microsoft Support @http://support.microsoft.com/kb/38335/eng

sscanf를 이용해서 내부 버퍼에서 ','(컴마)로 문자를 잘라서 읽어오는 것이다.  (이렇게 하기 위해서 필요한 포맷은 %[^',']이다)  물론 일반적인 토큰화를 해야 한다면 strtok을 사용하는 걸 추천한다. 

말 나온 김에 포맷에 대해서 정리해 보자.

주의 할 점은 포맷을 잘못 사용 할 경우, 이어지는 모든 데이터가 다 틀어지게 된다는 것이다.  sscanf를 사용해서 받은 값이 이상하거나 할 때는, 포맷을 제대로 썼는지 확인하자.

출처: virtual linux manager by Mel Gorman

memory 는 bank로 나뉘어짐
bank는 node라고 불리며,
node는 struct pglist_data로 표현됨.(UMA일때도 마찬가지)

pglist_data는 pg_data_t로 참조된다. 
시스템의 모든 node는 NULL로 끝나는 pgdata_list 이라는 리스트로 관리된다.
그리고 각 node는 pg_data_t->node_next로 다른 node와 연결된다.

UMA의 경우 contig_page_data라는 하나의 pg_data_t 구조체를 사용한다.(노드가 하나 이니까)

각 node는 'zone' 이라 불리는 여러개의 블록으로 나뉜다.

zone은 struct zone_struct 이라는 구조체로 정의되며, zone_t로 사용자정의된다.

zone의 종류에는,
ZONE_DMA 
ZONE_NORMAL
ZONE_HIGHMEM
(ZONE_MOVEABLE)
이 있다.
 
신경써야 할 부분은 ZONE_NORMAL이다.  ZONE_HIGHMEM은 ZONE_NORMAL의 상위 위쪽 부분이다.

시스템의 메모리는 page frame이라는 고정된 chunk들로 이루어져 있다.
각각의 physical page frame들은 struct page라는 구조체로 표현되며,
이 모든 구조체들은 mem_map이라는 배열에 저장된다.
(mem_map은 보통 ZONE_NORMAL 시작부분이나 지정된 커널 로딩 영역 뒤에 저장된다)

2.1 Nodes
리눅스는 page를 할당할 때, node-local alloocation policy를 사용해서
현재 실행 중인 CPU에서 가장 가까운 node의 메모리를 할당한다.

pg_data_t, 즉 pglist_data는 다음가 같이 정의되어 있다.
struct pglist_data { zone_t node_zones[MAX_NR_ZONES]; zonelist_t node_zonelists[GFP_ZONEMASK+1]; int nr_zones; struct page *node_mem_map; unsigned long *valid_addr_bitmap; struct bootmem_data *bdata; unsigned long node_start_paddr; unsigned long node_start_mapnr; unsigned long node_size; int node_id; struct pglist_data *node_next; } pg_data_t;

2.2 Zones

각 zone들은 struct zone_struct으로 구성된다. (linux/mmzone.h 참조)

typedef struct zone_struct { spinlock_t lock; unsigned long free_pages; unsigned long pages_min, pages_low, pages_high; int need_balance; free_area_t free_area[MAX_ORDER]; wait_queue_head_t * wait_table; unsigned long wait_table_size; unsigned long wait_table_shift; struct pglist_data *zone_pgdat; struct page *zone_mem_map; unsigned long zone_start_paddr; unsigned long zone_start_mapnr; char *name; unsigned long size; } zone_t;

2.2.1 Zone Watermarks

시스템에 남아있는 메모리가 적을 경우, kswapd라는 pageout 데몬이 실행되어 page들을 free하기 시작한다.  만약 메모리를 많이 회수해야 한다면, kswapd 데몬은 동기적으로 메모리를 free 한다.(이 방식은 direct-reclaim이라고 불리기도 한다.)

각 zoned은 세가지의 watermark를 가지고 있는데, 이들은 각각 다음과 같다.

pages_min은 free_area_init_core()에서 메모리 초기화 과정에서 page 단위로 표현된 zone의 크기로 표현되어 계산된다.

2.2.2 Calculating the size of Zones

각 zone의 크기는 setup_memory()에서 계산된다.

PFN은 pages단위로 세어진 실제 메모리 맵(physical memory map)안의 오프셋이다.

min_low_pfn은 첫번째 PFN이며, _end 다음의 첫번째 페이지에 위치한다.  min_low_pfn은 나중에 쓰일 boot memory allocator를 위해 mm/bootmem.c 에 file scope 변수로 지정되어 있다.

unsigned long min_low_pfn;

unsigned long max_low_pfn;

unsigned long max_pfn;

마지막 페이지 프레임인 max_pfn 은 아키텍쳐 의존적으로 계산된다.  x86의 경우 find_max_pfn()으로 e820 map을  통해 가장 높은 값을 갖는 페이지 프레임을 읽는다. (e820은 BIOS를 통해 얻어지는 테이블이며, 어떤 physicla memory가 있는지, 예약되어 있는지등을 알려준다)  

max_low_pfn은 (x86의 경우) find_max_low_pfn()을 통해 계산되며, 이는 ZONE_NORMAL의 끝을 표시한다.

2.2.3 Zone Wait Queue Table

(생략)

2.3 Zone Initialization

zone 들은 kernel page table 이 paginig_init()에 의해 완전히 세팅되고 나면 초기화 된다.  페이지 테이블 초기화에 대해서는 3.6을 참조하자.

아키텍쳐마다 방식에는 다르겠지만, 기본적으로 UMA 일 경우, free_area_init()에 보낼 매개변수를, NUMA일 경우, free_area_init_node()에 보낼 매게변수를 결정한다.  이 매게변수들은 다음과 같다.

free_area_init_core()는 각 zone_t의 내용을 연관성이 있는 정보로 채우는 역활 및 mem_map 배열 할당을 한다.  현 상황에서는 어떤 페이지가 free인지는 알 수 없으며, boot memory allocator의 작업이 끝날 때 까지는 알 수 없다.

2.4 Initializing mem_map

mem_map은 시스템 초기화 과정에서 생성된다.

NUMA의 경우, global mem_map이 PAGE_OFFSET에서 시작하는 가상 배열로 취급되며, 각 node 마다 free_area_init_node()를 호출하여 이 가상 배열을 할당한다.  

UMA의 경우, free_area_init()이 contig_page_data를 node로, global mem_map을 local mem_map으로 동일하게 취급한다.

locla mem_map은 free_area_init_core()에 의해 할당되며, 이를 위한 배열은 boot memory allocator가 alloc_bootmem_node()를 호출하여 할당한다.  UMA의 경우, 이렇게 할당된 메모리는, 위에서 말한 거 처럼, global mem_map이 되나, NUMA의 경우 조금 다르다.  NUMA는 local mem_map을 각 node의 고유한 메모리에서 할당하며, global mem_map의 경우 따로 할당되지는 않으나, (가상 배열로 취급되는)PAGE_OFFSET으로 설정된다.  local map은 pg_data_t->node_mem_map에 저장된다.

node에 존재하는 각 zone들은  가상 mem_map의 주소를 zone_t->zone_mem_map에 저장한다.  이 외의 작업에서는 mem_map을 실제 배열로 취급한다.

2.5 Pages

모든 시스템의 physical page frame은 struct page를 가지고 있다.

쉘 스크립트가 오동작을 하거나 이해하기 힘든 동작을 보일 때, 디버깅을 하려면 다음과 같이 하면 매우 편하다.

보통 쉘의 시작 부분은 #!/bin/sh로 되어 있는데, 이는 스크립트가 어떤 쉘에서 동작하는지를 정하는 매직코드이다.

그래서 위와 같이 하면, 쉘 코드가 한줄 한줄 실행되는 걸 볼 수 있어 디버깅하기에 좋다.

출처: Secure Coding in C and C++

Linux 의 기본 바이너리 포맷은 ELF(Executable and Linking Format)이다.  ELF는 원래 UNIX System Laboratories(USL)에 의해 ABI(Application Binary Interface)의 일환으로 개발되었다.

ELF 파일의 프로세스 공간은 GOT(Global Offset Table)을 포함하고 있는데, 이 GOT는 절대 주소값을 가지고 있다.  이렇게 절대 주소값을 가지고 있을 경우, 코드 영역의 위치여부나 공유여부에 상관없이 사용 할 수 있게 된다.

실제 테이블의 내용이나 형태는 프로세서의 종류에 따라 다를 수 있지만,   기본적으로 GOT는 다이나믹 링킹 프로세스를 지원하는데 있다.

프로그램에 의해 사용되는 모든 라이브러리 함수는 GOT에 실제 함수의 주소를 가진 엔트리를 가지고 있으며, 이는 라이브러리가 쉽게 프로세스 메모리 안에서 재배치될 수 있게 한다.  프로그램이 실제로 함수를 처음으로 사용하기 전까지는, GOT의 엔트리에는 RTL(RunTime Linker)의 주소를 가지고 있다.  만약 프로그램에 의해 함수가 호출되면, RTL에게 제어는 넘어가며, 함수의 실제 주소가 GOT에 등록된다.  차후의 함수 호출은 RTL을 거칠 필요 없이 GOT를 통해서 호출된다.

GOT 엔트리의 주소는 EFL 파일의 고정된 위치에 있고, 결과적으로 모든 실행 프로세스 이미지들에게 공통적인 주소에 있게 된다.  GOT 엔트리의 위치를 알려면, 'objdump' 커맨드를 사용하여 확인 할 수 있다.