action_for_each_trigger("early-init", action_add_queue_tail);

    queue_builtin_action(wait_for_coldboot_done_action, "wait_for_coldboot_done");
    queue_builtin_action(mix_hwrng_into_linux_rng_action, "mix_hwrng_into_lin一部分在ux_rng");
    queue_builtin_action(keychord_init_action, "keychord_init");
    queue_builtin_action(console_init_action, "console_init");

    /* execute all the boot actions to get us started */
    action_for_each_trigger("init", action_add_queue_tail);

    /* skip mounting filesystems in charger mode */
    if (!is_charger) {
        action_for_each_trigger("early-fs", action_add_queue_tail);
        action_for_each_trigger("fs", action_add_queue_tail);
        action_for_each_trigger("post-fs", action_add_queue_tail);
        action_for_each_trigger("post-fs-data", action_add_queue_tail);
    }

    /* Repeat mix_hwrng_into_linux_rng in case /dev/hw_random or /dev/random
     * wasn't ready immediately after wait_for_coldboot_done
     */
    queue_builtin_action(mix_hwrng_into_linux_rng_action, "mix_hwrng_into_linux_rng");

    queue_builtin_action(property_service_init_action, "property_service_init");
    queue_builtin_action(signal_init_action, "signal_init");
    queue_builtin_action(check_startup_action, "check_startup");

    if (is_charger) {
        action_for_each_trigger("charger", action_add_queue_tail);
    } else {
        action_for_each_trigger("early-boot", action_add_queue_tail);
        action_for_each_trigger("boot", action_add_queue_tail);
    }

        /* run all property triggers based on current state of the properties */
    queue_builtin_action(queue_property_triggers_action, "queue_property_triggers");


#if BOOTCHART
    queue_builtin_action(bootchart_init_action, "bootchart_init");
#endif
 

void action_for_each_trigger(const char *trigger, void (*func)(struct action *act))
該函式利用字串trigger從從action_list中查詢特定Actions，為每個符合條件的Actions執行action_add_queue_tail函式，也就是說將action_list中所有觸發器為trigger的Actions新增到action_queue中。
void queue_builtin_action(int (*func)(int nargs, char **args), char *name)
該函式完成兩個操作：
1)構造一個觸發器為name的struct action結構體，並建立一個struct command，對應函式為行參func
2)將struct action新增到action_queue連結串列末尾。

從名字上來看action_queue就是Actions佇列，而佇列具有FIFO特性。事實也是如此，action_queue可以用於控制Actions執行的順序。
上述程式碼結束後，action_queue連結串列最終具有如下形式，每個連結串列都是struct action資料結構，各節點通過struct action中的qlist變數彼此連線。
白色節點來自init啟動指令碼，橘紅色節點則有函式queue_builtin_action建立。

現在萬事具備，只欠東風。接下來就是如何執行這些Actions了。
init.c main

    for(;;) {
        execute_one_command();
        ...
    }

execute_one_command函式分析
概括的說，這個函式每次從action_queue開頭取出一個Actions，同時移除對應節點，依次執行每個command。由與main函式中for迴圈語句的存在，最終所有的action_queue中所有Actions都會被執行。大致執行流程如此。

簡要總結下：init程序的邏輯時，任何一個Actions想要被執行，只要把自己放到action_queue中，然後在init程序的for迴圈中就會在之後的某個時間被執行。 細心的讀者已經發現，為什麼action_queue中的Actions如此之少（請參考本文前面介紹Actions時），至少“post-fs”、“post-fs-data”、“boot”，以及"property:<name>=<value>”等Actions怎麼沒有？

這是因為init程序耍了花招，它把這部分Actions的觸發放到了init.rc裡，由Actions的一條特殊command: "trigger"觸發。請注意，該trigger與Actions的名字（也稱為trigger）不同。 見init.rc

on late-init
    trigger early-fs
    trigger fs
    trigger post-fs
    trigger post-fs-data

    # Load properties from /system/ + /factory after fs mount. Place
    # this in another action so that the load will be scheduled after the prior
    # issued fs triggers have completed.
    trigger load_all_props_action

    # Remove a file to wake up anything waiting for firmware.
    trigger firmware_mounts_complete

    trigger early-boot
    trigger boot
 

看到這裡，先大膽猜測當init程序執行到“late-init” Actions時，對於每條trigger語句，取出後面所跟的字串，從action_list（“媽蛋，終於想起我來了”）中找出該Actions對應的struct action結構，新增到action_queue中。快去看看程式碼確定一下是否如此。怎麼找到command對應程式碼？前面提到init啟動指令碼所有關鍵字都keyword.h中，

//keyword.h
//-------------
    KEYWORD(trigger,     COMMAND, 1, do_trigger)
//builtins.c
//-------------
int do_trigger(int nargs, char **args)
{
    action_for_each_trigger(args[1], action_add_queue_tail);
    return 0;
}

bingo！原來trigger命令對應的函式do_trigger中再次呼叫了action_for_each_trigger，可見之前的猜測正確！
至於"property:<name>=<value>”型別的Actions由於需要在屬性條件滿足時被執行，在android4.4的init的實現中對這類Actions的處理比較特殊，有兩種方式：
(1) 通過action_queue，配合execute_one_command處理
參考上面action_queue連結串列圖，在main函式中使用queue_builtin_action建立了一個特殊的Actions："queue_property_triggers"，該Actions內只有一個command，對應函式為queue_property_triggers_action，程式碼如下：

static int queue_property_triggers_action(int nargs, char **args)
{
    queue_all_property_triggers();
    /* enable property triggers */
    property_triggers_enabled = 1;
    return 0;
}
void queue_all_property_triggers()
{
    struct listnode *node;
    struct action *act;
    list_for_each(node, &action_list) {
        act = node_to_item(node, struct action, alist);
        if (!strncmp(act->name, "property:", strlen("property:"))) {
            /* parse property name and value
               syntax is property:<name>=<value> */
            const char* name = act->name + strlen("property:");
            const char* equals = strchr(name, '=');
            if (equals) {
                char prop_name[PROP_NAME_MAX + 1];
                char value[PROP_VALUE_MAX];新浪微博
                int length = equals - name;
                if (length > PROP_NAME_MAX) {
                    ERROR("property name too long in trigger %s", act->name);
                } else {
                    int ret;
                    memcpy(prop_name, name, length);
                    prop_name[length] = 0;

                    /* does the property exist, and match the trigger value? */
                    ret = property_get(prop_name, value);
                    if (ret > 0 && (!strcmp(equals + 1, value) ||
                                    !strcmp(equals + 1, "*"))) {
                        action_add_queue_tail(act);
                    }
                }
            }
        }
    }
}

可見queue_all_property_triggers函式中會檢查從action_list中查詢所有property型的Actions，並判斷其屬性條件是否滿足，若滿足則使用action_add_queue_tail(act)將其新增到action_queue中。

仔細考慮一下，這種方式並不能保證所有property型的Actions都能在屬性滿足後被觸發執行，參考action_queue連結串列圖，這種方式僅僅能保證在"queue_property_triggers"之前的Actions執行中所設定的屬性。設想這種情況，在init.rc新增某個Actions，希望可以在Android命令列終端中設定屬性（android的set_property命令可以設定android屬性），從而觸發某個動作。僅僅通過action_queue配合execute_one_command是難以優雅實現的，所以init程序使用了第二種方式。
思考：非優雅的實現最簡單方式，只要在for迴圈中定時輪詢屬性，但是延時間隔多少合適？若是間隔太短，則將會相當浪費CPU，若是間隔太長，則會導致設定某個屬性到執行其對應Actions的時間過長。優雅的方式可以利用程序見通訊機制避免CPU被浪費，並能保證響應的及時性。

(2) 藉助程序間通訊方式實現
首先細化init.c main函式中for迴圈程式碼，大致如下：

int main(int argc, char* argv[])
{
    ....
    for(;;) {
        execute_one_command();
        ....
        nr = poll(ufds, fd_count, timeout);
        if (nr <= 0)
            continue;
        for (i = 0; i < fd_count; i++) {
            if (ufds[i].revents == POLLIN) {這部分內容請閱讀
                if (ufds[i].fd == get_property_set_fd())
                    handle_property_set_fd();
                ...
            }
        }
    }
}

當某個程式（程序）呼叫property_set（libcutils庫）來自設定屬性，就會給init程序傳送一個訊息（通過Unix domain socket），最終init接收到整個訊息後，會呼叫
handle_property_set_fd() -> property_set（來自init/property_service.c）->  property_changed() -> queue_property_triggers()->action_add_queue_tail
在queue_property_triggers函式中從全域性action_list中匹配 property:<name>=<value>型別的Actions，如果屬性數值滿足，則將該Actions加入到action-queue中，這樣該Actions中的command將會在之後的execute_one_command()被呼叫。

在本文中涉及很多Android屬性的操作，筆者將在文章《Android init原始碼分析（3）屬性系統》進一步分析Android的屬性系統。 此外還有些問題需要解決： (1). service將如何執行，並且service存在多種屬性，當包含restart屬性時，init程序是如何重啟的？ (2). for迴圈中execute_one_command之後的大量程式碼的含義？

第一個問題將在文章《Android init原始碼分析（4）service的處理》中具體分析。至於for迴圈中其他程式碼，將分散在init原始碼分析（3）與（4）這兩篇文章中。

本文由prife原創，轉載請註明出處。部落格地址：blog.csdn.net/prife ，豆瓣prife，weibo prife