好客户端是怎样炼成的

http://blog.csdn.net/a345017062/article/details/45538187

本文主要从开发的角度讲一下一个客户端的开发主要涉及的方方面面，让想了解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上面还可以做一下二进制差量，实现增量更新，不用每次都下载整包。

七、节奏

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