大型移动应用解决之道 - 前言

大型移动应用解决之道 - 前言
大型移动应用解决之道 - 多进程
大型移动应用解决之道 - 插件化
大型移动应用解决之道 - 组件化
大型移动应用解决之道 - 动态化
大型移动应用解决之道 - 业务框架化
大型移动应用解决之道 - 升级精准化
大型移动应用解决之道 - 测试自动化
大型移动应用解决之道 - 代码检查自动化
大型移动应用解决之道 - 依赖管理
大型移动应用解决之道 - 发布自动化
下图列出了各个方案所解决的问题，本系列文章也是对下图的详细描述。



大型移动应用解决之道，是针对在研发大型移动应用中面临的一系列问题时如何解决的系列文章。我会把我听到的，看到的，研发中用到的，都整理出来，供大家参考。
什么样的应用属于大型移动应用？
我想每个人都会有一个标准，我的理解是，不管是从模块数(几十个)，用户量(千万-过亿)， 团队规模(几十人)等都达到了一定的量。像猎豹清理大师，360手机卫士都已经达到了这个规模。
要把这样规模的一个应用做好，实在不是一件易事，要付出很多时间和精力。
我们从两个方面来了解移动应用有哪些挑战：

1. 功能需求

我们刚才在介绍什么是大型移动应用时，已经说了笔者的理解。 首先是模块数达到了一定量，即功能需求量很大。

2. 非功能需求

2.1 质量

A) 非常好的体验：面对如此大的用户量，产品经理对产品的质量要求相比其他产品相对苛刻，产品不能卡，不能慢，更不能崩，体验一定好，滑动起来要非常流畅。
B) 高灵活性和扩展性：有很多需求，是需要在不发版的情况下去上线和解决的，同时对于一些组件和模块的实现随时可以下发补丁和替换。一些UI的布局及风格等具备动态的特性。

2.2 约束

约束主要体现在移动应用本身的一些特点

A) 流量

对于移动应用的负责人，一定要考虑到流量的问题，流量既是用户的切身利益，流量==money，所以用户是很在乎自己的流量。 相信大家都知道，一些新闻类应用，提供了“文字模式”，“智能下图”等。都是在为节省用户流量考虑。 我身边的一位同事，他在月末的时候，基本上都会开启这种模式，只浏览文字，不下载图片。 我去…..，服。
如果你的应用在做业务的时候，肆无忌惮的使用用户流量，那么好了，你的应用迟早会被卸载掉。
为用户节省流量是我们一定要做的事情，也有很多技术手段来帮助我们实现，比如：java字 节码的混淆与压缩，资源的混淆与压缩，使用其他技术手段替换一些图片，拆分成插件等等。

B) 电量

电量也同样重要，如果你的应用耗电非常快，那么也免不了被卸载。 如果你们团队有 PowerMonitor这样的设备那最好，如果没有，请QA的兄弟或者研发多留意观察吧。一旦发现有耗电的情况，也是有好的工具可以定位排查的，比如：battery-historian。

C) 内存

我们把所有的模块揉到一个进程中去争抢内存，而且由于研发人员技术能力的参差不齐，内存泄漏与抖动时常发生，这些都是导致应用不稳定的因素。

D) 安装包体积

安装包体积也是很重要的一个性能指标，是用户体验很重要的一部分。体积大了之后也会占用较高的内存。 减小安装包体积对于节省用户流量也是非常有意义的。如果安装包体积比较大，那么用户在下载安装你的应用时，就会面临流量的问题。 如果你的应用是20M，你的竞品是10M，用户可能会选择10M的应用，他可能会认为10M的会更好用，可能不会卡机，占用内存更小，更加流畅。有这样想法的用户可能就会选择竞品。 另外，安装包体积越小，升级转化的成功率越高。

E) SDK兼容

SDK兼容的问题，不止Android，iOS也存在。Android从2.x到7.x的版本，SDK在不断的升级，完善，更新。应用要兼容这些版本的变动。如果不兼容低版本或在低版本运行有问题，那么这部分用户就会流失掉。还好android提供了compat包的支持。

F) 非标准兼容

Android的分支平台特别多，有很多非标准的实现，都需要我们去适配。

G) Density适配

奇葩的分辨率，奇葩的密度，我们都需要花时间去适配，测试。
以上总结下来，基本都是移动研发的痛点。所以做一个应用很简单，但是做好一个应用太难了。 需要解决太多太多的问题，当然要解决这些不是没有方法，没有手段。 这也正是，笔者写这篇文章的原因。 下面我会列出所有笔者了解到的方法模式来一一应对这些问题。
下面，我列出了一些解决方法，下面的内容只是简单的列举出解决了什么问题和方法，具体请参考详细链接。