MoboMarket流量性能提升测试分析—Android图片显示和屏幕大小尺寸关系
作者：李剑 2016-07-02 {{allComments.length}} 40806 干货分享可以帮助新接触android客户端测试的工程师快速掌握内存数据采集的方法。 最近产品线在关注客户端性能问题，提出了多个红线标准，其中当然少不了互联网的基本问题—流量消耗问题。为了提升客户端流量性能，减少客户端的流量消耗，客户端在迭代中提了一个流量性能优化的需求，客户端RD也做了非常详细的分析，并给出了一份非常专业的优化报告，初次看到报告完全懵了，各种专业名词很多都没接触过啊，这可如何是好！！！但是，作为一个认（yao）真（bei）负（da）责（lian）的QA，肯定不能打退场鼓吖，硬着皮头也要上，不懂咱们可以问RD，问度娘啊，咱们可是做搜索的啊！ 详情 ↓
RD分析报告
RD对客户端的流量消耗做出非常详细的分析，最后得出的客户端流量消耗分布如下：
APK包：APK包的下载在3G网络下有相应的产品策略，可以保证用户对这部分流量的预知和管理。
APP图标：MM的显示内容每个APP的图标第一次都是从网上拉取，而图标包含应用的信息熵很高，由于我们产品特性这部分流量消耗存在合理性。但是有优化的空间，后面详细分析。
WEB页面：我们的tab页和一些其他活动页面是web的页面形式的，存在流量消耗的情况，例如music的tab页展示会消耗500k流量左右, 这部分页面的展示通常和运营活动有关，具体需要产品考虑运营与流量的冲突或者有些合理的提示或策略。
闪屏：闪屏运营中的闪屏图片也是一块耗流量的点。一个闪屏图片大约消耗100k左右流量，这部分可以考虑在有wifi的环境获取。这个和PM沟通，结论是闪屏的运营策略高于流量策略。 CS通信：这些通信主要展现、配置和运营策略，这部分数据呈现分散长尾现象，且数据的优先级较高占比低，这部分流量属于合理流量
APP图标的现有问题
因为我们应用中大量常用view中出现图标概率很大，正常使用拉取图标较多，对图标的流量问题优化的投入产出比会很高。
同时参考竞品数据，竞品的图标格式仍然采用相对模糊的PNG格式，图标大小取值很不合理。如在我测试的LG n5，根据系统信息计算的需要图标合理大小应该为183px，MM返回200px的webp图片，9APPS返回100px的PNG图片。虽然竞品的流量会有略微（因为图片格式原因导致优势不大）优势，但体验要差很多。
我们现有的APP图标的拉取策略是根据分辨率宽度进行分级，按级向上取整拉取对应图片。因为手机屏幕大小的限制，图标大小从交互角度上看是手指合理触碰区域的强相关的，根本上应该和屏幕的像素密度相关。而分辨率与像素密度并非线性相关，所以用分辨率作为分级标准可能存在一定的浪费，特别是在低密度手机上。
APP图标的优化
对MM的图标大小的代码逻辑进行全面梳理后，图标的拉取分级应该按照设备的DPI进行分级，而不是现在的按照屏幕分辨率。下图是经过梳理后得出的屏幕密度与图标大小的分布图：
图中横轴为屏幕密度，纵轴为需要的图标大小（如LG n5的屏幕DPI为445则表示需要的图标大小至少为183×183px）。红线表示对数据做线性拟合后的结果。
现在图标的分级分别是65px、90px、130px、200px，此次优化改动希望不做影响大的调整，所以不调整后台的分级策略。按已有的分级数据，结合线性拟合很小的方差，所以按DPI分级也应该是一个简单的正相关对应。因为图标的大小选择实际上是体验相关的，所以按照八十二十原则把图标上溢20%作为标线。然后再根据现有机型（因为没有DPI上报）分步，向下做修正，使上溢部分避开高分步机型。
图标像素分段 (px) | 上溢20% (px) | 对应DPI (dpi) | 机型对齐修正 (dpi) |
65 | 78 | 208 | 200 |
90 | 108 | 288 | 256 |
130 | 156 | 378 | 378 |
分步计算结果如上表，最终划分分段为65px 90px 130px 200px对应(0,200) [200,256) [256,378) [378,+∞)。
图标优化后效果
因为分辨率与密度有一定相关性，但在低配屏幕机上线性相关方差很大，所以在这类机型上会有一定效果。
例如Asus Zenfone 6 A600，该机型是MM的印尼安装机型的top30，屏幕参数为720 x 1280 pixels (~245 ppi pixel density)，该机型实际需要92x92的图标。按照旧算法实际拉取图标为130x130的图标，新算法将会拉取90x90。
优化后对部分低PPI的手机会有一定的流量优化效果，因为图标的拉取量较大，长时间使用优化效果会比较明显。
初步分析
先理清思路，在多看了几遍之后可以开始有了一个初步的概念，其实客户端的改动并不大，只是获取图片大小的算法有变动，优化之前是根据屏幕分辨率大小决定获取图片的，优化后是根据屏幕DPI大小来获取图片大小的，看来也没什么嘛（太天真了）。
但是，但是，仔细想想之后发现不对吖，获取图片大小变化之后肯定会有一部分的用户获取的图片变小了，会不会导致用户体验变差呢？还有些用户屏幕分辨率小但是DPI大的会不会获取的图片更大了呢？流量消耗岂不是增多了？这里肯定还有没有很多没有考虑到底地方！
基本概念理解
首先肯定是要把基本的概念理清楚，在各种百度、找RD咨询、查阅文档之后终于把一些基本的知识补上了：
屏幕分辨率：这个就不用解释啦，就是屏幕长宽的大小，单位是像素（px），主流的Android机器分辨率有320*240,480*800,720*1280,1080*1920等等；
DPI（Dots Per Inch）：最初用于衡量打印物上每英寸的点数密度，就是说你的打印机可以在一英寸内打多少个点，当DPI的概念用在计算机屏幕上时，就应称之为PPI（Pixels Per Inch）。同理： PPI就是计算机屏幕上每英寸可以显示的像素点的数量。当然，你说 DPI大伙也能理解，PPI的计算方法：PPI=√（X^2+Y^2）/ Z；
DP：在android系统中单位DP也就是DIP：device independent pixels(设备独立像素). 不同设备有不同的显示效果,这个和设备硬件有关，Android应用中设置长度都是使用DP，而不使用像素（px）；
了解上面三个概念之后就能大概的读懂上面的分析报告了，但是还是看不明白其中“屏幕密度与图标像素的的分布线性拟合”这张图，这是为什么呢？和RD沟通之后才发现原文隐藏了两个重要的概念：
1） 在客户端代码中设置图标的DP之后，实际显示在屏幕上的大小是多少呢？
原来还有如下的计算方法（出自Android API文档）：
实际显示像素=（DPI/160）* dips
2） 客户端的DP值又是如何设置的呢？是统一的一个值吗？
和RD沟通后原来不同屏幕设置的图标DP是不一样的，翻阅代码发现我们客户端的图标DP设置如下：
DPI分段 | Dip值 |
ldpi | 47 |
Mdpi | 51 |
Hdpi | 60 |
Xhdpi | 60 |
Hdpi_960_540 | 69 |
DPI的分段又是怎么分的呢，查看Android API文档可以得到：
A set of six generalized densities:
• ldpi (low) ~120dpi
• mdpi (medium) ~160dpi
• hdpi (high) ~240dpi
• xhdpi (extra-high) ~320dpi
• xxhdpi (extra-extra-high) ~480dpi
• xxxhdpi (extra-extra-extra-high) ~640dpi
这样一来就真相大白了，咱们可以根据新旧算法计算出来实际获取的图片尺寸吖，再和图片实际显示的像素对比一下，就能看出来是否对用户体验有影响了啊。有种莫名的兴奋感，哈哈（图样图神破）。
但是，问题又来了，主流的DPI有哪些呢？各种DPI的用户又有占多少呢？优化的结果会影响到多少的实际用户呢？
数据素材收集
主流的屏幕分辨率和DPI：第一个想到的就是中关村在线的手机频道，涵盖了现在市场上大部分的机型数据，肯定是最好的数据源，经过一番调查，主流的屏幕尺寸和分辨率出来了，DPI只要使用计算公式算一下就出来了：
主流屏幕分辨率 | 屏幕分辨率对应主流尺寸 |
240*320 | 3.0,3.2 |
320*480 | 3.2,3.5,4.0 |
480*800 | 3.5,3.7,4.0,4.3,4.5,5.0 |
480*854 | 4.5,4.7 |
540*960 | 4.3,4.5,5.0,5.5 |
720*1280 | 4.7,5.0,5.5 |
1080*1920 | 5.0,5.2,5.5,6.0 |
主流屏幕分辨率的分布：从PM处要的数据；
主流屏幕分辨率各尺寸占比：这个数据有点多，这里不再一一列出了，后面的分析会列出来一些有用的占比；
有了这些数据之后，各种分辨率优化前后获取图片的大小，实际影响的用户量也能大概的估算出来了，一个python脚本就搞定了，赞！
数据整理
根据上面统计的各种数据，计算出来的结果如下(已去掉没有变化的行)：
宽(px) | 高(px) | 物理尺寸(inch) | 实际DPI | 客户端列表ICON实际显示大小(px) | 旧版算法获取图片大小(px) | 优化后获取图片大小(px) |
480 | 800 | 3.5 | 267 | 100 | 90 | 130 |
480 | 800 | 5 | 187 | 59 | 90 | 65 |
480 | 854 | 5 | 196 | 62 | 90 | 65 |
540 | 960 | 4.3 | 256 | 110 | 90 | 130 |
1080 | 1920 | 6 | 367 | 138 | 200 | 130 |
可以看出来，在480*800屏幕大小为3.5英寸和540*960屏幕大小为4.3英寸的时候是几获得的图片大小增加了，也就是消耗的流量也增加了；而且在480*800屏幕大小为3.5英寸的时候实际显示100px，旧算法获取90px新算法获取130px图片实际对用于的体验是没多大改善的，但是图片获取却大了很多；
输出报告
根据整理的数据整理输出测试报告：
屏幕分辨率 | 屏幕尺寸 | 屏幕显示像素 | 优化前获取图片大小 | 优化后获取图片大小 | 流量消耗变化和体验变化 | 对应屏幕型号用户占有率 |
480*800 | 3.5 | 100px | 90px | 130px | 流量消耗增加51%，视觉体验稍好 | 8.2% |
480*800 | 5 | 59 px | 90 px | 65 px | 流量消耗较少37%，视觉体验基本不变 | 1.6% |
480*854 | 5 | 62 px | 90 px | 65 px | 流量消耗较少37%，视觉体验基本不变 | 2.8% |
540*960 | 4.3 | 110 px | 90 px | 130 px | 流量消耗增加51%，视觉体验稍好 | 2.7% |
1080*1920 | 6 | 138 px | 200px | 130px | 流量消耗较少39%，视觉体验基本不变 | 0.01% |
其中流量变化为估计值，计算方法为随机截取200px、130px、90px、65px的几张webp格式的图片来计算大小差值；
其中屏幕占有率的计算为分别去对应分辨率在印尼市场占有率乘以屏幕尺寸在该分辨率中的占有率来计算的，屏幕尺寸在分辨率中的占有率数据来自中关村在线；
挑战胜利
测试结论发出之后和RD一番讨论，最后修正了获取图片大小的算法，当然这么详细的测试报告肯定是收到了一番表扬撒（洋洋得意）。
注：此处数据有误，之后修正对齐参数为268，因为267正好是一个边界值；
修正后的测试结果如下：
屏幕分辨率 | 屏幕尺寸 | 屏幕显示像素 | 优化前获取图片大小 | 优化后获取图片大小 | 流量消耗变化和体验变化 | 对应屏幕型号用户占有率 |
480*800 | 5 | 59 px | 90 px | 65 px | 流量消耗较少37%，视觉体验基本不变 | 1.6% |
480*854 | 5 | 62 px | 90 px | 65 px | 流量消耗较少37%，视觉体验基本不变 | 2.8% |
720*1280 | 5.5 | 100 px | 130 px | 90 px | 流量消耗较少34%，视觉体验基本不变 | 1.1% |
1080*1920 | 6 | 138 px | 200px | 130px | 流量消耗较少39%，视觉体验基本不变 | 0.01% |
总结
本次测试前后共经历两天时间，从最开始的迷迷糊糊到最后的给出精确的测试分析结果，中间学习了很多新的东西，也认识了自己的一些不足，总结经验如下：
遇到问题不要怕困难，不要被一些不熟悉的东西吓到，遇到新的东西要先去了解它，不懂的要多问，主动的去学习新的知识，应对新的挑战，才能够不断成长！（此处应该有掌声）
如果你看的意犹未尽，如果你想随时随地充实自己，请扫描以下二维码，关注我们的公众账号，可以获取更多技术类干货，还有精彩活动与你分享~
