商城APP开发关于在低流量模式图片处理以及城市列表解决方案。商城APP开发注意在2G和3G网络环境下，我们应该适当降低图片的质量。降低图片质量，相应的图片大小也会降低，我们称为低流量模式。还记得我们前面提到的ImageServer吗？我们可以在URL中再增加一个参数quality，2G网络下这个值为50%，3G网络下这个值为70%，我们把这个参数传递给ImageServer，从而ImageServer在绘制图片时，就会将jpg图片质量降低为50%或70%，这样返回给App的数据量就大大减少了。在列表页，这种效果最为明显，能极大的节省用户流量。
商城APP开发关于在极速模式下解决方案
商城APP开发关于在极速模式下解决方案
深圳APP开发公司发现，在2G和3G网络环境下，用户大多对图片不感兴趣，他们可能就是想快速下单并支付，我们需要额外设计一些页面，区别于正常模式下图文并茂的页面，我们将这些只有文字的页面称为极速模式。比如，首页往往图片占据多数，而且这些图片大多数从网络动态下载的，在2G网络下，这些图片是很浪费流量的。所以在极速模式下，我们需要设计一个只有纯文字的首页。在每次开启App进入首页前会先进行预判，如果发现当前网络环境为2G、3G或4G，但是当前模式为正常模式，就会弹出一个对话框询问用户，是否要进入极速模式以节省流量。如果是WiFi网络环境，但当前模式是极速模式，也会提示用户是否要切换回正常模式，以看到最炫的效果。仅在开启App时提示用户极速模式是不够的，我们在设置页也要提供这个开关，供用户手动切换。
商城APP开发关于城市列表的设计
很多，App都有城市列表这一功能。看似简单，但就像登录功能一样，做好它并不容易。商城APP开发公司将关于城市列表数据整理一份城市列表的数据包括以下几个字典：
·cityId：城市Id。
·cityName：城市名称。
·pinyin：城市全拼。
·jianpin：城市简拼。
其中，全拼和简拼是用来在App本地做字母表排序和关键字检索的。我曾经经历过把城市列表数据写死在本地文件的做法，日积月累，就会产生两个问题：·Android和iOS维护的数据，差异会越来越大。·一千多个城市，每次从本地加载都要很长时间。针对问题1的解决办法是，写一个文本分析工具，找出Android和iOS各自维护文件的不同数据。iOS开发人员喜欢使用plist文件作为数据存储的载体，最好能和Android统一使用一份xml文件，这样便于管理类似城市列表这样的数据。针对问题2的解决方案是，对于一千多个城市，意味着每次都要解析xml城市数据文件，既然每次读取数据都很慢，那么我们干脆就把序列化过的城市列表直接保存到本地文件，跟随App一起发布。这样，每次读取这个文件时，就直接进行反序列化即可，速度得到很大提升。把城市列表数据保存在本地，有个很烦的事情，就是每次增加新的城市，都要等下次发版，因为数据是写死在App本地的。于是，我们把城市列表数据做成一个MobileAPI接口，由MobileAPI去后台采集数据，这样数据是最新最准的。但是这样做的问题是，这个MobileAPI接口返回的数据量会很大，上千笔数据，还包括那么多字段，即使打开了gzip压缩，也会有100k的样子。于是我们又增加了版本号字段version的概念，这个MobileAPI接口的定义和返回的JSON格式是这样的：
很多，App都有城市列表这一功能。看似简单，但就像登录功能一样，做好它并不容易。商城APP开发公司将关于城市列表数据整理一份城市列表的数据包括以下几个字典：
·cityId：城市Id。
·cityName：城市名称。
·pinyin：城市全拼。
·jianpin：城市简拼。
其中，全拼和简拼是用来在App本地做字母表排序和关键字检索的。我曾经经历过把城市列表数据写死在本地文件的做法，日积月累，就会产生两个问题：·Android和iOS维护的数据，差异会越来越大。·一千多个城市，每次从本地加载都要很长时间。针对问题1的解决办法是，写一个文本分析工具，找出Android和iOS各自维护文件的不同数据。iOS开发人员喜欢使用plist文件作为数据存储的载体，最好能和Android统一使用一份xml文件，这样便于管理类似城市列表这样的数据。针对问题2的解决方案是，对于一千多个城市，意味着每次都要解析xml城市数据文件，既然每次读取数据都很慢，那么我们干脆就把序列化过的城市列表直接保存到本地文件，跟随App一起发布。这样，每次读取这个文件时，就直接进行反序列化即可，速度得到很大提升。把城市列表数据保存在本地，有个很烦的事情，就是每次增加新的城市，都要等下次发版，因为数据是写死在App本地的。于是，我们把城市列表数据做成一个MobileAPI接口，由MobileAPI去后台采集数据，这样数据是最新最准的。但是这样做的问题是，这个MobileAPI接口返回的数据量会很大，上千笔数据，还包括那么多字段，即使打开了gzip压缩，也会有100k的样子。于是我们又增加了版本号字段version的概念，这个MobileAPI接口的定义和返回的JSON格式是这样的：
1）入参。version，本地存储的城市列表数据对应的版本号。
2）返回值。如果传入参数version和线上最新版本号一致，则返回以下固定格式：{"isMatch":false,"version":1,"cities":[{},]}如果传入参数version和线上最新版本号不一致，则返回以下格式：{"isMatch":false,"version":1,"cities":[{"cityId":1,"cityName":"北京","pinyin":"beijing","jianpin":"bj"},{"cityId":2,"cityName":"上海","pinyin":"shanghai","jianpin":"sh"},{"cityId":3,"cityName":"平顶山","pinyin":"pingdingshan","jianpin":"pds"}
]}version这个字段由MobileAPI进行更新，每当有城市数据更新时，version可以立即自增+1，也可以积累到一定数据后自增+1。具体策略由MobileAPI来决定。基于此，App的策略可以是这样的：
1）本地仍然保存一份线上最新的城市列表数据（序列化后的）以及对应的版本号。我们要求每次发版前做一次城市数据同步的事情。
2）每次进入到城市列表这个页面时，将本地城市列表数据对应的版本号version传入到MobileAPI接口，根据返回的isMatch值来决定是否版本号一致。如果一致，则直接从本地文件中加载城市列表数据；否则，就解析MobileAPI接口返回的数据，在显示列表的同时，记得要把最新的城市列表数据和版本号保存到本地。
3）如果MobileAPI接口没有调用成功，也是直接从本地文件中加载城市列表数据，以确保主流程是畅通的。
4）每次调用MobileAPI时，会获取到大量的数据，一般我们会打开gzip对数据进行压缩，以确保传输的数据量最小。
好了，深圳APP开发公司本文“商城APP开发关于在低流量模式图片处理以及城市列表解决方案”就分享到这里。如果您需要联系深圳的APP开发公司为您定制商城APP开发服务，请咨询我们网站在线客服或者拨打我们网站APP开发技术客服联系电话，为您提供详细的高端商城APP开发解决方案。谢谢关注，博纳网络编辑整理。
1）本地仍然保存一份线上最新的城市列表数据（序列化后的）以及对应的版本号。我们要求每次发版前做一次城市数据同步的事情。
2）每次进入到城市列表这个页面时，将本地城市列表数据对应的版本号version传入到MobileAPI接口，根据返回的isMatch值来决定是否版本号一致。如果一致，则直接从本地文件中加载城市列表数据；否则，就解析MobileAPI接口返回的数据，在显示列表的同时，记得要把最新的城市列表数据和版本号保存到本地。
3）如果MobileAPI接口没有调用成功，也是直接从本地文件中加载城市列表数据，以确保主流程是畅通的。
4）每次调用MobileAPI时，会获取到大量的数据，一般我们会打开gzip对数据进行压缩，以确保传输的数据量最小。
好了，深圳APP开发公司本文“商城APP开发关于在低流量模式图片处理以及城市列表解决方案”就分享到这里。如果您需要联系深圳的APP开发公司为您定制商城APP开发服务，请咨询我们网站在线客服或者拨打我们网站APP开发技术客服联系电话，为您提供详细的高端商城APP开发解决方案。谢谢关注，博纳网络编辑整理。
当前文章链接：/construction/appkaifa/15172.html
如果您觉得案例还不错请帮忙分享：
[声明]本网转载网络媒体稿件是为了传播更多的信息，此类稿件不代表本网观点，本网不承担此类稿件侵权行为的连带责任。故此，如果您发现本网站的内容侵犯了您的版权，请您的相关内容发至此邮箱【qin@198bona.com 】，我们在确认后，会立即删除，保证您的版权。