APP开发公司详解怎样解决对网络流量进行优化？APP开发公司资深工程师提醒网络流量优化工作非常重要，我们知道对App的最低容忍限度是，在2G、3G和4G网络环境下，每个页面都能打开，都能正常跳转到其他页面。要能够完成一次完整的支付流程。慢点儿没关系，尤其是2G网络。但是动不动就弹出“无法连接到网络”或者“网络连接超时”的对话框，就是我们开发人员必须要解决的问题了。深圳APP开发公司下面就如何具体进行网络流量优化进行分享。
APP开发时通信层面的优化让我们先从MobileAPI层面进行优化：
1）MobileAPI接口返回的数据，要使用gzip进行压缩。注意：大于1KB才进行压缩，否则得不偿失。经过gzip压缩后，返回的数据量大幅减少。
2）App与MobileAPI之间的数据传递，通常是遵守JSON协议的。JSON因为是xml格式的，并且是以字符存在的，在数据量上还有可以压缩的空间。我这里推荐一种新的数据传输协议，那就是ProtoBuffer。这种协议是二进制格式的，所以在表示大数据时，空间比JSON小很多。
3）接下来要解决的是频繁调用MobileAPI的问题。我们知道，发起一次网络请求，服务器处理的速度是很快的，主要花费的时间在数据传输上，也就是这一来一回走路的时间上。走路时间的长度，网络运维人员会去负责解决。移动开发人员需要关注的是，减少网络访问次数，能调用一次MobileAPI接口就能取到数据的，就不要调用两次。
4）我们知道，传统的MobileAPI使用的是HTTP无状态短连接。使用HTTP协议的速度远不如使用TCP协议，因为后者是长连接。所以我们可以使用TCP长连接，以提高访问的速度。缺点是一台服务器能支持的长连接个数不多，所以需要更多的服务器集成。
5）要建立取消网络请求的机制。一个页面如果没有请求完网络数据，在跳转到另一个页面之前，要把之前的网络请求都取消，不再等待，也不再接收数据。我遇到过一个真实的例子，首页要在后台调用十几个MobileAPI接口，用户一旦进入二级页面，在二级页面获取列表数据时，经常会取不到数据，并弹出“网络请求超时”的提示。我们通过在App输出log的方式发现，二级页面还在调用首页没有完成的那些MobileAPI接口，App网络底层的请求队列已经被阻塞了，原因是在进入下一个页面时，首页发起的网络请求仍然存在于网络请求队列中，并没有移除掉。无论是iOS还是Android，都应该在基类（BaseViewController或者BaseActivity）中提供一个cancelRequest的方法，用以在离开当前页面时清空网络请求队列。
APP开发时通信层面的优化让我们先从MobileAPI层面进行优化：
1）MobileAPI接口返回的数据，要使用gzip进行压缩。注意：大于1KB才进行压缩，否则得不偿失。经过gzip压缩后，返回的数据量大幅减少。
2）App与MobileAPI之间的数据传递，通常是遵守JSON协议的。JSON因为是xml格式的，并且是以字符存在的，在数据量上还有可以压缩的空间。我这里推荐一种新的数据传输协议，那就是ProtoBuffer。这种协议是二进制格式的，所以在表示大数据时，空间比JSON小很多。
3）接下来要解决的是频繁调用MobileAPI的问题。我们知道，发起一次网络请求，服务器处理的速度是很快的，主要花费的时间在数据传输上，也就是这一来一回走路的时间上。走路时间的长度，网络运维人员会去负责解决。移动开发人员需要关注的是，减少网络访问次数，能调用一次MobileAPI接口就能取到数据的，就不要调用两次。
4）我们知道，传统的MobileAPI使用的是HTTP无状态短连接。使用HTTP协议的速度远不如使用TCP协议，因为后者是长连接。所以我们可以使用TCP长连接，以提高访问的速度。缺点是一台服务器能支持的长连接个数不多，所以需要更多的服务器集成。
5）要建立取消网络请求的机制。一个页面如果没有请求完网络数据，在跳转到另一个页面之前，要把之前的网络请求都取消，不再等待，也不再接收数据。我遇到过一个真实的例子，首页要在后台调用十几个MobileAPI接口，用户一旦进入二级页面，在二级页面获取列表数据时，经常会取不到数据，并弹出“网络请求超时”的提示。我们通过在App输出log的方式发现，二级页面还在调用首页没有完成的那些MobileAPI接口，App网络底层的请求队列已经被阻塞了，原因是在进入下一个页面时，首页发起的网络请求仍然存在于网络请求队列中，并没有移除掉。无论是iOS还是Android，都应该在基类（BaseViewController或者BaseActivity）中提供一个cancelRequest的方法，用以在离开当前页面时清空网络请求队列。
6）增加重试机制。如果MobileAPI是严格的RESTful风格，那么我们一般将获取数据的请求接口都定义为get；而把操作数据的请求接口都定义为post。这样的话，我们就可以为所有的get请求配置重试机制，比如get请求失败后重试3次。有人会问post请求失败后，是否需要重试呢？我们举个例子吧，比如说下单接口是个post请求，如果请求失败那么就会重试3次，直到下单成功。但是有时候post请求并没有失败，而是超时了，超时时间是30秒，但是却31秒返回了，如果因此而重新发起下单请求，那么就会连续下单两次。所以post请求是不建议有重试机制的。此外，对所有的post请求，都要增加防止用户1分钟内频繁发起相同请求的机制，这样就能有效防止重复下单、重复发表评论、重复注册等操作。如果post请求具有防重机制，那么倒是可以增加重试机制。但是要可以在服务器端灵活配置重试的次数，可以是0次，意味着不会重试。在App启动的时候，告诉App所有的MobileAPI接口的重试次数。
APP开发时对图片策略优化
首先，我们从图片层面进行优化，这里说的图片，是根据MobileAPI返回的图片URL地址新启一个线程下载到App本地并显示的。很多App崩溃的原因就是图片的问题没处理好。以下是深圳APP开发公司在开发过程中遇到的几类问题以及相应的解决方案。
APP开发时对图片策略优化
首先，我们从图片层面进行优化，这里说的图片，是根据MobileAPI返回的图片URL地址新启一个线程下载到App本地并显示的。很多App崩溃的原因就是图片的问题没处理好。以下是深圳APP开发公司在开发过程中遇到的几类问题以及相应的解决方案。
APP开发公司提醒要确保下载的每张图，都符合ImageView控件的大小这对于Android是有难度的，因为手机分辨率千奇百怪，所以App中的图片，我们大多做成自适应的，有时是等比拉伸或缩放图片的宽和高，有时则固定高度而动态伸缩宽度，反之亦然。于是我们要求运营人员要事先准备很多套不同分辨率的图片。我们每次根据URL请求图片时，都要额外在URL上加上两个参数，width和height，从而要求服务器返回其中某一张图，URL如下所示：http://www.aaa.com/a.png?width=100&height=50。如果认为每次准备很多套图片是件很浪费人力的事情，我还有另一种解决方案，这种方案只需要一张图。但我们需要事先准备一台服务器，称为ImageServer。具体流程是这样的：
1）首先，App每次加载图片，都会把URL地址以及width和height参数所组成的字符串进行encode，然后发送给ImageServer，新的URL如下所示：http://www.ImageServer.com/getImage?param=(encodevalue
)2）然后，ImageServer收到这个请求，会把param的值decode，得到原始图片的URL，以及App想要显示的这张图片的width和height。ImageServer会根据URL获取到这张原始图片，然后根据width和height，重新进行绘制，保存到ImageServer上，并返回给App。
1）首先，App每次加载图片，都会把URL地址以及width和height参数所组成的字符串进行encode，然后发送给ImageServer，新的URL如下所示：http://www.ImageServer.com/getImage?param=(encodevalue
)2）然后，ImageServer收到这个请求，会把param的值decode，得到原始图片的URL，以及App想要显示的这张图片的width和height。ImageServer会根据URL获取到这张原始图片，然后根据width和height，重新进行绘制，保存到ImageServer上，并返回给App。
3）最后，App请求到的是一张符合其显示大小的图片。接下来收到同样的请求，直接返回ImageServer上保存的那种图片即可。但是要每天清一次硬盘，不然过不了几天硬盘就满了。如果width和height的比例与原图的宽高比不一致呢？我们需要再加一个参数imagetype，以下是定义：
·1表示等比缩放后，裁减掉多余的宽或者高。
·2表示等比缩放后，不足的宽或者高填充白色。当然你也可以定义0表示不进行缩放，直接返回。这种方案的缺点就是，ImageServer频繁地写硬盘，硬盘坚持不到两周就坏掉。所以，我们在损失了几块硬盘后，决定事先规定几套width和height，App必须严格遵守，比如说100×50，200×100，那么就不允许向服务器发送类似99×51这样的图片尺寸。但这样规定，并不能防止App开发人员犯错，他在UI上就是不小心为某个ImageView控件指定了99×51这样的尺寸，那么ImageServer还是会生成这样的图片。唯一的办法就是在出口加以控制，也就是向ImageServer发起请求的时候。我们会拿99×51
·1表示等比缩放后，裁减掉多余的宽或者高。
·2表示等比缩放后，不足的宽或者高填充白色。当然你也可以定义0表示不进行缩放，直接返回。这种方案的缺点就是，ImageServer频繁地写硬盘，硬盘坚持不到两周就坏掉。所以，我们在损失了几块硬盘后，决定事先规定几套width和height，App必须严格遵守，比如说100×50，200×100，那么就不允许向服务器发送类似99×51这样的图片尺寸。但这样规定，并不能防止App开发人员犯错，他在UI上就是不小心为某个ImageView控件指定了99×51这样的尺寸，那么ImageServer还是会生成这样的图片。唯一的办法就是在出口加以控制，也就是向ImageServer发起请求的时候。我们会拿99×51
这个实际的图片尺寸，去轮询我们事先规定好的那几个尺寸100×50和200×100，看更接近哪个，比如说99×51更接近100×50，那么就向ImageServer请求100×50这种尺寸的图片。找最接近图片尺寸的办法是面积法：S=(w1-a)×(w1-w)+(h1-h)×(h1-h)w和h是实际的图片宽和高，w1和h1是事先规定的某个尺寸的宽和高。S最小的那个，就是最接近的。
好了，深圳APP开发公司本文关于“怎样解决对网络流量进行优化？”就分享到这里。如果您需要联系深圳APP开发公司为你定制开发高端APP项目，请咨询我们网站在线客服或者拨打我们APP开发技术客服联系电话，为您提供详细的APP开发解决方案。谢谢关注，博纳网络编辑整理。
好了，深圳APP开发公司本文关于“怎样解决对网络流量进行优化？”就分享到这里。如果您需要联系深圳APP开发公司为你定制开发高端APP项目，请咨询我们网站在线客服或者拨打我们APP开发技术客服联系电话，为您提供详细的APP开发解决方案。谢谢关注，博纳网络编辑整理。
当前文章链接：/construction/appkaifa/15171.html
如果您觉得案例还不错请帮忙分享：
[声明]本网转载网络媒体稿件是为了传播更多的信息，此类稿件不代表本网观点，本网不承担此类稿件侵权行为的连带责任。故此，如果您发现本网站的内容侵犯了您的版权，请您的相关内容发至此邮箱【qin@198bona.com 】，我们在确认后，会立即删除，保证您的版权。