好客户端是怎样炼成的

本文基于淘宝游戏的一次 内部移动开发知识普及培训，主要从开发的角度讲一下一个客户端的开发主要涉及的方方面面，让想没做过App开发的后台开发、产品、设计、运营同学做个快速入门，以利于项目沟通配合。

一、开发前准备

这个主要是产品的设计阶段。

1、产品

确定产品的功能List，主要操作逻辑，产品满足的需求目标，以及过程。输出以PRD、原型图、流程图等为主。

2、画视觉稿

如，概念稿、效果图等。把产品经理的输出以二维、Flash等方式表达出来，让人对目标产品有更清晰的感受。然后按照开发的要求进行切图，把按钮、图标等分割开来，交给开发放在代码中组成界面。另外还要针对Icon、字体等制定规范，一个App中用到的Icon和字体等都是数量有限，且大小遵循一定标准的。

3、交互优化。

面对的细节问题很多，像元素位置摆放是否好操作，按钮可按区域是否足够大，让用户可以很容易按下；用户按下按钮时，视觉上面是否能有直观的感受确认操作已经生效；用户对自己的操作接下来会产生什么后果是否有足够的预期；用户是否会迷失在自己的操作路径中等。

二、开发：

1、页面开发。

这个主要利用平台自身提供的可视化工具，像Android上面使用XML布局，IOS上面使用XCode自带的Xib方式等。拖动元素组成界面。在移动平台上面，页面开发除了要完成视觉稿的100%还原之外，往往会面临一些屏幕适配方面的问题。不同厂商，不同型号，不同系统版本的手机之间，屏幕大小、分辨率等有方方面面的不同。程序员有时要参考视觉稿做出一些妥协，保证在不同机器上面都能接近视觉稿的效果，且极端机器上面也不会出现不可救药的显示问题。

另外，有些娱乐化较强的App还会有一些换肤、夜间模式等方面的需求，这个除了对程序员组织资源有要求之外，往往还要处理一些从网络上面下载资源并替换等问题。

2、前端校验。

足够好的App需要对用户的任何输入都做校验，保证输入内容合理、合法，没有安全问题、基本错误等，然后才会提交给后端，避免无意义的网络交互，以免浪费用户的流量、时间，给后端造成无谓的负担，或带来安全问题等。

3、通信协议。

现在不需要联网的App已经很少了，即然联网就需要通信协议，通常可以选择的有TCP（协议私有特性比较多时使用）、Http（简单方便，很多开源项目支持）、HTTPS（安全，但握手时间较长，登录、付款等关键流程节点使用）、Spdy（通信效率高，在一个连接上面完成所有网络请求，减少握手时间及无意义的请求头等冗余信息）、Http2.0（新发布，可以看作SPDY的正式版）、QUIC（Google针对UDP的一项改进，提高通信速度）等。综合来看各有各的优势，需要适具体情况而定。

4、网关。

这个主要针对后端来说。通常会在与App进行网络产互的服务器最前面加一层反向代码，比如流行的有Nginx等。用来做一些网络通信的基础工作，像登录态检查、安全校验、加签校验、Log记录、7层负载均衡等。

5、长连与Push。

这个问题在IOS上面是不存在的，系统已经提供了足够强大的单一PUSH通道，足够满足需求。在Android上面因为GWF的原因，需要自己动手，不过市场上已经有不少像360、小米这种比较强势的渠道提供了自己的SDK，我们可以直接拉过来用，其原理基本一样。主要解决了以下的问题。

进程保活：只有进程不被杀掉才能保证长连，并有机会从服务端拉取消息，这个是基础。

心跳策略：需要与后端保持一定频率的通信，否则会被中间路由、运营商等把连接掐掉。

多进程共享：同一个机器上面有多个App同时使用了SDK时，只需要保持一个工作就可以。

耗电管理：既要进程保活，又要跟服务器玩心跳，当然很容易耗电了，需要很小心的写代码。要注意的问题有很多，你不要过分打扰机器自身的睡眠。心跳不要太频繁，程序位于前台时可以在正常的通信中把消息下发下来等。

6、本地存储。

这个主要涉及到两方面的数据：一个是图片缓存和管理，这个是缓存大户；另外一个是用户在App使用过程中产生的私有数据、服务端数据缓存。一般来说，图片缓存的管理与图片加载都在开源的引擎里面实现了，不用自己管理。但App使用过程中产生的私有数据、缓存等就需要自己来用代码管理了，既要考虑内存容量，又要考虑读写速度，一般需要实现一个二级缓存等。参考老码农的这篇文章（ http://blog.csdn.net/a345017062/article/details/45227135）

7、工程拆分。

当代码越来越多，工程越来越庞大时，方法数越来越多超过系统支持的极限（体现在Android4.0以下）时，就需要对工程做拆分。对后端来说，拆分成使用RPC互相调用的不同应用仿佛是天然的，但App因为视觉表现层占了很大部分，以及系统设计的自然特性等原因，导致各模块之间耦合程度比较高，拆分要更有技巧性一些。这点儿上IOS做的比较好，可以天然划分成不同的Bundle。Android只能使用Hack的方式只把代码拆分成不同的Dex，但资源部分却无法分开。

另外，工程拆分也方便我们进行模块的动态布署和插件化，做到不需要升级即可更新部分业务逻辑，提高运营灵活性。

8、Hybrid使用。

虽然Hybrid的号号喊了快4年，但直到今天，我们仍然不得不承认它的局限性是短时间内不可破解的。只有以下场景比较适合使用：布局多样且频繁变动的展示模块，添加临时或紧急需求，性能和流量不敏感的地方等。

使用Hybrid时，在技术上需要关注以下几个问题：登录态转移（Hybrid与Native之间互传Session等）、接口互调（Native调用JS，JS调用Native）、对JS接口进行扩展、JS固有的安全问题影响到整个App安全性。

另外，加载速度是Hybrid一个天然的短板，可以针对性做一些资源或页面数据的缓存，以避免用户等待时间过长。

9、PageLink。

这个概念最早由Google提出，其目标是应用间信息开放，及跨应用互调。最后落地的效果差强人意，但这个概念用在App内部做页面管理还是不错的。针对核心页面定义规范、统一、唯一的URI，这样可以解耦页面之间的关联，简化页面之间跳转的成本，也让运营可以带用户飞起来。

另外，对于主流App，如微信、微博、支付宝等，也可以很方便的与依赖其生态系统的应用做集成，用户使用成本更低。

三、精益求精

在这里，我们主要讨论一些常规功能之外的优化方向和优化技巧，让App不只“能用”，还更“好用”。

1、速度。

这个一般在下面列出的这些CPU、内存消耗比较大的地方出现。

列表滚动：是否卡顿。

加载速度：加载新页面时间多长、图片加载速度是否够快、网络数据时速度是否够快。

大数据的处理：数据量比较大时，是否可以很快的看到结果，对于不常更新的数据是否做了缓存。

H5页面优化：加载一个比较大的H5页面时，是否要等很长时间，变化不大的页面是否对JS、CSS等资源做了缓存或预置。

启动速度：在桌面上点击Icon启动应用后，多长时间才能看到欢迎界面，多长时间才能进入首页，又要过多长时间才能看到首页的数据。

这些地方是我们需要下大功夫的地方，是能否和其它App拉开差距的地方，也是最影响用户体验的地方。

2、稳定。

这个主要针对Crash，一个App的Crash率在0.1%以上，就基本不可以接受了，如果超过了1%，那基本可以说是个残次器。没有人能容忍使用一段时间就莫名其妙退出的App。

3、流量。

节省流量会为用户省来时间、金钱，所以好好搞吧，把我们的十八般兵器都用上。

协议压缩：Gzip只是最基本的，把Json这种冗余信息过多的纯文本协议换成Protobuf吧。图片使用WebP格式可以省下1/3~1/5的流量。大屏手机当然要用高大上的清晰图片才符合用户的身份，但小屏手机就没必要了，把图片压一下再给用户。不经常更新的数据，尤其是一些数据量比较大的地方，做缓存和更新检查，确实有必要再更新。多个Http请求合并成一个，可以节约握手的时间，节省Header里面的Cookie等冗余信息。

4、电量。

电量的消耗一般分为前台消耗和后面消耗两种。

App在前台的时间比较长，由于用户正在使用，电量稍微大些也说的过去。当然，让手机热的烫人那种情况除外。

App在后台的时候，即使耗电量不大，但架不住时间长，所以还是要严格把关的。像，是否拿住了屏幕、传感器等的Lock不放；是否有频繁的闹钟唤起，让机器睡不下去；是否发送了过于频繁网络请求等。

5、弱网处理。

拉风的Wifi下大家是看不出差距来的，但信号不好的地方总会有不少，电梯，厕所，商场等地方有时只能使用3G甚至2G信息，关键还经常不稳定。使用传统的如压缩图片质量等方式减少流量是一方面，但有时网络就是不通，怎么破？不同运营商的在数据包不同大小时的表现也是有区别的，可以试一试。有时在单个连接超时不返回时尝试重建连接效果会更好。这里有位大侠提到了弱网模拟（ http://hugozhu.myalert.info/2015/03/28/59-use-raspberrypi-to-build-an-augmented-traffic-control-system.html），大家可以试一试。

6、IP直连。

有一天，国内的权威DNS被劫持了，大家都没法上网，但有一个App半点儿不受影响，什么情况？很简单，它使用了IP直连，除了不怕DNS被劫持以外，平时还可以节省DNS解析时间，真是好处多多啊。

7、峰值处理。

App从启动到退出，总有那么一些时间段里面，对内存、CPU、IO、网络的使用非常集中，表现出来，就是UI卡顿，数据获取比较慢，偶发性的崩溃。对这些任务进行归类，为同类的任务设置线程队列，让它们顺序执行，不要全挤在一起。

四、安全

随着移动互联网的普及，PC安全领域的白帽子黑帽子们也开始盯上了一个个小App，现在的App，安全已经是很基础的问题了。

1、网络安全。

很常见的像重放攻击、数据修改等基本问题无论如何还是要处理的。至于DNS劫持这种小概率事件，只要你的量不够大，其实还好。关键还是量力而行。安全无极限，不要跳坑里出不来了。

2、本地数据安全。

程序运行一段时间之后，总要在机器上面存储一些数据的，用户的历史账号，屏幕密码，登录Token等。现在Root机器横行，让一切系统的黑盒变得白得不能再白，我们只能寄希望于自己的数据加密策略了。

3、包安全。

拿到一些主流的App，反编译并修改代码后重打包，然后放出来，就可以得到很多人的账号密码，这种简单低级的Hack手段让很多人上当受骗。正版躺枪是正常的，谁让你的App树大招风呢。混淆、关键逻辑用C处理，然后加壳，运行过程中自动校验软件包签名是否有变化。这些手段一直是攻与反攻在不停的对攻中互相进步，如果是小App，还是那句话，量力而行吧。

4、Root。

这个其实我们平时不用管，这里提一下。基本有两种方式：利用老版系统的公开漏洞进行提权，获取临时Root或System权限；通过刷机预置支持Root的后门供大家调用。

5、应用攻击。

这个有时也被一些披着羊皮的狼称为“保护”，总之，你的App可能被别人进程注入，然后一举一动都在别人的监控之下。所谓的去广告，清除系统垃圾等基本都需要先注入，这个是没有比较妥善的预防办法的，做到心里有底，把关键逻辑隐藏起来，每个版本小动一下，让它们琢磨不着头脑就好了。

App上的钓鱼比较好识别，其实只要别装些看起来乱七八糟的软件，然后看到让输密码的地方仔细看清楚是否有异常就行了。

Fuzzing经常被用来做测试，但也不排除某些App爱通过这种方式搞别人，如果质量不合格，连最基本的空广播都识别不了的话，也不能怪人给咱找事。

建议大家有空逛逛看雪论坛，乌去等，了解一下常见的攻防。这里推荐一本书：Android软件安全与逆向分析

五、数据

焦点访谈一直教育我们要“用事实说话”，那什么是事实，数据。尤其是App这种放出去给人用的，要了解用户，就必须注重数据。

1、技术数据

这里主要关注的信息有Crash、网络错误率及原因、耗电、流量等，市场上有很多公司专门做这块儿的业务有提供很好的SDK，以及数据观察平台，集成进去就好了。

2、行为数据

这个主要针对用户的使用行为习惯，SDK提供了基本的工具，但在什么地方记录，怎么记录就需要我们灵活掌握了。页面切换，列表项点击，关键字点击等。横向活动/广告推送的效果统计，转化率等。

3、配置

客户端一旦发布出去，我们就失去了绝对的控制权，必要的云端控制还是要加上的，如新业务的开关控制等。

4、基础数据挖掘。

用户只要使用我们的服务，我们就可以得到如下的信息：终端、网络、UV、渠道、留存、地域。根据这些基础信息，我们可以为每个用户做画像，打上标签，可以更了解用户，为用户定制更个性化的服务，推送更适合它的产品，或者营销内容。以数据促进服务的改进，是我们的终极目标。

5、用户反馈

对于那些愿意通过App内的反馈提交页面向我们提意见的用户，都是在我们的App上面花了时间和心思，并且对我们寄于厚望的人。对这些意见，我们要提起重视。对改进类的意见，慎重考虑；对吐槽的，要思考背后的需求；对反馈不清晰的，要做回访。

六、发布

丑媳妇儿总要见公婆的，我们也一定会走到发布环节。

1、灰度。

测试完直接往外扔的话，是对用户不负责任。通常，视项目具体情况，我们可以选择以下几种手段来逐步放量并收集问题，确认没有不可接受的问题之后再往正式上线。Show Case、使用访谈、Beta测试群、部分灰度放量。

2、发布。

对Android来说，可能的渠道有官网、老版本推送自更新，360、小米、应用宝、PP助手等App市场之类的各种渠道。我们通常会选择其中一个可以自由控制渠道，如官网、老版本自更新等，做部分放量，进行充分灰度，然后再全渠道铺开。

对于IOS来说，可以使用企业包或者在破解软件渠道部分放量，做充分的灰度，然后再正式上AppStore。

3、升级

App一旦正式发布，就不受我们控制了，一旦出了紧急问题，如安全、严重Bug等，就需要用到一些非常规手段了。Hotpatch、强制更新等。

4、自更新

自更新是我们可以全权控制的一个发布渠道，且速度快，短时间可以放很大的量，这里单独提一下。一般可以在Wifi下静默下载，然后提示用户直接安装、在Android上面还可以做一下二进制差量，实现增量更新，不用每次都下载整包。

七、节奏

开发节奏方面，其实所有的软件工程都是共通的，不过由于客户端的特殊性，如，发布/更新成本高、体验为王等，对敏捷的要求更高一些。需要我们在产品策略上快速试错，快速响应修改；在开发上，注重版本迭代期间的重构，避免代码遗留问题过多，维护性降低；在沟通上面，注重速度与合力，减少沟通成本，对不确定后果的需求可以先执行再看数据，根据反馈迅速修正。