編輯:關於Android編程
<喎?/kf/ware/vc/" target="_blank" class="keylink">vcD4KPHA+PGJyPgo8L3A+CjxoMj5TZXJ2aWNlIE1hbmFnZXLI57rOxvS2r7XEsKGjvyAgICA8L2gyPgo8cD48YnI+CjwvcD4KPHA+ICAgICAgzqrKssO00qq9slNlcnZpY2UgTWFuYWdlciC6zSBtZWRpYXNlcnZlcrXExvS2r8TYo78g0vLOqrrzw+bO0sPH1Nq9skNhbWVyYcH3s8w8L3A+CjxwPrXEyrG68qOsu+HTw7W9z+C52Naqyra146Gj19u6z87E1cK94bm51+nWr7yw1MS2wczl0em/vMLHo6y+9raovavV4sG9sr+31rbAwaKz9sC0o6w8L3A+CjxwPtXrttTQ1Nf2uPbGys72oaO52NPaQmluZGVysr+31qOsuPbIy9a7yse4+b7d19S8urXEwO294tC0tcS31s72o6yyos60zai5/cq11b3XpWxvZzwvcD4KPHA+tcS3vcq90+jS1Mi3yM+jrNTaz+C52MH3s8zA77jD1PXDtLzTbG9no6y7ucfruN/K1sPHsrvB37TNvcyjoaOhPC9wPgo8cD48YnI+CjwvcD4KPHA+ICAgIMeww+bO0r2yaW5pdC5yY9bQtcRzZXJ2aWNlysfI57rOxvS2r7XEo6yyotLUenlnb3RlzqrA/df2wcvLtcP3oaPP6sfpx+uyzr+8PC9wPgo8cD6htsnuyOvA7b3iQW5kcm9pZCC+7TGht7bByumxyrzHIKOo0rujqaGqoaoKIEFuZHJvaWQgSW5pdCDHs8721q60001haW6/qsq8tb1zZXJ2aWNlIHN0YXJ0PGJyPgo8L3A+CjxwPlNlcnZpY2UgTWFuYWdlctKyysewtNXVzazR+bXEt73KvbG7xvS2r7XEoaPO0sPHz8i/tL+0aW5pdC5yY9bQtcTP4LnYxqy2zqO6PC9wPgo8cD48L3A+CjxwcmUgY2xhc3M9"brush:java;">service servicemanager /system/bin/servicemanager
class core
user system
group system
critical
onrestart restart zygote
onrestart restart media
onrestart restart surfaceflinger
onrestart restart drm
好了,我們重點是第一句: service servicemanager /system/bin/servicemanager
那這個servicemanager程序對於的源碼位於哪裡呢? 找Makefile!!怎麼找?搜索servicemanager找目錄,
文件?確實,就這麼找到了。看看frameworks/base/cmds/servicemanager/Android.mk怎麼寫的吧?
include $(CLEAR_VARS) LOCAL_SHARED_LIBRARIES := liblog LOCAL_SRC_FILES := service_manager.c binder.c LOCAL_MODULE := servicemanager include $(BUILD_EXECUTABLE)
太感動了,從LOCAL_MODULE為servicemanager,我們知道要找的東東就是它了!! 涉及到此目錄
下的service_manager.c和binder.c兩個源文件(和binder.h一個頭文件)。
接下來的第一步就是找程序的入口函數——main函數啦。 哇塞,我找到了,太激動了有莫有。。。
int main(int argc, char **argv) { struct binder_state *bs; void *svcmgr = BINDER_SERVICE_MANAGER; bs = binder_open(128*1024); if (binder_become_context_manager(bs)) { ALOGE("cannot become context manager (%s)\n", strerror(errno)); return -1; } svcmgr_handle = svcmgr; binder_loop(bs, svcmgr_handler); return 0; }
變量賦值神馬的,暫時不管,我們先看看調用的函數做了些啥。
struct binder_state *binder_open(unsigned mapsize) { struct binder_state *bs; bs = malloc(sizeof(*bs)); if (!bs) { errno = ENOMEM; return 0; } bs->fd = open("/dev/binder", O_RDWR); if (bs->fd < 0) { fprintf(stderr,"binder: cannot open device (%s)\n", strerror(errno)); goto fail_open; } bs->mapsize = mapsize; bs->mapped = mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, bs->fd, 0); if (bs->mapped == MAP_FAILED) { fprintf(stderr,"binder: cannot map device (%s)\n", strerror(errno)); goto fail_map; } /* TODO: check version */ return bs; fail_map: close(bs->fd); fail_open: free(bs); return 0; }
就是打開/dev/binder設備,調用mmap將設備映射到大小為(128*1024)字節的內存裡。但這邊open,
mmap,其實會調用binder驅動注冊的open和mmap函數。 以open為例,對應的就是
kernel/drivers/staging/android/binder.c中的binder_open函數。
static int binder_open(struct inode *nodp, struct file *filp) { struct binder_proc *proc; binder_debug(BINDER_DEBUG_OPEN_CLOSE, "binder_open: %d:%d\n", current->group_leader->pid, current->pid); proc = kzalloc(sizeof(*proc), GFP_KERNEL); if (proc == NULL) return -ENOMEM; get_task_struct(current); proc->tsk = current; INIT_LIST_HEAD(&proc->todo); init_waitqueue_head(&proc->wait); proc->default_priority = task_nice(current); #ifdef RT_PRIO_INHERIT proc->default_rt_prio = current->rt_priority; proc->default_policy = current->policy; #endif binder_lock(__func__); binder_stats_created(BINDER_STAT_PROC); hlist_add_head(&proc->proc_node, &binder_procs); proc->pid = current->group_leader->pid; INIT_LIST_HEAD(&proc->delivered_death); filp->private_data = proc; binder_unlock(__func__); if (binder_debugfs_dir_entry_proc) { char strbuf[11]; snprintf(strbuf, sizeof(strbuf), "%u", proc->pid); proc->debugfs_entry = debugfs_create_file(strbuf, S_IRUGO, binder_debugfs_dir_entry_proc, proc, &binder_proc_fops); } return 0; }
int binder_become_context_manager(struct binder_state *bs) { return ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, 0); }
原來是通過ioctl,發送了BINDER_SET_CONTEXT_MGR的命令給/dev/binder設備。有點Linux Driver基礎知識
的人都知道,如果設備的驅動程序注冊的file operation函數指針數組裡面如有指定ioctl函數,那麼此處調用的
ioctl函數將是那個對應的注冊函數。
關於binder相關的代碼,位於kernel/drivers/staging/android目錄下。在此目錄的Binder.c中,我們看到了
binder_ioctl函數,初步猜測這個就是我們要找的binder設備的ioctl函數。代碼中是如何印證這一點的呢?
在該文件中搜索binder_ioctl,我們可以看到:
static const struct file_operations binder_fops = { .owner = THIS_MODULE, .poll = binder_poll, .unlocked_ioctl = binder_ioctl, .mmap = binder_mmap, .open = binder_open, .flush = binder_flush, .release = binder_release, }; static struct miscdevice binder_miscdev = { .minor = MISC_DYNAMIC_MINOR, .name = "binder", .fops = &binder_fops };
看到這個東東,是否覺得似曾相識? 沒錯,在很多講驅動程序的地方,我們會看到字符設備驅動的范例。
裡面會有module_init/ module_exit。會講到模塊的插入和移除,字符設備的注冊和注銷,以及該module的
file operation數組。該數組裡面會指定設備文件的各種操作函數,諸如open,ioctl,release等。
這裡也是那樣的。還有個問題,那設備驅動程序的入口(insert module時執行的函數)在哪裡呢?搜索下
上面那個binder_miscdev,看看哪個地方注冊的這個設備。原來是在binder_init函數裡:
ret = misc_register(&binder_miscdev);
device_initcall(binder_init); #define device_initcall(fn) module_init(fn) /* Each module must use one module_init(). */ #define module_init(initfn) \ static inline initcall_t __inittest(void) \ { return initfn; } \ int init_module(void) __attribute__((alias(#initfn)));
終於水落石出了,原來init_module時調用的就是這個binder_init啊。OK,追根溯源結束了,我們回過頭來
看看那個binder_ioctl裡針對BINDER_SET_CONTEXT_MGR到底做了啥。
struct binder_proc *proc = filp->private_data; struct binder_thread *thread; unsigned int size = _IOC_SIZE(cmd); void __user *ubuf = (void __user *)arg; /*printk(KERN_INFO "binder_ioctl: %d:%d %x %lx\n", proc->pid, current->pid, cmd, arg);*/ trace_binder_ioctl(cmd, arg); ret = wait_event_interruptible(binder_user_error_wait, binder_stop_on_user_error < 2); if (ret) goto err_unlocked; binder_lock(__func__); thread = binder_get_thread(proc); if (thread == NULL) { ret = -ENOMEM; goto err; }
case BINDER_SET_CONTEXT_MGR: binder_context_mgr_node = binder_new_node(proc, NULL, NULL); if (binder_context_mgr_node == NULL) { ret = -ENOMEM; goto err; } #ifdef BINDER_MONITOR strcpy(binder_context_mgr_node->name, "servicemanager"); #endif binder_context_mgr_node->local_weak_refs++; binder_context_mgr_node->local_strong_refs++; binder_context_mgr_node->has_strong_ref = 1; binder_context_mgr_node->has_weak_ref = 1; break;
static struct binder_node *binder_new_node(struct binder_proc *proc, void __user *ptr, void __user *cookie) { struct rb_node **p = &proc->nodes.rb_node; struct rb_node *parent = NULL; struct binder_node *node; while (*p) { parent = *p; node = rb_entry(parent, struct binder_node, rb_node); if (ptr < node->ptr) p = &(*p)->rb_left; else if (ptr > node->ptr) p = &(*p)->rb_right; else return NULL; } node = kzalloc(sizeof(*node), GFP_KERNEL); if (node == NULL) return NULL; binder_stats_created(BINDER_STAT_NODE); rb_link_node(&node->rb_node, parent, p); rb_insert_color(&node->rb_node, &proc->nodes); node->debug_id = ++binder_last_id; node->proc = proc; node->ptr = ptr; node->cookie = cookie; node->work.type = BINDER_WORK_NODE; INIT_LIST_HEAD(&node->work.entry); INIT_LIST_HEAD(&node->async_todo); binder_debug(BINDER_DEBUG_INTERNAL_REFS, "binder: %d:%d node %d u%p c%p created\n", proc->pid, current->pid, node->debug_id, node->ptr, node->cookie); return node; }
從函數和變量名稱來看,跟紅黑樹有關。先在紅黑樹中查找此結點,後面調用rb_link_node和rb_insert_color
將結點插入到紅黑樹上。這裡的debug_id唯一地標識了每一個創建的binder node,傳入的ptr和cookie
均為NULL。然後創建此code的work.entry和async_todo鏈表。對此片段更詳細的解讀,還是需要大神指點。
#ifdef BINDER_MONITOR strcpy(binder_context_mgr_node->name, "servicemanager"); #endif
這句就是關鍵了,我們明確知道了這個binder_context_mgr_node就是Service Manager。這個全局變量
binder_context_mgr_node“代表”的就是service manager,今後看到此變量時得多多留意哦!!!
#define BINDER_SERVICE_MANAGER ((void*) 0) void *svcmgr = BINDER_SERVICE_MANAGER; svcmgr_handle = svcmgr;
bwr.write_size = 0; bwr.write_consumed = 0; bwr.write_buffer = 0; readbuf[0] = BC_ENTER_LOOPER; binder_write(bs, readbuf, sizeof(unsigned));
int binder_write(struct binder_state *bs, void *data, unsigned len) { struct binder_write_read bwr; int res; bwr.write_size = len; bwr.write_consumed = 0; bwr.write_buffer = (unsigned) data; bwr.read_size = 0; bwr.read_consumed = 0; bwr.read_buffer = 0; res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr); if (res < 0) { fprintf(stderr,"binder_write: ioctl failed (%s)\n", strerror(errno)); } return res; }
由此可見,這個binder_write其實是設置了binder_write_read結構體裡面的write部分,而read
部分為空(read_size為0,read_buffer為NULL),然後通過ioctl發送BINDER_WRITE_READ命令。
case BINDER_WRITE_READ: ... ... if (copy_from_user(&bwr, ubuf, sizeof(bwr))) { ret = -EFAULT; goto err; } ... ... if (bwr.write_size > 0) { ret = binder_thread_write(proc, thread, (void __user *)bwr.write_buffer, bwr.write_size, &bwr.write_consumed); trace_binder_write_done(ret); if (ret < 0) { bwr.read_consumed = 0; if (copy_to_user(ubuf, &bwr, sizeof(bwr))) ret = -EFAULT; goto err; } }
if (bwr.read_size > 0) { ret = binder_thread_read(proc, thread, (void __user *)bwr.read_buffer, bwr.read_size, &bwr.read_consumed, filp->f_flags & O_NONBLOCK); trace_binder_read_done(ret); if (!list_empty(&proc->todo)) wake_up_interruptible(&proc->wait); if (ret < 0) { if (copy_to_user(ubuf, &bwr, sizeof(bwr))) ret = -EFAULT; goto err; } } if (copy_to_user(ubuf, &bwr, sizeof(bwr))) { ret = -EFAULT; goto err; }
既然是驅動,就涉及到了內核空間和用戶空間數據的傳遞。通過copy_from_user將用戶空間的數據拷貝到
內核空間(此處對應驅動程序處理數據之前),copy_to_user將內核空間的數據拷貝到用戶空間
(此處對應驅動程序處理完數據後)。
此處我們的write_size > 0, 而read_size為0。繼續看binder_thread_write函數:
case BC_ENTER_LOOPER: thread->looper |= BINDER_LOOPER_STATE_ENTERED; break;
哦,原來只是設置了binder_thread結構的looper成員的狀態。果真是跟BC_ENTER_LOOPER這個命令
對應啊。繼續看binder_loop的其他部分。
for (;;) { bwr.read_size = sizeof(readbuf); bwr.read_consumed = 0; bwr.read_buffer = (unsigned) readbuf; res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr); if (res < 0) { ALOGE("binder_loop: ioctl failed (%s)\n", strerror(errno)); break; } res = binder_parse(bs, 0, readbuf, bwr.read_consumed, func); if (res == 0) { ALOGE("binder_loop: unexpected reply?!\n"); break; } if (res < 0) { ALOGE("binder_loop: io error %d %s\n", res, strerror(errno)); break; } }
這個死循環只有在出錯情況下才會退出。前面講了BC_ENTER_LOOPER的前半段,就是binder_write,
去寫數據(set command)。這裡繼續講其後半段——讀數據( Binder Reply)。
上面那個binder_write執行完了,在這裡的loop中,我們看到read_size不為0,如上面所貼出的
case BINDER_WRITE_READ,binder_thread_read函數會被執行。
if (*consumed == 0) { if (put_user(BR_NOOP, (uint32_t __user *)ptr)) return -EFAULT; ptr += sizeof(uint32_t); }
將會把BR_NOOP (也就是Binder Reply NO OPeraterion 放到用戶空間。在這裡順便說下
put_user與copy_to_user的區別,前者是將基本類型數據(1字節,2字節,4字節,8字節)
拷貝到用戶空間,後者可以拷貝任意長度的數據(參數裡面有長度,有數據指針)。
此時thread_todo鏈表應該為空,也沒有transaction吧(個人推測)?那麼wait_for_proc_work
此時應該為FALSE。(關於return_error,thread->todo,請參考binder_get_thread,這個在
binder_ioctl裡面會調用到)
wait_for_proc_work = thread->transaction_stack == NULL && list_empty(&thread->todo);
上面這個應該是設置binder reply的狀態信息。
thread->looper |= BINDER_LOOPER_STATE_WAITING; ... ... binder_unlock(__func__);
之所以這裡直接用了binder_unlock,是因為之前在binder_ioctl 已經調用了binder_lock。
if (non_block) { if (!binder_has_thread_work(thread)) ret = -EAGAIN; }
static int binder_has_thread_work(struct binder_thread *thread) { return !list_empty(&thread->todo) || thread->return_error != BR_OK || (thread->looper & BINDER_LOOPER_STATE_NEED_RETURN); }
為了確認函數binder_has_thread_work的返回值的真假,我們需要逐個判斷函數裡面 “||"的幾個條件:
(1)list_empty(&thread->todo)
這個thread->todo是在binder_get_thread裡面被賦值的。
INIT_LIST_HEAD(&thread->todo);
static inline void INIT_LIST_HEAD(struct list_head *list) { list->next = list; list->prev = list; }
static inline int list_empty(const struct list_head *head) { return head->next == head; }
(2)關於return_error和thread->looper在binder_get_thread裡的賦值
thread->looper |= BINDER_LOOPER_STATE_NEED_RETURN; thread->return_error = BR_OK; thread->return_error2 = BR_OK;
判斷結果為FALSE,而(thread->looper & BINDER_LOOPER_STATE_NEED_RETURN)判斷
結果為TRUE,於是函數返回TRUE。
binder_lock(__func__); thread->looper &= ~BINDER_LOOPER_STATE_WAITING;
if (!list_empty(&thread->todo)) w = list_first_entry(&thread->todo, struct binder_work, entry); else if (!list_empty(&proc->todo) && wait_for_proc_work) w = list_first_entry(&proc->todo, struct binder_work, entry); else { if (ptr - buffer == 4 && !(thread->looper & BINDER_LOOPER_STATE_NEED_RETURN)) /* no data added */ goto retry; break; }
也不會被執行。else裡面的那個thread->looper & BINDER_LOOPER_STATE_NEED_RETURN
為TRUE,所以goto retry不會被執行,下面的break會被執行,while(1)循環退出。
done: *consumed = ptr - buffer; if (proc->requested_threads + proc->ready_threads == 0 && proc->requested_threads_started < proc->max_threads && (thread->looper & (BINDER_LOOPER_STATE_REGISTERED | BINDER_LOOPER_STATE_ENTERED)) /* the user-space code fails to */ /*spawn a new thread if we leave this out */) { proc->requested_threads++; binder_debug(BINDER_DEBUG_THREADS, "binder: %d:%d BR_SPAWN_LOOPER\n", proc->pid, thread->pid); if (put_user(BR_SPAWN_LOOPER, (uint32_t __user *)buffer)) return -EFAULT; binder_stat_br(proc, thread, BR_SPAWN_LOOPER); } return 0;requested_threads,ready_threads,requested_threads_started均為0(未見其賦值),
max_threads在binder_ioctl中的case BINDER_SET_MAX_THREADS 被設置。
frameworks/native/libs/binder/ProcessState.cpp中的open_driver函數用來打開binder設備,其中有句:
size_t maxThreads = 15; result = ioctl(fd, BINDER_SET_MAX_THREADS, &maxThreads);
也就是說max_threads為15。
另外,由於thread->looper的狀態包含BINDER_LOOPER_STATE_ENTERED,所以此處判斷條件為TRUE。
將會把BR_SPAWN_LOOPER傳到用戶空間,然後設置binder reply的相關狀態為BR_SPAWN_LOOPER。
OK,到此binder_ioctl這邊走完了,對應的就是binder_loop中的ioctl(bs->fd, BINDER_WRITE_READ, &bwr);
執行完畢了,那麼返回到binder_loop中,由於binder_ioctl返回值為0,接下來執行的是binder_parse。
先看看binder_parse傳入的參數:
(1)從bwr.read_buffer = (unsigned) readbuf; 可知,readbuf對應的是read_buffer,它會在ioctl調用
過程中被改變。
binder_thread_read(proc, thread, (void __user *)bwr.read_buffer, bwr.read_size, &bwr.read_consumed
static int binder_thread_read(struct binder_proc *proc, struct binder_thread *thread, void __user *buffer, int size, signed long *consumed, int non_block)
void __user *ptr = buffer + *consumed; void __user *end = buffer + size;
if (put_user(BR_NOOP, (uint32_t __user *)ptr))
指向這塊buffer,那上面的put_user就是改變裡面的內容。可是問題來了,後面不是也有句
(put_user(BR_SPAWN_LOOPER, (uint32_t __user *)buffer)) 麼? 由於函數進來時,ptr 等於buffer,
那麼,這個就會改掉之前寫入的BR_NOOP,但這樣做的話,binder_parse中執行的將是:
default: ALOGE("parse: OOPS %d\n", cmd); return -1;
done標號語句的分析可能有誤。其中,”requested_threads,ready_threads,requested_threads_started
均為0(未見其賦值)“的判斷可能不正確,這裡不能執行if下的語句。還望高人指點!!
(2) bwr.read_consumed 為多少? 下面兩句會被執行,所以read_consumed為sizeof(uint32_t) 。
ptr += sizeof(uint32_t); *consumed = ptr - buffer;
int r = 1; uint32_t *end = ptr + (size / 4); case BR_NOOP: break; return r;
分析: 上面那個size / 4 結果為1,所以while 循環只有一次,只會處理一個binder reply —— BR_NOOP 。
binder_parse返回1後,回到binder_loop裡的for循環,然後繼續ioctl, binder_parse。
也就是說,在沒有命令到來的時候,這邊處理的REPLY就是BR_NOOP 。
如需轉載,請注明出處: http://blog.csdn.net/happy08god/article/category/1881463
今天在我哥們的帶領下,學習了一些關於ListView的優化方案。現在提出來和大家分享下.... 第一點: 在Listview中數據加載時經常用到的ViewHolder,我
相比主頁鍵(HOME)和最近應用鍵(APP_SWITCH)的處理,返回鍵比較簡單,復寫onKeyDown就可以實現,如下:
方式一:自定義對話框 public class ProgersssDialog extends Dialog { private ImageView img;
本文介紹微信自動搶紅包的實現方法,主要實現以下幾個功能: 1.自動拆開屏幕上出現的紅包