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

该函数利用字符串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，weiboprife