背景介绍:
这是一个webapp和nativeapp相结合的项目,webapp负责ui和业务逻辑,包含网络请求、数据存储、手机信息获取、app统计分析、webapp和整体app升级控制,nativeapp负责给webapp提供网络请求(跨域访问),app统计分析(集成countly sdk)调用,升级资源的下载和解压安装;
其实这不是一个很好的架构设计,例如:app的一级菜单都是webapp,你想用户每次点击菜单都会发起网络请求,所以一想项目中webapp跟nativeapp的层次关系就知道会出很多问题;
问题来了:
测试人员说webapp登录有时候长达3-5秒,偶尔发生没有规律,也是无法忍受的;因为在wifi环境下都如此,要是用户在2G网路下,问题会放大的。
插曲:
webapp开发人员开始说server端登录耗时长,在排除了server问题之后,开始说android网络通信有问题,嗯,本人不太像bs前端工程师,可以理解,毕竟前端工程师从来就没有考虑过手机系统优化问题,所有出现类似的请求也在意料之中。
问题寻找:
android工程师,看了自己的网络代理代码,如下:
public class HttpClientFactory { private static DefaultHttpClient client; public synchronized static DefaultHttpClient getThreadSafeClient() { if (client != null) return client; client = new DefaultHttpClient(); ClientConnectionManager mgr = client.getConnectionManager(); HttpParams params = client.getParams(); HttpProtocolParams.setVersion(params, HttpVersion.HTTP_1_1); // 请求超时 HttpConnectionParams.setSoTimeout(params, 15000); HttpConnectionParams.setTcpNoDelay(params, true);//nagle算法默认是打开的,会引起delay的问题;所以要手工关掉。 HttpConnectionParams.setConnectionTimeout(params, 15000); client = new DefaultHttpClient( new ThreadSafeClientConnManager(params, mgr.getSchemeRegistry()), params); return client; } }连nagle算法都关闭了,哎,其实这个nagle算法关不关闭都不会影响的。随后也检查了,每次的网络请求都是线程控制的,甚至他都把其它不重要的网络请求线程的优先级设置成 Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND) 都没效果。
android工程师,又重新写了一个访问server的app,顺序执行100次,均很正常;这说明了webapp的业务逻辑调用出问题了。
最后发现:
webapp在webview加载完自己的登录页面就开始调用countly统计分析的初始化,结果造成了countly数据发送和webapp登录请求并发,自然就会出现有时候耗时长的问题;
虽然这篇的文章标题和内容不太相符,但是我想提醒大家,做app一定合理安排好业务逻辑,充分适当地用好网络请求这种宝贵而影响用户体验的资源。
随后对于webapp的业务优化开展:
1、 全部的网络请求放在登录成功后延时10秒执行。
2、countly监控数据汇报和app升级下载放在,activity onstop 里执行。
3、合并多个并发网络请求为一次网络请求,减少并发。