请教API应用程序的消息响应过程，详解

OS有自己的消息队列和消息循环，至于消息处理工作OS自己可以完成；

同时OS为当前运行的每个Windows应用程序也建立了各自的消息队列，该应用程序的消息循环和消息处理函数（窗口过程函数）需要由应用程序的代码来编写，但是这些应用程序的消息循环和窗口过程函数中的实现 *** 作，还必须依靠OS来完成。（如消息循环中的GetMessage, TranslateMessage, DispathMessage窗口过程中的PlaySound, BeginPaint, GetClientRect, DrawText等都是调用OS来实现的。）

Windows中的消息通常来自两种情况：

鼠标、键盘或时钟等用户 *** 作（又可称为进队消息）； 或者调用某些特定的Windows函数(如CreateWindow，ShowWindow，UpdateWindow时产生的)（又可称为不进队消息）<这里的进队、不进队中的队列指的是应用程序的消息队列>

产生的消息传输和处理过程晌物如下：

不进队消息：首先被OS自动捕获，加入OS自己的消息队列中，当轮到该消息的时候，OS直接调用应用程序的消息处理函数（窗口过程WndProc），把该消息传给该函数，WndProc中的switch-case语句进昌谨宏行判断，然后调用相应条件下的系统函数如PlaySound等，做出响应，没有case的，调用系统默认的处理方法DefWindowProc。（这部分的消息通常不是来自用耐册户的输入，而是来自于调用特定的Windows函数是产生的，如CreateWindow，ShowWindow，UpdateWindow等）；

进队消息：用户 *** 作后产生的消息，首先由OS捕获，OS将这些消息添加到应用程序自己的消息队列中，在程序中，应用程序的消息循环代码，不断地从自己的消息队列中取出消息（其实还是借助OS的GetMessage函数来去自己的消息），并将该消息键盘转换(还是借助OS，即调用OS的TranslateMessage函数完成)，最后将消息分发(同样需借助OS，并由OS的DispatchMessage函数将这些消息分发，也就是由OS将这些消息传给应用程序的窗口过程WndProc函数，做switch-case处理。分发给OS的消息，OS可能仍旧需要放入自己的消息队列中。)

综上可以看到，其实绝大多数的 *** 作必须通过OS来完成，即使是应用程序自己的消息循环和窗口过程，都需要调用大量的OS函数来实现如GetMessage，PlaySound等等。

一. 首先要分析接口响应慢的具体原因，列出一些常见原因

是不是资源层面的瓶颈（服务器性能问题）

是不是缓存没添加，如果加了，是不是热点数据导致负载不均衡

是不是有依赖于第三方接口

是不是接口涉及业务太多，导致程序跑很久

是不是sql层面的问题导致的等待时机加长，进而拖慢接口

网络层面的原因，带宽，DNS解析

二.相应的解决方案

资源紧张，加机器，SLB（负载均衡）搞起来

加缓存可以解决的问题都不是什么大问题，存在热点数据可以将某几个热点单独出来用专门的机器进行处理，不要因为局部影响整体

一方面与第三方沟通接口响应问题，另一方面超时时间注意把控，如果可以非核心业务能异步久异步掉

把非核心的业务进行异步化 *** 作历升并（消息队列）。记住如果代码层面是非核心业务，但是会影响用户感知，需要慎重决定是否异步。

如果是代码不良导致加锁了，尽量优化索引或sql语句，让锁的级别最小（到行），一肢迹般来说到行差不多了。如果是单个sql跑慢了，需要分析是不是索引没加或者sql选的索引错了，索引该加的就加了，该force index也加了。

网路原因，需要联系运营笑冲商一起商量下怎么解决，单方面比较难有大的优化。

---