【转】移植之乱谈 深入理解Android 卷I作者谈

昨天有一个博友回复，说他已经完成了android系统在windows上的移植，其中比较难的是binder系统的移植。下面是两个demo网址，我看了后倍有感触。

http://v.youku.com/v_show/id_XMzIwMDkxOTQ4.html
http://v.youku.com/v_show/id_XMzIwNzI2NTg4.html

这才是真正有技术含量的移植啊！

从做android开始，听到的最多的就是移植+merge了。但总感觉都是：

1 简单的把人家做好的，放到新的平台上，然后测试，修改。完完全全的改bug。甚至都不需要对系统，程序结构有什么深入的了解。

2 做linux驱动更是这样，到处去改参数，调板子。（个人感觉都被硬件绑架了..）。

什么后果？居然很多人一年都写不了几行代码！！！我知道google有一个美女程序员，每天都要花4个小时来写代码，没有什么别的特殊目的，就是为了保持脑子的灵活。

另外，那些刚工作的人，改改bug就完成工作，而又不写代码，让他们误以为程序员就是这样工作的，结果不去花时间研究系统（放着linux内核，android系统这种高质量，高复杂度的优秀源码不看。说实话，代码量不超过10w行以上的同志，真的怀疑能否看懂代码的真正意图，所以google校园招聘的时候，似乎对代码量有一定的要求），

【这里也请那些培训学校的老师们，稍微注重下教育质量，培训方法。】

我心目中的移植，是应该建立再对当前平台和目标平台的一个深刻认识上，再加上对要移植代码本身，程序结构得深入了解上才能做的。看看上面博友的移植，如果只会改几个bug，何年何月才能将android系统移植到windows上呢？

下面是我之前做的一份关于完成端口到linux平台上的移植的设计文档。这个设计由于各种原因，最终没有被讨论过，也没有（永远不会）被采用。

view plain

1.                                                   完成端口在Linux平台下的实现 
2.  
3. 一 说明
4.  
5. Windows下的完成端口模式是一种真正的由操作系统来实现的“异步IO”，应用程序等待完成通知即可。 
6.  
7. 在面向对象的网络库中，包括ACE, ASIO, LibEvent, SPServer等开源公共库中实际有类似的模块。一般将完成端口模型称之为Proactor模型，而select的方式称之为Reactor模型。 
8.  
9. 简单来说，在Reactor模型中，系统通知你可以干什么，然后应用程序去做对应的事情（例如send，recv，accept等）。以发送为例，流程大致如下： 
10.  
11. 1  用户注册回调事件 
12.  
13. 2  Reactor等待select返回，然后调用回调 
14.  
15. 3 用户在回调中继续发送操作（非异步IO） 
16.  
17. 而在Proactor模型中，系统通知你什么已经干完了（例如上一次send完成了，recv完成了，accept完成了）等，仍以发送为例，流程大致如下： 
18.  
19. 1  用户注册回调，发送数据（异步IO） 
20.  
21. 2  Proactor检测发送完成事件，然后调用回调 
22.  
23. 3  用户在回调中继续发送操作（异步IO） 
24.  
25. 从流程上看，似乎没有区别。而关键点就在于IO是否为异步。Reactor模型一般是非异步的，而Proactor由于能检测完成事件，所以IO是异步的。 
26.  
27. 在Linux平台上，由于系统并没有支持异步IO，所以我们必须用Reactor的模式去模拟一个Proactor模式。大体流程如下； 
28.  
29. 1 用户注册回调，发送数据（非阻塞IO） 
30.  
31. 2 构造一个完成事件，记录发送的结果，并添加到完成事件队列 
32.  
33. 3 Proactor检测完成事件队列，然后调用回调 
34.  
35. 4 用户继续发送数据（非阻塞IO） 
36.  
37. 从上面可以看出，在Linux下Proactor的实现关键是自己构造一个完成事件队列，并处理相关入队和出队的操作即可。这种实现方式与windows完成端口是一致的。 
38.  
39. 从已知的资料来看，Proactor模型本身没有设计缺陷。我们将参考Windows下的完成端口的原理和用法来实现一个Linux平台下的完成端口。 
40.  
41.   
42.  
43. <strong>二 设计细节</strong> 
44.  
45. 与完成端口相关的有线程池，完成端口句柄，和完成事件队列。 
46.  
47. 1 完成端口句柄：将与一个epoll句柄相对应 
48.  
49. 2  线程池：调用GetQueuedCompletionStatus从完成事件队列中取事件 
50.  
51. 3  用户调用IO操作，将事件加入完成队列 
52.  
53. <strong>2.1 事件入队</strong> 
54. 先讨论事件入队的操作。有两种明显的方式来完成。 
55.  
56. 这里所有的socket或者别的文件句柄必须都是非阻塞的。 
57.  
58. <strong>1, 真正的异步IO</strong>  
59.  
60. 要实现真正的异步IO，需要有一个线程池来完成实际的IO工作，并且还需要有一个IO请求队列来保存用户提交的IO操作请求。在Windows平台下，这个线程池和队列是位于操作系统内部的。而在Linux平台上得自己创建相关组建。 
61.  
62. 工作流程如下： 
63.  
64. 1 用户发起IO操作，内部创建一个IO请求，并加入到请求队列 
65.  
66. 2  内部线程从请求队列中取出请求，完成实际的请求，并将请求结果加入到完成端口的完成事件队列 
67.  
68. 这种方式的优缺点有： 
69.  
70. 1  优点，很大程度上的异步IO。（其他的优点暂时未想到） 
71.  
72. 2  缺点：实现难度较大，而且资源消耗比较多 
73.  
74. <strong>2. 利用非阻塞模式构造的伪异步IO</strong> 
75.  
76. 在这方式下将在用户调用的IO函数中直接完成实际的IO操作，只不过不阻塞罢了。这种方式可以不需要IO请求队列，不需要线程池。 
77.  
78. 考虑目前的并发数量，暂时用方式2来实现。 
79.  
80.   
81.  
82. <strong>2.2 一些不能完全实现的地方</strong> 
83. Windows下有些用法在Linux没有合适的模型对应，包括： 
84.  
85. 1  AcceptEx对应的先创建socket以供AcceptEx使用的方法 
86.  
87. 2  GetAcceptExSockAddr 
88.  
89. 实现过程中，将尽力保证接口的一致。 
90.  
91. <strong>2.3 涉及的内容</strong> 
92. 模块上，可能包括： 
93.  
94. 1 完成端口相关函数和类设计 
95.  
96. 2 已有windows下的线程池到Linux平台下的移植 
97.  
98. 3 Socket相关库的修改与异步IO配套功能的增加 
99.  
100. 性能考虑方面，目前可以想到的包括： 
101.  
102. 1 池的和自旋锁的使用 
103.  
104. 2 GetQueuedCompletionStatus函数的内部实现要考虑使用刚完成工作的那个线程来继续工作，以避免不必要的线程切换 
105.  
106. 3 同理，PostQueuedCompletionStatus函数内部要避免触发所有线程来竞争一个事件的出队 

回想当时做这个移植，花了很多时间来调研完成端口的实现机制，来研究proactor和reactor的区别，来研究linx平台的特性。考虑到完成端口是Win平台最有效率的IO操作，那么在linux平台上实现自然也得考虑效率方面的问题。

虽然最终没有实现该设想，但却极大加深了对以上知识的认识，对以后的工作有非常大的帮助。

作为本篇的结尾，希望大家认真对待工作，从简单的移植工作中去发掘背后那块绝大的金矿，以提高自己的价值。