蜗窝科技

@稻草人：我没有读过Android的这段代码，猜测如下： 这里的代码应该是Android为了兼容几种不同Wakelock机制的实现，就像本文开头所说的那样。 g_fds数组应该保存了这几种机制所对应的不同的文件句柄，当然，现在最正宗的wakelock机制，就对应了[ACQUIRE_PARTIAL_WAKE_LOCK]，也即“/sys/power/wake_lock”。 你可以看看数组中的其它fd对应什么。 至于jni中为什么只使用了ACQUIRE_PARTIAL_WAKE_LOCK，估计得问问作者了，也许是不想再节外生枝，尽量往linux原生上靠拢吧。

@ushineme：多谢夸奖，欢迎常来，共同交流、学习、进步。

@superm：高通和苹果应该会自己设计、修改ARM IP的，不然比其它厂家就没有优势了。

hi, wowo, 关于android acquire wakelock有一点不明白的地方，就是framework层在申请acquire wakelock的时候在最后逐层的调用到JNI层的时候我看到他往kernel申请的wakelock只有一种PARTIAL_WAKE_LOCK类型： static void nativeAcquireSuspendBlocker(JNIEnv *env, jclass clazz, jstring nameStr) { ScopedUtfChars name(env, nameStr); acquire_wake_lock(PARTIAL_WAKE_LOCK, name.c_str()); } 百思不得其解，因为我看到framework层有申请其他类型的wakelock的（比如FULL_WAKE_LOCK），为什么一层层的调用下来最后就变成了只申请PARTIAL_WAKE_LOCK了，麻烦帮忙解惑呀！ Ps:上面是android JNI层的一个函数，他调用的acquire_wake_lock是HAL层的一个函数： acquire_wake_lock(int lock, const char* id) { initialize_fds(); // ALOGI("acquire_wake_lock lock=%d id='%s'\n", lock, id); if (g_error) return -g_error; int fd; if (lock == PARTIAL_WAKE_LOCK) { fd = g_fds[ACQUIRE_PARTIAL_WAKE_LOCK]; } else { return -EINVAL; } return write(fd, id, strlen(id)); } 这个函数最后write的文件节点就是这篇文章开始说的/sys/power/wake_lock节点，写完之后就调用了 wake_lock_store函数，往这篇文章所写的往下面走了。 想问的就是为什么上层下来的wakelock只能申请PARTIAL_WAKE_LOCK类型的partial wake。

今天意外发现了这个网站，真是太好了！ 更意外的是通过其他文章的评论里wowo的链接看到这篇文章后，我才发现原来之前来过这里，只是当时错过了～ 以后常来，向大家学习！

感谢博主，真的学到了很多。我是刚毕业分到公司显示驱动组的，从一头雾水到现在稍微有了些许理解，从你的博客中学到了非常多的东西。

@superm：欢迎，欢迎！这个团队是一个非常松散的组织，只要热爱技术（不仅仅限于linux），都可以进入这个团队（注册了这个网站的用户就是我们一员了）。当然，我们还是希望这个组织有一个共同的理念，那就是我们网站的宣传语：慢下来，享受技术。 只要注册了用户就都可以写文章发表在这个网站，如果你愿意，还可以在文章后面附注： 原创文章，转发请注明出处。蜗窝科技 当然，有这个附注的文章，我们要求更加严格，希望是有调理，言之有物的，代表蜗窝品质的

@小白：在dtc目录下执行./dtc 试试.

看到有这样的团队，感到很兴奋，如果想加入你们，也为该网站写点文章，不知如何联系？

@wowo：其实我就是觉得高通可能会自己修改了ARM的IP，优化和个性化IP，就好像你说的高通买的是IP core的授权，而不是ARM core的授权，这个是不是说明高通自己在修改ARM IP? 二国内大部分都是直接集成了。