Android 性能核心揭密

其实我发现不少人不注重性能的开发，这样产品体验会很差的！好吧，一起来看下吧！

移动互联网是用户体验为王的时代，而排在影响用户体验的问题如快速、流畅、省电等，都与研发优化直接相关。
推荐使用traceview和monkey等工具来测试应用，利用layoutopt和ninepatch等工具优化视图，建议开发者注重代码复用，做好应用分析最大化利用第三方工具。移动开发者一定要精通一门服务器端语言及框架，这样才能搞定海量资源、掌握用户的喜好，了解个性化推荐，特别是在需要建立人/机构和人/机构的关系，引导互动类应用时，推荐选择可快速搭建原型的语言，如ruby on rails、nodejs等。

ANDROID架构图蓝色的上面部分是平时关注最多，基本上都是Java代码，Android是基于MID开发的，在这个上面提供一些库，这些库是纯C++的，如果要调的话是向上面提供API，同时Android提供了虚拟层，这比较类似于，但是是不同的界面，因为有这个虚拟层，做Android开发的时候不需要考虑太多内存方面的东西，正是由于这个原因导致很多JAV程序员转做Android的时候，他们会认为不需要考虑性能优化的问题。其实这是非常错误的认识。

在Android上开发都和传统的Web开发、Java开发不太一样，所以我们做开发的时候需要更多考虑跟Android手机有关系的设计和优化。从用户体验出发讲三点，第一是用户要求快速，因为手机上主要访问数据，所以数据的获得，有几个途径，第一是内存，五毫秒去一个数据。我也有一个内存文件、一个数据库，还有传统IO。这个需要上百毫秒的时间，IO需要这边去桌上拿，时间也不是很长。
Android上有一个返回键，很多iOS设计师过来的时候会把iOS菜单键，把那个设计直接带过来用，直接无视Android的按钮，打破了用户预期，他会觉得无所适从，所有系统原生程序充分利用了返回键。所以我们要尊重用户期望，满足他的心理期许关系到用户体验的第三点是一定要省电，一个手机如果需要每天都充电，算不算一个移动设备？我觉得不算。首先要避免一些复杂算法，我有朋友曾经在Android手机上实现过哈析表，是谷歌这种大公司做Email，还是一个分级的，这个Email先做哈析然后再哈析，他做完以后得意。但是用户发现，当他打开应用的时候，系统会发现耗电量太大了，没过几天他就自己更新了，省了很多电，性能没有受太大的影响。手机上真的不要涉及太复杂的算法。
因为多进程、多限程，并且Android没有退出的设计，所以可以设计一个永远在后台跑的，推出一些信息、提供一些时间。我建议考虑一下实时和非实时两种不同需求。如果实时建议使用谷歌的功能。如果是非实时的需求，建议一定要延长推崇时间，比如隔几个小时、一天扑一次。而且时间可以设置得灵活一些。五比如说设了一个更新的键，可以放一个字段，这个字段代表更新周期，每次更新的时候先把字段做好。可以应付一些一会儿很紧，在你需要平台更新的时候更新，不需要的时候把时间限制设长一些。还有网络请求不要太长，平均每个用户使用时长一分钟，现在在Android手机上一次GPS请求(中国移动基本上2G比较普遍)一次10秒以上比较普遍，一次连接20秒，三次连接用户就关闭了。所以不要频繁请求。可以结合一些压缩方式来减少网络次数。第二点适配问题，分几个问题，硬件、分辨率还有OS。Android手机有各个价格位的。有一个合作伙伴Camera360，他们说在做拍照的时候，需要对不同摄像头做了大量优化，有的是200万像素、有的上千万像素，对图片处理完全不一样。这是比较痛苦的事。

然后看一下分辨率，这是二季度的总结，没有一个手机分辨率占主导地位，最多的是800×480，也只占30%不到的比例。剩下的不同分辨率千奇百怪，现在在中国Android量很大，不可能忽略一个很怪的分辨率，魅族的980×640，但是占6%的比例，所以没有办法忽略。这是最近的关于Android分裂的图，据统计在18个Android设备中，7个不用最新版Android，12个使用最新版短于一周，10个落后最新版两代，15个没有运行Android 3.0。还有内存管理，Android里内存管理是非常难的问题，对于每个内存限制24M，而老式手机上限制16，这种概念大家看好像比较大，但是实际上应用本身会超过十兆，分的内存空间已经非常少，如果你做一些图片应用，拍几张照，直接读出来是长跟宽，一张照片一般都是1兆以上。所以经常会出现out of Memory问题。我们怎么解决这个问题呢？从几个方面解决，首先从视图方面优化。我们善于运用Android提供的工具，谷歌提供了分析视图结构，提供一些建议。FrameLayout不要滥用。不要超过13层嵌套，不要超过80个view。还有一个工具是TraceView，函数单独化时间是多少，这个函数包含所有的子函数的时间是多少。其实谷歌提供非常非常丰富的开发辅助工具，还有很多没有讲到，比如一个随即测试界面的程序。怎么减少View以及View的嵌套层次呢？左边是一个图，右面是上下两行文字。有两种写法，一种是把文字包起来，另外一种是写两行文字，设一个相互关系。看上去没有太大的差别，但是看一下树，如果用嵌套，子模块结构变化这样，如果不用嵌套，相对位置关系就变化成这样。如果只有这条没有任何问题，但如果模块被大量应用在列表里，会导致主线会经常变得很慢，如果滑动的时候会变得很卡。这些是一些小细节。还有一个问题是图片当中，Android提供一个技术，可以把图局部放大，如果直接拉伸，因为每个像素均匀拉伸，那么边角会变得模糊。怎么样从左边无缝拉伸到右边？简单介绍一下这个原理，一张图通过这个工具，把图定义成两个区域，第一是左边和上边的投影，投影到中间会决定你的内容，下面和右边，投影出来的内容会决定你的PNG。小图放大的问题是被均等放大，放大之后变得特别猛，画两条黑线，制定上面和左边，决定了拉伸的区域。边缘不拉伸了。就这个意思。就能产生上面的效果。还有更复杂的，左边这张小图怎么变成右边的图？可以指定不同的复合区域。编辑图片压缩会带来很大的优势，如果处理得好，可以省很多apk大小，下载apk的时候下载率会大幅度提高。做过一个不太精准的统计，下载率50%左右，一半情况会失败，失败情况是因为包太大。图片压缩是很重要的技术。

另外从分辨率上适配，刚才说了系统会提供一些手段帮你做适配。提供几种不同的文件夹，ldpi、mdpi、hdpi，代表三种不同精度，系统会自己分析精度做定位。另外要尽量多使用dp，跟当前设备有关系的一个像处理。Pixel有问题，他们往往想直接用，用PS，Android里不一样，Pixel里有什么问题？有一句话叫supports 想问开发者你的程序适不适配于小屏幕、大屏幕、中屏幕，如果选择否，系统认为你没有经过特殊的配置，这时候会出什么问题？比如800×480的设备，通过大分辨率，会转化为533×320，因为使用了API。他认为你画的点，其实想画在15ph、15px这个点，因为他想帮你做适配。这个时候读API会读错，所以尽量不要用pihel，不要用绝对布局。内存方面的优化，其中一个很大的优化是图片优化，大家知道Bi图直接读大小是X×Y，我们要自己压缩，设一下压缩率就可以了。做应用的很多很多问题，跨写、包括M，其实很简单，可以写很多东西。
还有就是要了解编译器的优化原则。某种程度上是反OO的问题，不要太多用getter和setter，包括访问速度都有一系列的问题。另外下载的时候一定要有buffer。我们的经验是，因为我们做SDO，做了很多数据压缩方面的探索，结合两种技术会导致网络发送数据包大小变成原代码的30%左右，这是非常省流量和减少失败率的方法。别人看代码的时候会出现一些小问题。其实我认为更大的好处还是在于降低了APK大小，可以提升APK下载成功率。最后再说一下当我们写很多代码之后怎么样复用代码。最传统的做法和JAVA没什么区别，优点是稳定，但是缺点是无法集成资源文件。

Android提供了一个新的复用，叫Android Library。第一步是先创建Library工程，别人可以直接用这个工程，不用管资源什么东西。也有一个问题，它的习惯问题。现在开发者不太习惯这种机制，并且会有资源冲突。所以大家要根据自己开发习惯和项目实际情况去考虑这个问题。最后就是讲一下客户端的技术，最后比拼的还是服务。所以掌握服务器开发很重要。个人推荐大家掌握一个容易上手的。其实最终大家拼的还是一个互联的一种服务，而不是客户端做得如何漂亮。另外客户端可能进行一些比较复杂的计算的时候，要深思熟虑一下，你的计算是不是一定要做，是不是数据经常需要更新，如果是的话需要把这个东西放在服务器端啊，服务器端跟客户端涉及一套协议。但如果发展起来之后，这个问题可能不存在，但是目前来说，要根据自己的业务来决定选择什么样的BS2、CS2。综合来看，第一点要跟tracrace和monkey结合测试，然后写代码，最后做好代码复用，精通一门服务器开发构架，尽快变成服务器端构架应用。最后以运用的心态经营应用。为什么呢？说到运营的话，必须要了解，我们有提供了解用户的一种机制，我们是一个非常专注了解帮助开发者了解应用的各种使用情况，包括收集你的crash报表，告诉程序员最容易犯的错误是什么，我们也提供一种双向反馈系统。我们提供一个界面，用户可以通过界面提交反馈，他觉得你有什么不好给你建议，在我们网站上可以看到这个建议，看到建议之后可以给他回复，用户第二次启动应用会看到这条回复，建立了用户和开发者之间双向的渠道。