移动研发最佳实践-苗顺平

一个移动应用从开发到上线，我们应该考虑哪些问题？问题出现的时侯，如何完备的提出相关方案？并如何在这些技术方案中作出选择？应用稳定性的检查可以使用哪些工具？从哪些地方可以提高应用的性能？图片、音视频资源、网络、优化算法？兼容性问题和安全性问题又该从何入手呢？带着这些疑问，七牛云存储邀请到思必驰高级技术总监苗顺平为大家进行一个总结和分析，下面是完整的现场记录：
我想先看一下参与移动开发的人有哪些？可以占到一半，另一半是服务端研发。跟大家讨论一下，对于一个移动应用来说我们关注的有哪些方面，从一个想法出来，到最后我们上线，或者说我们在整个的过程中会考虑哪些问题，我们这里面简单的列了一下，也是抛砖引玉，也是自己的一些经验积累；另外一方面是能学习一些新的想法，比如说FIR.im我们也在用，我们也自己搭了一套聊天系统，七牛的服务、CDN我们也在用，能够认识这么多小伙伴很高兴。

第一个问题是最近很大的事件，H5的规划已经确认下来了，但是在业内并没有引起多么大的轰动；第二个是我们的稳定性，第三个是关于性能。第四个是兼容性；还有一个是耗电量；最后两个是安全性和可靠性。我列的不见得全，纬度也不见得是一个纬度，很随意的列举一下。其实每一个都是有一些坑的，也是给大家做一个提醒。先说一下H5，最早接触到这个事情的是在用开心的时候，关于Facebook、开心、人人网都面临一个问题，消息流特别多。

图上右边是我们最早用，但是我们调研了之后否定了这个建议，我否定这个建议的时候承受了很多压力，这个地方并不是说完全的拥护者，或者损毁者，其实这个应该看一看为什么。

关于Native App和Web App有一些区别，为什么要否定H5整个性能呢？我们采用的是原始的方案。这一块我相信现在有太多的例子给了我们一些指导，比如说微信，就是用的这个方案。我们看的朋友圈等等都是这样，只是和大家分享的。如果说有志于做一款性能跟用户体验，跟兼容性各方面都折中的一个方案的时候，大家不妨去思考一下我们的方案是什么？我们的技术人员、产品经理都会面临时间的压力、资源的压力，一开始搞一个网页上去了，过段时间再去返工效果是不好的。

说一下稳定性，最直观的指标是Crash率，我不太清楚在座的研发人员是否了解自己的移动服务的Crash率是多少。这个数字说出来很惊人，两年前我们安卓加iphone是1.6%。也就是说一百次启动里面就有1.6次Crash，这个是非常痛苦的一个体验，现在的确有一些大牛们在这方面下了功夫，我给大家同步一个数据，是跟支付宝的基础负责人沟通时，了解到去年十一月份他们的ios加安卓平均Crash率达到了万分之二，一万次才有两次，两次包含了所有的情况。

现在，大多数的应用有过几个版本的迭代和正常维护流程，基本是千分之几或者是十几的概念，到了十几的概念是没有什么进展了。我们对稳定性这方面是不是有一些直观的认识？比如说一万次里面，不算用户的，如果说发现了一两次，计算的方法跟用户数没有关系。比如说我们应用了一次Crash，心情好可能还会再打开，如果心情不好就直接关掉了，对产品是一个直接的影响。

我先说一下安卓的稳定性建议，里面有很多工具，自己有代码检查工具，比如说Lint工具，种类有十几个类别，每一个类别里面还有很多。我不知道我们的开发人员有没有对它有一个直观的警告和认识，每一条其实都是有原因的。关于稳定性有一个兼容的问题，比如说4.0的API在2.3里面使用了，就会提一个问题，会导致2.3的活动装上之后无法使用。

Findbugs能检查很多问题，越界或者其他的一些问题，这个地方往往是能够做一些最初的判断。因为很多情况大家都经历过，我们的应用发出去之后就像泼出去的水收不回来。但是我们又没有遇到的话，非常的不幸。早期还好，几百个用户没有问题，Crash没有关系，但是如果说微信现在出这么一个问题就成为业界笑话了。

关于流程的个有两个工具，第一个是Reviewboard，比如说我这个团队从来没有出过事故，我可以继续做，但是我所知道的团队都出过事故。还有一个是架构清晰的逻辑分层，这个事情说出来很容易，但是做出来比较难。

咱们接着谈性能，用户等待时间七秒和三秒的演变，iPhone第一代的时候，乔布斯引领的苹果团队做过一个体验，一个页面或者一个UI用户最多可以等多长时间是有耐心呢？答案是七秒，这是2005年还是2006年的时候，但是现在3秒不出来，我就认为你是出问题了。性能对一个移动应用来说是非常关键的，谈到影响性能的因素有哪些，这个地方我列了一下：

比如我买了一个很便宜的手机，已经有四五年了，我很珍爱它，还在用，这个时候会出现稳定性的问题，为什么我把这个情况列在第一位？因为它是直接相关，性能这个地方的比例是最少的，统计来讲一两年就会换一个手机，性能差导致一些游戏跑不起来是没有办法的，网络IO占了很大一部分，我们前面的嘉宾也介绍了很多云的服务，有很多云的创业项目和产品，其实这个是对优化我们产品性能有帮助的，IO没有问题。如果我传一兆和1K，肯定是1K更快一些。

第四个是说我们第三方登陆，这个地方我们曾经出现过问题。早期的时候我们做联合登陆，我们做定位，最早的是关于定位方面，我仅仅需要十秒。现在慢慢的也就好了，这方面也是原因之一。

关于性能的建议，这一块说一下图片缓存和网络、数据量以及应用代码和服务器的性能。图片缓存每次分享都会说这个问题，这个跟应用是息息相关的。关于图片缓存是这样的，之前有朋友说我的应用优化很多，每次很慢。但是我发现他们的图片是这样存的，把图片的URL放到数据库里面，把本地的路径放在里面，每次显示图片的时候用URL查询一下，每次滑动的时候总是卡，很多人都知道IO性能是非常慢的，这可能是一个笑话，现在这种做法不用查数据库，就可以判断文件在不在的情况。

还有一个情况是做了一个现成的框架，可以去设置，还可以对你容量大小的缓存设置一百兆或者多大都可以，我们之前做应用开发的人，都做过类似于这样的事情，最后都纷纷放弃了自己原来的那套，或者做一些适应性的调整，其实这是主要问题的一些集中，就像做过推送、聊天的人都知道里面的坑实在太多了。

再一个是优化我们的网络，比如说部署和CDN等等，这里我们有一个亲身体验。比如说做移动互联网开发或者移动平台的人，对服务端架构不是很清楚，能力怎么样很多时候也不会提出来。很多时候会有一个非常明显的提升，比如说文本有20%、30%的压缩率，只有1K的20%到30%，这是最简单的优化，但是做的人也不见得多，但是这个是必须要做的。

第二个是关于图片，我之前是在糯米，跟普通的电商没有区别，有太多的图片需要显示，2G、3G的网络下显示非常困难，图片的方式有很多压缩，第一是使用模块，比如说在手机上快速浏览的时候，最大容忍最低的图片质量是多少？最开始的时候，其实是90%，默认的。100 *100的图片需要十几K或者20K，现在2K网络下平均速度是两到3K,所以这个地方对图片本身的压缩，比如把质量调整到40%，快速滑动是看不出来的。这个对网络IO、对服务的带宽、对手机流量都是一个很大的节省。第二种图片压缩是图片的金字塔，其实最早做的就是地图，最大比例是图片最大，在手机上也是一样的，我们完全可以把这个东西做成离线化，处理所有的图片，适应手机的分辨率，对于手机来说，不需要下载多余的，这个也能提高性能。还有一个是ios、安卓在项目输出的时候，我们团队都有UI，或者是干UI的那么一个人会输出。我们所有的图片是不是都压缩了呢？比如说很多用户下载失败了等等的问题，所以说Pngout是主要的工具。

而音视频这一块，像YY、优酷、爱奇艺其实也一样，视频上去有离线的数据处理中心，都会做一些视频的处理，我们在看视频的时候，用手机上是流畅，家里用无线是1080P。每次切换的时候都会做一些压缩，分辨率也会有压缩。比如说我上传的时候，自己拍一个视频，我拍一分钟是几百兆，但是像YY这种，大家有用过YY的视频客户端或者QQ视频，其实流量很省，是对整个做了研究的。

优化本机的性能是应用代码，多线程大家很多在用，但是不知道清不清楚，比如说我在手机上跑一千多个多线程，这些线程是不是轮转到它呢？或者时间够不够？我们的应用界面有多少是真正需要去做？比如说UI界面来讲，最底下的设置了一个背景，在它上面我们给它叠加了很多层，每一层都是这个背景，UI测试的时候，或者说我们提到的单元测试、人工测试的时候觉得是对的，但是对于CPU来说这么多层，最底下的根本就没有显示，或者没有必要显示，刚才我提到了另外一个例子，图片的缓存是不是在？我只要做一个转换就可以了。

还有一个是合理的使用硬件加速，这个级别是不一样的，这里会有一个新的问题，即这个平台上的硬件支持，在另外一个平台不支持，用这个硬件最好的还是厂商，因为它只负责自己的硬件，但是对于咱们做开放APP的话，这个地方要慎重。我给大家举一个例子，我不知道大家是从哪个版本的百度地图开始使用的，2.0和现在的绘图是不一样的，地图绘制起来非常麻烦，一根线一个点一个面的画起来，非常的痛苦，这个地方我问过他们的技术人员或者产品负责人，我说为什么用这个呢？因为我们当时是在糯米的技术上做二次开发，他说他们做过一些分析，在通用的场景下适当的选择自己的用户。

优化算法这一块有些可以列出来，我们现在做的一些名字规划，这里提一点我们的业务，比如说我打电话给伍总、星星，其实都是名字规划的一种处理方法，并不是他都知道，而是说我们预先做了处理，因为处理一个名字需要九毫秒，非常痛苦。我们优化了之后，处理十个名字也不会超过一个毫秒，这是算法的优化，但是对于处理的结果是不一样的。

兼容性这一块OS版本，是SDK版，在做移动开发的时候，一定要注意我们适配的版本是什么，支持的平台是哪些？这是非常现实的问题，上图列了一下安卓系统的市场占有率，到2014年9月份，已经有很少的用户还在使用2.0了，这是OS一个较大的演变过程，系统更新的速度是非常快的。

谈到开发工具了，也说一下相关的东西，说到设计这一块，它是我们所有UI的源头，设计人员有没有同步显示在手机上？1080P的手机出来的时候，我们说分辨率好高，做了一系列的图我们看着很漂亮，在PC、投影和屏幕上，但是在手机上没法看，因为我们的字体太小，看不到，所以腾讯这方面也是巨头提供的工具，做了PS Play，我希望大家推荐一下。如果我们UI没有做这个事情的话，我们可以提高一下，是在同网络下的wifi传到手机上。

适配这个问题也是很重要的，以前在联想采购适配的费用是七十万人民币，对于初创的企业非常难，有一些云测试平台，大家可以试一下，包括版本的适配、API的适配，分辨率也可以。网络兼容性这边设置网速，可以在电脑上模拟2G、3G甚至更高的网络测试，这样可以体验你应用的速度，这个速度还是非常靠谱的。

耗电量是服务端不需要关注的问题，机房电源很稳定，整个的保护措施也很好，断电是百年不遇的，主要的原件是CPU、屏幕，比如安卓里面有一个应用，点一下就可以知道。我最近有一个软件没有用它，它无形的跑到第一了，我无情的解决了它。如果说我们的应用很不幸跑到第一名，除非我非常喜欢这个游戏，我天天玩。如果没有用的话，卸载率很高，我估计产品的负责人会很头疼。关于耗电量来说，第一个是自己的服务一直在后台运行；第二个是推送方案有问题，比如说刚才说的聊天服务，他们在这方面会有一些考虑，包括从一个山头过另外一个山头，比如说我在地铁上试一下，网络切换我们会遇到，但是处理的方法是不一样的；还有一个是大数据量的网络传输，如果咱们的手机去保持一个链接，大概是十几毫安，如果说要开始传东西，稳定在三百到四百毫安；用手机下载一个东西是三百到四百毫安；屏幕常亮在100到150之间，所以数据压缩提升整个性能的时候，电量也是一种方法。

这里就是一些经验和相关的东西，后台的服务部用时要关掉，避免频繁的唤醒；Sensor用完要关掉，Push方案这一块我们的团队比较小，业务比较少的时候，尽可能选择第三方的东西，任何一个团队除非是专门做推送的，很难做一套很好的推送方案，在到达率和网络占用各方面都考虑的时候，还有一个是网络IO。

安全性这一块刚才也有好多人提到了，之前我们有一个讨论，所有的应用都可以破解，只是说我们愿意不愿意花这么大精力，对于电商来说，一个永恒的话题是每次发起一个活动，用户做什么东西可以拿代金券或者现实的奖励，很多奖励都被黄牛拿走了，他从中牟利，这是一个行业，专门做这个事情，京东、天猫、美团都有专门的团队，这个是我们安全性没有考虑的事情。工具的测试手机和PC这里，通过PC代理看一下自己的包，有的时候你看一下是触目惊心的，很多用户密码是通过明文传的，设置代理在同网站下走整个PC的网络。

安全性我觉得有几个东西大家可以考虑，第一个是HTTPS本身，很多协议都是走APP，都有一些关联的情况。在合理的情况下用HTTPS，它自己的性能不见得好，所以说要合理的使用；加密这一块有很多，还有一个是涉及到第三方工具以及反逆向工程，这一块是做最好的棋盘，做最坏的打算；可拓展性这一块可能一个产品经理提出需求的时候没有想太多，过几天的时候说我要改一下，如果说你写死的，一定是不行的，如果做了很好的分层，只是一个组合的问题，很容易的就解决了，一个分层是非常重要的，而且这个力度是对后续的贡献最大，这和服务端是一样的，UI和业务逻辑的分离尤其重要。

以上内容来自思必驰技术高级总监 苗顺平 在11月29日“开发者实践日技术沙龙”上题为《移动研发最佳实践》的分享。
顺便通知一下大家：开发者最佳实践日·第7期－互联网产品从设计到上线 上海站将于12月13日在上海创业者公共实训基地5号楼1层，EFG一楼举行，欢迎XX社区的各路猿们来相聚！

报名地址： http://qiniu-7.eventdove.com/

「开发者最佳实践日」是由七牛云存储发起并联合各方小伙伴为开发者举办的系列技术沙龙，关注开发者在实际应用中可能遇到的技术问题。致力于为勇于创新的开发者们提供行业内最前沿最热门的技术干货，以技术驱动应用创新，让更多的开发者享受技术带来的生活乐趣。