likun.pm

经历了轻客服的开发以及IM SDK的开发，过程中遇到了很多都问题，开发APP与web应用其实差别非常大，APP对测试的要求更高，因为一旦测试完成，发版之后，用户安装成本很高，APP运行出错后用户很难被挽回，而且补救起来非常难，所以就移动应用开发遇到的一些问题，整理一下。

1.基础的公共服务

移动应用开发过程中，APP常用的基础公共服务非常多，可以使用其他平台提供的稳定服务，以来保证开发过程中只需要关注基本的业务模块，而不用分散太多的经历到应用本身的实现。

1）应用统计：友盟，百度统计等都会提供统计服务以及基本的统计以及自定义事件；

2）应用升级：百度内部有自己的升级服务；

3）应用设置：常规包括声音提示，字体等；

4）账户体系：百度账户开放平台；

5）用户反馈：百度内部采用的是ufo；

6）push服务：百度云推送，信鸽，个推等

7）积分服务：

8）广告变现：

 

2.内部开发的依赖关系

在公司内部进行业务开发的时候，新的产品可能对其他业务模块（不管是技术服务模块还是业务服务模块），比如内部的账户系统，运维的mysql集群等等，当新的业务上线的时候，如果对其他业务有依赖关系，一定要以邮件的形式，将可能带来影响知会到各个模块，以方便依赖方做业务支持调整或者是给出可能的问题，防止业务上线后，因为其他依赖模块导致产品的失败。

这块其实是RD实现上需要去关注的，但是pm也应该去关注，及时的提醒到RD。

 

3.对突发情况以及未来的应对策略

APP不同于站点，是用户主动升级的行为，用户不同手机下兼容的版本可能有差异，所以，总会有用户不升级，版本收敛速度比较低。所以针对每次发版，有以下的问题需要有解决的方案：

1.是不是真的有必要把这个功能做成native ，未来用户不继续升级，这个功能要不要持久的维护；

2.发版后如果有功能出了问题，怎么能及时告知用户，推送给用户升级正常版本，有没有办法及时关掉这个服务带来的影响；

 

4.测试需要满足不同的场景

移动端场景比较多，不同的的应用场景下会产生很多的异常，正常的业务流逻辑之外，大量的容错提示都需要考虑到，常规的如下：

1.静止时候的电量损耗，流量损耗，内存；

2.wifi情况下，4G/3G网路环境，2G网络环境，差网络环境，断网的操作等

3.crash的各种场景，重启机制，杀毒软件杀死进程后的重启机制；

4.应用图片不能被系统app图片相册识别，暴露给用户；

5.不同的系统：ios，安卓，不同的系统版本， 不同的机型，不同的机型版本；

 

5.APP的灰度与正式发版

跟web的小流量一样，app的灰度测试，会针对人群，一批一批的去升级，看看效果与反馈，灰度三个次，再全量开放。

发版后关注用户升级，通过运营手段推动用户升级，看看用户反馈以及服务端的数据。