如何提升app打开速度手机(如何提升阅读速度与阅读技巧)

App运行速度分析以及初步优化方案

一、 App运行速度分析

(1)硬件约束

CPU主频，多核；

CPU主频决定手机的运算速度，多核则更多体现在并发任务方面。

内存：运存与内存（RAM+ROM）

图1-1 移动端内存示例图

运存是指手机运行程序时的内存，也叫RAM简称运存；RAM越大，手机可运行的APP应用程序越多，运行越流畅，目前RAM基本是2GB够用，3GB流畅，4GB极佳。

内存是指手机的存储控件，也叫ROM；ROM越大，手机储存的文件空间越多，目前ROM基本是16GB，32GB，64GB；ROM不影响手机的运行速度。

当运存（RAM）匮乏时，运行大型APP会出现卡顿、黑屏甚至出现暂时性卡死状态。

在运存不够时可以采取手动关闭后台不必要的程序进行释放，或者通过手机管理软件进行内存释放，例如手机管家、手机安全卫士等。

(2)网络环境影响以及服务器接口环境

网络状况直接影响业务型APP的体验，例如用户登陆业务；登陆时手机端需要向服务器发送用户的登录名及密码等信息，服务器进行信息核对后返回登陆状态指令，手机端接收到返回信息进行业务跳转。登陆业务只需要进行一次接口调用，在网络和服务器环境都理想的情况下，秒内是可以被用户接受的。

手机端针对网络环境可采取相应的缓存策略以降低服务器的频繁访问，从直观上提高页面响应速度。根据业务级别提供相对可靠的有损服务，可采用懒加载、延迟异步加载等方式降低服务器压力。

对于服务器可采用缓存服务器、分布式服务器、反向代理等方式进行数据提供业务，对于图片、视频等媒体资源采用CDN进行加速。服务器端的优化性能提高率远大于手机端优化的提高率。

(3)View的绘制过程

Measure(计算) -> Layout(定位) -> Draw(绘制)

整个View树的绘图流程是在ViewRoot.java类的performTraversals()函数展开的，函数做的执行过程可简单概况为根据之前设置的状态，判断是否需要重新计算视图大小(measure)、是否重新需要安置视图的位置(layout)、以及是否需要重绘(draw)，其框架过程如下：

图 1-2 View绘制流程示例图

View的绘制时间可以利用hierarchyviewer工具进行查看。

图1-3 hierarchyviewer示例图

上图Measure为0.089ms，Layout为0.115ms，Draw为1.088ms，该view的绘制总耗时为1.292ms。

(4)16ms原则

目前大多数手机的屏幕刷新频率是60hz，如果在1000/60=16.67ms内没有办法把这一帧的任务执行完毕，就会发生丢帧的现象。丢帧越多，用户感受到的卡顿情况就越严重。16ms时间很短，身为一名应用开发者，为了让用户有更好的体验，应该要充分利用这16ms，确保刷新一帧的时候在16ms内。

图1-4 UI刷新示例图

如果你的某个操作花费时间是24ms，系统在得到VSYNC信号的时候就无法进行正常渲染，这样就发生了丢帧现象。那么用户在32ms内看到的会是同一帧画面。

图1-5丢帧示例图

优化16ms问题可以通过尽可能减少过度绘制，减少布局嵌套，尽可能不要在UI线程做过多耗时操作。

(5)OverDraw过度绘制

当设计上追求更华丽的视觉效果的时候，我们就容易陷入采用复杂的多层次重叠视图来实现这种视觉效果的怪圈。这这很容易导致大量的性能问题，为了获得最佳的性能，我们必须尽量减少Overdraw的情况发生。

图 1-6 过度绘制四种级别示例图

蓝色、淡绿、淡红、深红代表了4种不同程度的Overdraw情况，我们的目标就是尽量减少红色Overdraw，看到更多的蓝色区域。

(6)GC垃圾回收

GC一般耗时在几毫秒到几百毫秒之间，然而对于手机16ms渲染机制来说，GC会带来不小的开销，所以在开发过程中尽量避免显示调用GC。频繁GC会导致页面卡顿，当执行GC操作时，任何线程都进入暂停状态，等待GC操作结束后才能够继续运行。导致频繁GC有两个原因：

1、 内存抖动，即大量的对象被创建后又在短时间内立刻被释放

2、 瞬间产生大量的对象会严重占用Young Generation的内存区域，当达到阀值时会触发GC过程。

以上这些GC操作可能会造成丢帧情况，如下图：

图 1-7 GC时丢帧示例图

24ms的GC形成了丢帧，用户感知到页面卡顿。

(7)同步任务过多

页面启动时同步任务过多会在短期内过多占用手机资源，直接导致其他性能下降，影响页面响应时间。例如在Activity的onCreate方法中进行了大量的同步任务。

二、 初步优化方案

综上所述，App运行速度分析概括为以下七点：硬件约束、网络环境影响以及服务器接口环境、View的绘制过程、16ms原则、OverDraw过度绘制、GC垃圾回收、同步任务过多。在这里我们只对移动端开发并对后面五点提出相应的初步优化方案：异步延迟加载。

不妨先针对View的绘制过程、16ms原则来分析下某首页，采用hierarchyviewer工具分析首页如下：

图 2-1 首页MLD分析示例图

从上图可以看出首页包含了1435个view，Measure耗时43.476ms，Layout耗时1.141ms，Draw耗时2.840，总耗时47.457ms（大于16ms）。基于16ms原则，该页面会出现丢帧情况从而导致卡顿现象。针对这种长篇幅的页面可以根据实际情况进行异步延迟加载，对于第三屏、第四屏、第五屏采用梯级延迟加载从而避开同步加载。

异步延迟加载的关键是延迟时间为多少是合适的，对于配置较低的手机延迟相对要高一些，对于配置较高的手机延迟相对要低一些。如果延迟配置的不合理的话，高配置手机会产生等待延迟加载的内容的情况，而低配置手机会出现优化效果不明显的情况。所以这个时间需要结合业务以及不同配置的手机进行测试来确定的。

针对GC垃圾回收，我们以某APP MainActivity为例子分析下。MainActivity作为项目中所有Activity的托管，采用getLocalActivityManager().startActivity().getDecorView()方法获取启动Activity的视图进行显示。jumpActivity为切换Activity的方法，每次进行页面跳转时必须经过该方法，该方法包含GC过程。通过测试分析统计出每次跳转页面GC的耗时在8ms到300毫秒之间，这里的GC时间会随着下个启动页面的工作量越多而耗时越长。我们采用异步处理一下，GC过程耗时在0~4ms之间，效果提升显著。

使用低配置的手机打开某APP进入首页时会黑屏8~·14秒，然后出现界面，通过代码分析发现首页同步初始化五个重量级的Fragment，导致系统运存缺乏，影响了后续的界面绘制渲染等逻辑。我们采用异步延迟加载进行处理一下，先对第一个主Fragment进行异步加载，主Fragment加载完毕后再异步加载第二个Fragment，接着第三个，最后第四个，这样就可以在短时间内合理分配运存，避免了黑屏的情况。

以上就是App运行速度分析以及初步优化方案，我们只有对App运行速度的硬件环境、开发的软件因素以及App运行交互的原理进行了解后才能制定相应的优化方法，方可对症下药。对于每一个可能影响用户体验的问题进行逐步优化，以先解决大问题、迫切问题为前提，以解决繁琐、细小的问题为原则进行深入优化，App体验才会越来越好。