1.前言
随着移动互联网的发展，产品的更新迭代，公司业务的不断扩展，移动应用页面布局也越来越复杂，效果越来越炫，自身业务功能越来越多。市面上大部分产品中还接入了大量三方的SDK。随之而来的是App安装包越来越大，界面加载越来越慢，运行速度越来越低。当界面响应时间超出用户能容忍的时间临界点后，大多数用户都会选择强制关闭该应用，不再等待响应。应用给用户留下了很卡，很笨重的印象后，将会大大提高用户的流失率。
为此，我们结合工作中的实践经验和网络部分资料的整理汇总并且提供相关验证数据，为我们的产品优化提供有力支撑。
2. Android端性能优化调研
2.1电池耗电量优化调研
引发原因
- 错误使用WakeLock锁机制导致系统无法进入休眠低功耗节电模式
- 错误使用Service导致应用在后台持续运行
- 频繁地进行网络请求,数据通信导致网络通讯等耗能硬件持续运转
- 频繁持续地使用定位服务、定位服务使用不当导致GPS等高耗能硬件持续运转
优化方案
- 合理使用WakeLock锁机制,使用完毕及时释放让系统能进入休眠模式,必要时可用AlarmManager唤醒系统
- 合理使用Service,后台任务完成后要及时关闭,避免用Service来实现监控类型的需求
- 满足需求的情况下,更新频率低,请求频率较高的接口数据可做本地缓存，减少网络数据传输
- 使用定位服务时，可根据需求选择GPS定位、基站定位或被动定位并减小定位刷新频率
2.2手机发热优化调研
引发原因
- 频繁长时间地执行大量算法逻辑、绘图进行界面刷新、 调用GPS、蓝牙、相机、闪光灯等服务导致高耗能硬件持续运转造成短时间内大量做功引起的热量集中发散
优化方案
- 减小代码冗余度，提高执行效率
- 满足需求的情况下,更新频率低,请求频率较高的接口数据可做本地缓存，减少网络数据传输
- 满足需求的情况下，减少对GPS、蓝牙、相机、闪光灯等高耗能服务的使用
2.3内存消耗优化调研
引发原因
- 错误使用Handler，单例，Activity中内部类等致使Activity无法被销毁回收导致内存泄漏
- 获取相册图片时对BitMap未经压缩读入内存导致内存溢出
- 列表组件未开启视图复用机制，滑动过程中创建出大量的对象
- 从服务端下载的图片直接加载到界面上可能会导致内存溢出
优化方案
- 避免对象对Activity(Context)的强引用，Activity finish之前要手动释放对其的强引用
- 对初始不可见的UI和对象进行懒加载
- 获取相册照片时，根据显示尺寸需求压缩后再读入内存
- 开启列表组件视图复用机制，减少滑动过程中对象的创建
- 服务端下载的照片，根据显示显示尺寸需求压缩后加载到界面
2.4App启动时间优化调研
引发原因
- 应用入口Application类中执行大量耗时的初始化工作。
- 应用首页Activity界面太过复杂,界面布局嵌套太深，控件数目过多
- 应用首页Activity界面onResume生命周期之前执行大量耗时工作
优化方案
- 精简应用入口Application类，应用或者第三方SDK的初始化工作根据需求可以移到Thread中去执行或者延后执行
- 精简首页Activity布局,删除不必要的节点,减少布局嵌套,对初始不可见的控件进行懒加载
- 安装包大小优化调研
引发原因
- 应用功能越来越多，代码量越来越大
- 第三方代码越来越多
- 图片以及他资源越来越多
- 图片资源大小设计不合理
优化方案
- 自身应用结构设计，减少代码冗余，提高代码、UI布局复用性
- 灵活运用.9图减少图片资源占用
- 灵活运用webP格式图片来替代png，jpg。
- 灵活运用shape代替图片来实现控件的着色
- 对体积庞大的三方库可做功能提取或者寻找专注一个功能点的轻型库替代
- 及时删除无用的资源文件，代码片段。
2.5 网络流量消耗优化调研
引发原因
- 上传大尺寸的相册照片
- 频繁的接口请求或网络图片加载
- 不合理冗余度的接口请求
优化方案
- 相册图片提交上传前需根据界面显示需求进行质量或者尺寸的压缩
- 更新频率较低的接口数据或者网络图片,可在本地做数据缓存,定义更新协议
- 网络通信数据可采用Protocol Buffer 或者MessagePack进行数据压缩减小传输数据量
- 服务端提供的网络图片可采用webP替代jpg，png
- 合并不合理冗余度的接口请求
3.iOS端性能优化调研
3.1电池耗电量优化调研
引发原因
- 优化方持续的驱动设备的GPS定位、蓝牙、相机、闪光灯等造成的持续耗电
- 持续的网络传输，尤其是非Wifi环境造成的持续耗电
- 持续的高频度使用CPU/GPU、内存（例如长时间看视频、做图像处理等）造成的持续耗电
优化方案
- 在满足需求情况下，减少GPS定位，蓝牙、相机、闪关灯等耗电量较大的硬件
- 在满足需求情况下，减少集中网络传输的情况
- 注意线程、定时器以及高开销对象的使用
- 注意网络数据的缓存，以及复杂计算结果的缓存
3.2手机发热优化调研
引发原因
- 高频率、长时间的使用手机CPU、GPU、内存、GPS、蓝牙、相机、闪光灯等等消耗大的硬件时造成短时间内大量做功引起的热量散发引起
- 手机电池在高负荷工作放掉一部分电以后，持续高负荷工作导致内阻增大、继续放电导致电池发热
优化方案
- 在满足需求情况下，减少GPS定位，蓝牙、相机、闪关灯等耗电量较大的硬件
- 在满足需求情况下，减少集中网络传输的情况
- 注意线程、定时器以及高开销对象的使用
- 注意后端数据的缓存，以及复杂计算结果的缓存
- 内存消耗优化调研
引发原因
- 局部产生大量Autorelease对象，造成内存暴涨
- 使用DrawRect方法Quartz 2D框架绘图
- 使用复杂UI时没有注意懒加载或重用
- 对象间的循环引用，内存泄露
优化方案
- 局部产生大量Autorelease对象，使用AutoreleasePool包裹
- 使用layer绘制代替DrawRect绘图
- 复杂UI时要重用和懒加载
- 解除对象间的循环应用
3.3App启动时间优化调研
引发原因
- 链接Framework过多，静态库过大，加载时占用启动时间
- 冗余无用的类、函数、变量加载占用启动时间
- 使用XIB，Storyboard等文件
- 网络请求占用时间
优化方案
- 减少不必要的Framework，因为动态链接比较耗时
- 删除无用类，无用函数，无用变量，可以使用工具AppCode的代码检查功能
- 将不必须在+load方法中做的事情延迟到+initialize中
- 尽量不要用C++虚函数(创建虚函数表有开销)
- 不使用XIB，直接视用代码加载首页视图
- 梳理应用启动时发送的所有网络请求，是否可以统一在异步线程请求
3.4安装包大小优化调研
引发原因
- 业务代码越来越多
- 第三方框架代码越来越多
- 图片或其他资源越来越多
优化方案
- 资源优化，删除无用文件，压缩图片，音视频等
- 编译优化，Release模式、异常支持等
- 删除第三方库，繁重第三方库替代，代码抽象，减少无用代码量
3.5网络流量消耗优化调研
引发原因
- 程序缓存机制不够完善，频繁的请求相同数据造成的流量消耗
- API设计造成的接口冗余，发起多次请求引起的流量消耗
- 使用臃肿的数据交互格式，交互数据未压缩造成的流量消耗
- 图片过大造成的流量消耗
- 针对不同网络环境没有针对性策略造成的网络消耗
优化方案
- 缓存，避免网络请求
- 数据缓存，最快的请求就是不请求
- 减少请求次数，合并请求
- API设计减少冗余接口，例如注册后自动登录
- 减小请求带宽
- 文本数据交互格式，考虑使用Protocol Buffer代替JSON
- GZIP压缩，GZIP压缩一般对纯文本内容可压缩到原大小的40%
- 图片格式 WebP格式图片的体积要比JPEG格式图片小40%
- 图片Size请求需求合适大小的Size
- 使用不同网络策略&&弱网优化
- 使用不同的网络策略：
现在2G，3G，4G，WiFi网络并存，网络速度差距也很大，针对每种网络应该有不同的应对策略
