开发人员可以使用这些变量编写Android build系统的Makefile -- Android.mk。每个模块，如一个应用，一个共享库等，都有一个自己的Android.mk。在编译的时候，Android.mk中的宏就会被展开成相应的Make规则,变量也会代入相关的规则。下面以packages/apps/AlarmClock/Android.mk举例介绍：
～～～～～～～～
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE_TAGS := eng development
LOCAL_SRC_FILES := $(call all-subdir-java-files)
LOCAL_PACKAGE_NAME := AlarmClock
include $(BUILD_PACKAGE)
～～～～～～～～～～
关于这些变量的含义，在build/core/build-system.html中都有具体介绍。值得注意的是，如果是生成一个可执行程序，则引用 BUILD_PACKAGE，如果生成一个library,则引用BUILD_SHARED_LIBRARY。我们可以模仿现有的Android.mk去创建自己的Android.mk。
下面以HelloAndroid (http://code.google.com/android/intro/hello-android.html中Eclipse SDK自动生成)为例，讨论如何实现HelloAndroid的中文化。
1）文件src/com/android/hello/R.java中列出了hello 字符串的id:
public final class R {
...
public static final class string {
public static final int app_name=0x7f040001;
public static final int hello=0x7f040000;
}
}
web widget 目前种类比较多，比较流行的有Symbian, apple widget等。下图中的widget基于android示例HelloActivity，使用一个WebView去调用一个简单的widget。
值得注意的是，web widget中的javaScrip 可以调用java的函数，反之亦然。这将极大扩展web widget的功能。
function initialize() {
var text = document.getElementByIdx("text").value;
var tlang = document.getElementByIdx("tlang").value
google.language.detect(text, function(result) {
if (!result.error && result.language) {
google.language.translate(text, result.language, tlang,
function(result) {
var translated = document.getElementByIdx("translation");
if (result.translation) {
translated.value = result.translation;
}
});
}
});
}
</script>
</head>
<body>
<body>
Auto detect source language and translate to:<br/>
<select id="tlang">
<option value="zh-TW">Chinese Trad</option>
<option value="zh-CN">Chinese Simpl</option>
<option value="en">English</option>
<option value="fi">Finnish</option>
<option value="fr">French</option>
<option value="de">German</option>
<option value="it">Italian</option>
<option value="ja">Japanese</option>
<option value="ko">Korean</option>
<option value="pt">Portuguese</option>
<option value="es">Spanish</option>
</select><br/>
<textarea id="text" name="query" height="100px">Enter string here</textarea> <BUTTON TYPE=BUTTON onClick="initialize()">
<I>GO</I></BUTTON><br/>
<textarea id="translation" name="results" height="100px">Results</textarea><br/>
Copy from the above text box and paste the text where ever. If there is an update, it will be here: <a href="http://www.waiseto.com/2009/01/simple-google-translator-widget-for-s60.html">link</a> Enjoy W. Seto
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// Set the layout for this activity. You can find it
// in res/layout/hello_activity.xml
setContentView(R.layout.hello_activity);
WebView wv;
wv = (WebView) findViewById(R.id.text);
wv.getSettings().setJavaScriptEnabled(true);
wv.loadUrl("file:///data/index.html");
The window is tied to a Surface and the ViewRoot asks the Surface for a
Canvas that is then used by the Views to draw onto. After View draw its data to canvas, ViewRoot
will call surface.unlockCanvasAndPost(canvas) to schedule surfaceFlinger::composeSurfaces() which do the actually display to display panel. SurfaceFlinger handles to transfers drawn data in canvas to surface front buffer or backbuffer
Except for SurfaceViews, different views within the same ViewRoot share the same surface.
A Layer is something that can be composited by SurfaceFlinger (should
have been called LayerFlinger). There are several types of Layers if
you look in the code, in particular the regular ones (Layer.cpp) ,
they are backed by a Surface, and the LayerBuffer (very badly chosen
name) which don't have a backing store, but receive one from their
client. .
Note that the GGLSurface type, should have been called GGLBuffer
Multiple layers are just composited to the final buffer in their Z order.
zip.close()作者: 翔子 时间: 2010-10-13 16:52 标题: Android系列之二十一 －－ track memory allocations 下文来自http://developer.android.com/resources/articles/track-mem.html但需要越墙访问，特摘录在此。
Despite the impressive hardware of the first Android phones (T-Mobile G1 and ADP1) writing efficient mobile applications is not always straightforward. Android applications rely on automatic memorymanagement handled by Dalvik's garbage collector which can sometimes cause performance issues if you are not careful with memory allocations.
In a performance sensitive code path, like the layout or drawing method of a view or the logic code of a game, any allocation comes at a price. After too many allocations, the garbage collector will kick in and stop your application to let it free some memory. Most of the time, garbage collections happen fast enough for you not to notice. However, if a collection happens while you are scrolling through a list of items or while you are trying to defeat a foe in a game, you may suddenly see a drop in performance/responsiveness of the application. It's not unusual for a garbage collection to take 100 to 200 ms. For comparison, a smooth animation needs to draw each frame in 16 to 33 ms. If the animation is suddenly interrupted for 10 frames, you can be certain that your users will notice.
Most of the time, garbage collection occurs because of tons of small, short-lived objects and some garbage collectors, like generational garbage collectors, can optimize the collection of these objects so that the application does not get interrupted too often. The Android garbage collector is unfortunately not able to perform such optimizations and the creation of short-lived objects in performance critical code paths is thus very costly for your application.
To help you avoid frequent garbage collections, the Android SDK ships with a very useful tool called allocation tracker. This tool is part of DDMS, which you must have already used for debugging purposes. To start using the allocation tracker, you must first launch the standalone version of DDMS, which can be found in the tools/ directory of the SDK. The version of DDMS included in the Eclipse plugin does not offer you ability to use the allocation tracker yet.
Once DDMS is running, simply select your application process and then click the Allocation Tracker tab. In the new view, click Start Tracking and then use your application to make it execute the code paths you want to analyze. When you are ready, click Get Allocations. A list of allocated objects will be shown in the first table. By clicking on a line you can see, in the second table, the stack trace that led to the allocation. Not only you will know what type of object was allocated, but also in which thread, in which class, in which file and at which line. The following screenshot shows the allocations performed by [url=http://code.google.com/p/shelves]Shelves while scrolling a ListView.
Even though it is not necessary, or sometimes not possible, to remove all allocations for your performance critical code paths. the allocation tracker will help you identify important issues in your code. For instance, a common mistake I have seen in many applications is to create a new Paint object on every draw. Moving the paint into an instance field is a simple fix that helps performance a lot. I highly encourage you to peruse the [url=http://source.android.com/]Android source code to see how we reduce allocations in performance critical code paths. You will also thus discover the APIs Android provide to help you reuse objects.作者: 翔子 时间: 2010-10-13 16:53 标题: Android系列之二十二 －－ 图形系统 http://www.moandroid.com/?p=937中介绍了一些关于Android图形系统的知识。
）