客户端怎么高效请求数据让界面又不卡
客户端怎样高效请求数据让界面又不卡
我最近做一个交易客户端，用http协议包装交易的协议。不同的交易协议是向相应的url发请求，交互的数据都是json格式。发送了某一协议后，要根据相应数据刷新界面显示。很卡。到底怎样处理请求，数据，界面显示这3者的关系呢？大神们你们会怎么做？说说你们的经验
------解决方案--------------------
我想应该分为两个方面吧，一个是服务器的网络响应和处理，一个是接收到数据以后的分析展现。
1 网络响应处理
如果是tomcat或者iis这类的应用服务器，这些已经比较成熟了，要提高处理能力和响应速度的话用多机做负载并发比较好。但是相对来说资源开销大一点。
另一个是自己写server服务器，这个主要的瓶颈在于网络模型，一般用iocp模型效率会高一点，普通的服务器并发量应该是可以达到2000-3000左右。而且可以自己把数据包进行压缩传输，这个对网络处理的压力就相对小一点。
2 客户端的分析响应
如果是由comcat或者是iis发回来的http数据包，如果过大可能分批接收的话，对网络的依赖就比较高，相当于界面有个等待的过程，造成界面缓慢，这个如果是自己写的server就可以压缩，一般对于xml或者json的文本压缩率可以达到90%以上。
另外对大容量或者大节点的json或者xml的解析因为涉及到遍历节点速度也会慢一点。这个没有什么好的方法，优化算法，或者是升级cpu可能会好一点。
我想两个方面处理吧，一个是提高服务器的网络处理性能，压缩数据包大小，前段使用多线程解析后界面显示，这样应该能大幅度提高性能。
------解决方案--------------------
不知道你想怎么弄 我们是发送请求的时候可以直接响应界面事件 组包 发送请求
处理返回的数据时单独开启线程来处理 处理结束后可以消息映射给界面线程 通知界面跟新
我用UDP 不卡
------解决方案--------------------
发送协议的时候要自己开个线程去发送
如果把发送写在界面消息响应函数里面就是楼主这种情况了。
------解决方案--------------------
请求数据和显示应该放入不同的线程中，请求数据可能会进行网络等待，因此造成了阻塞
------解决方案--------------------
把什么网络访问部分的操作放到单独的工作线程中去做，UI线程只负责显示
------解决方案--------------------
一个线程专门处理录音，也就是处理所有的返回，不用每次语音都开一个线程
------解决方案--------------------
降低虚高的界面刷新频率。
------解决方案--------------------
界面里如果超过100毫秒不响应是会感觉到卡顿的
------解决方案--------------------
这个问题我遇到过，我是用线程解决的。你可以用线程去试一试
------解决方案--------------------
利用多线程就行，让界面和工作线程分开。
------解决方案--------------------
界面线程：接受自定义消息后，刷新屏幕
工作线程：可以用采用线程池或者异步模式通信，一个线程接受多个Socket字
推荐 Window32多线程
------解决方案--------------------
你最好还是把一切东西集中到一切来做。如果按我上面说的那个不可靠的方法做，你以后改什么玩意，你会哭的很销魂
我最近做一个交易客户端，用http协议包装交易的协议。不同的交易协议是向相应的url发请求，交互的数据都是json格式。发送了某一协议后，要根据相应数据刷新界面显示。很卡。到底怎样处理请求，数据，界面显示这3者的关系呢？大神们你们会怎么做？说说你们的经验
------解决方案--------------------
我想应该分为两个方面吧，一个是服务器的网络响应和处理，一个是接收到数据以后的分析展现。
1 网络响应处理
如果是tomcat或者iis这类的应用服务器，这些已经比较成熟了，要提高处理能力和响应速度的话用多机做负载并发比较好。但是相对来说资源开销大一点。
另一个是自己写server服务器，这个主要的瓶颈在于网络模型，一般用iocp模型效率会高一点，普通的服务器并发量应该是可以达到2000-3000左右。而且可以自己把数据包进行压缩传输，这个对网络处理的压力就相对小一点。
2 客户端的分析响应
如果是由comcat或者是iis发回来的http数据包，如果过大可能分批接收的话，对网络的依赖就比较高，相当于界面有个等待的过程，造成界面缓慢，这个如果是自己写的server就可以压缩，一般对于xml或者json的文本压缩率可以达到90%以上。
另外对大容量或者大节点的json或者xml的解析因为涉及到遍历节点速度也会慢一点。这个没有什么好的方法，优化算法，或者是升级cpu可能会好一点。
我想两个方面处理吧，一个是提高服务器的网络处理性能，压缩数据包大小，前段使用多线程解析后界面显示，这样应该能大幅度提高性能。
------解决方案--------------------
不知道你想怎么弄 我们是发送请求的时候可以直接响应界面事件 组包 发送请求
处理返回的数据时单独开启线程来处理 处理结束后可以消息映射给界面线程 通知界面跟新
我用UDP 不卡
------解决方案--------------------
发送协议的时候要自己开个线程去发送
如果把发送写在界面消息响应函数里面就是楼主这种情况了。
------解决方案--------------------
请求数据和显示应该放入不同的线程中，请求数据可能会进行网络等待，因此造成了阻塞
------解决方案--------------------
把什么网络访问部分的操作放到单独的工作线程中去做，UI线程只负责显示
------解决方案--------------------
一个线程专门处理录音，也就是处理所有的返回，不用每次语音都开一个线程
------解决方案--------------------
降低虚高的界面刷新频率。
------解决方案--------------------
界面里如果超过100毫秒不响应是会感觉到卡顿的
------解决方案--------------------
这个问题我遇到过，我是用线程解决的。你可以用线程去试一试
------解决方案--------------------
利用多线程就行，让界面和工作线程分开。
------解决方案--------------------
界面线程：接受自定义消息后，刷新屏幕
工作线程：可以用采用线程池或者异步模式通信，一个线程接受多个Socket字
推荐 Window32多线程
------解决方案--------------------