个人博客网站开发背景论文,node.js做直播网站,寻找长沙网站建设,建设银行mylove网站一、APP启动流程 首先在《Android系统和APP启动流程》中我们介绍了 APP 的启动流程#xff0c;但都是 FW 层的流程#xff0c;这里我们主要分析一下在 APP 中的启动流程。要了解 APP 层的启动流程#xff0c;首先要了解 APP 启动的分类。
1、启动分类
冷启动 应用从头开始… 一、APP启动流程 首先在《Android系统和APP启动流程》中我们介绍了 APP 的启动流程但都是 FW 层的流程这里我们主要分析一下在 APP 中的启动流程。要了解 APP 层的启动流程首先要了解 APP 启动的分类。
1、启动分类
冷启动 应用从头开始启动即应用的首次启动。需要做大量的工做耗费的时间最多。 热启动 当活动有驻留在内存中系统只是把该活动放到前台无需重复对象初始化、布局扩充和呈现。例如按了home键相对于冷启动开销较低。 温启动 用户退出应用程序随后又从新启动可是活动的进程是有驻留在后台的。例如按了back键退出应用。 2、生命周期
冷启动 对于冷启动的耗时计算比较复杂除了 Activity 本身的生命周期外还要考虑 Application 中 onCreate 的耗时操作。所以对于冷启动来说一般从进程创建即 Application 的attachBaseContext 方法开始计时到完成视图的第一次绘制即 Activity 的 onWindowFocusChanged 方法停止计时。 冷启动 Activity 生命周期 onCreate() - onStart() - onResume() - onWindowFocusChanged() 热启动 相比于冷启动热启动省去了 Application 的初始化以及 Activity 的 onCreate。热启动生命周期 HomeonPause() - onStop() 热启动onStart() - onResume() 温启动 温启动生命周期 BackonPause() - onStop() - onDestory() 热启动onCreate() - onStart() - onResume() 可以看到温启动相比热启动Activity 生命周期增加了一个 onCreate() 方法在使用 Back 时也比 Home 多执行一个 onDestory()。
二、启动时间统计
1、埋点统计 根据上面的生命周期在不同方法中打印当前时间通过查看 Log 计算不通启动方式的启动耗时。
2、查找Log 通过查找 Log 关键字 Displayed 查看 APP 入口信息即包含启动时间。
adb命令 adb logcat | grep Displayed 结果输出
I/ActivityManager( 384): Displayed com.test.myapp/com.test.myapp.MainActivity: 1734 ms (total 1734 ms)
3、adb命令统计 adb shell am start -W 包名/启动类的全限定名 实际使用
adb shell am start -W com.test.myapp/com.test.myapp.MainActivity 冷启动需要杀掉最近任务进程再使用上面的命令。热启动需要 Home 键退出应用后使用上面命令。
结果输出
Starting: Intent { actandroid.intent.action.MAIN cat[android.intent.category.LAUNCHER] cmpcom.test.myapp/.MainActivity }
Warning: Activity not started, its current task has been brought to the front
Status: ok
LaunchState: HOT
Activity: com.test.myapp/.MainActivity
ThisTime: 79
TotalTime: 79
WaitTime: 82
Complete LaunchState启动方式 COLD冷启动、 HOT热启动和 WARM温启动。 ThisTime启动多个 Activity 的最后一个 Activity 的启动耗时。 TotalTime启动多个 Activity 总耗时包括新进程的启动和 Activity 的启动。也就是说开发者一般只要关心 TotalTime 即可这个时间才是自己应用真正启动的耗时。 WaitTime应用进程的创建过程 TotalTime就是总的耗时包括前一个应用 Activity pause 的时间和新应用启动的时间。 如果只关心某个应用自身启动耗时参考TotalTime如果关心系统启动应用耗时参考WaitTime如果关心应用有界面Activity启动耗时参考ThisTime。
多次测试 adb shell am start -S -R 10 -W com.test.myapp/com.test.myapp.MainActivity 其中 -S 表示每次启动前先强行停止-R表示重复测试次数注意反斜杠、包名、类名。所以可以通过 -S 设置冷/热启动。
三、方法耗时统计 traceview 统计可以用代码统计。也可以用 Android Studio自带的 cup profiler 来统计。
1、Debug Trace
Override
public void onCreate() {super.onCreate();Debug.startMethodTracing(main_trace);……Debug.stopMethodTracing();
} 生成文件路径storage/emulated/0/Android/data/packagename/files/main_trace。 然后直接将该文件拖入到 Android Studio 中就能看到对应方法执行的时长从而进行相关的优化如是否可以在异步线程操作该方法或者考虑懒加载的方式根据自己的业务找到合适的方法。
2、CPU Profiler Profiler 是 Android Studio 内置的工具。如下配置 1run - edit configurations 2勾选start recording a method trace on startup 3从菜单中选择cpu记录配置profiling菜单下勾选两个复选框 4apply -- profile模式部署。 详细使用参考Android app的启动优化总结
3、systrace
Override
public void onCreate() {super.onCreate();Trace.beginSection(Launcher);……Trace.endSection();
} 命令行终端进入如下目录 /Users/tian/Library/Android/sdk/platform-tools/systrace 输入如下命令进入监听状态 python systrace.py -o main_trace sched freq idle am wm gfx view binder_driver hal dalvik camera input res 此时运行代码完成之后在命令行窗口按 Enter 键结束监听然后会生成目标文件 main_trace同样使用 Android Studio 的 Profiler 工具进行分析。
三、优化策略
1、优化onCreate onStartonResume函数 由于许多内容在 Activity 的 UI 初始化和生命周期中需要用到所以大部分 Activity 中的成员需要在 onCreate 中通过 new 的方式赋值。这就要求 new 的类的构造函数应该尽可能简单不要有耗时操作以便快速执行。 不要在这些函数中 new 暂时用不到的内容比如一些提醒的 dialog可以在需要提醒的地方再去创建。
2、优化布局文件 减少UI的布局嵌套层数从而减少 layout 时间。 简化XML布局界面布局时层次越多加载的时间就越长。因此应该尽可能的减少布局层次。如果实在层次太多并且无法简化建议不使用XML布局直接在代码中进行布局。 判断嵌套布局是否可以优化的方法 1借助工具Hierarchy Viewer可以看到layout比较耗时的节点。 2直接review xml布局文件。 布局优化方案 1尽量使用 ConstraintLayout 和 RelativeLayout 替换 LinearLayout。 2尽量为所有分辨率创建资源减少不必要的硬件缩放这会降低UI的绘制速度。 3首次不需要显示的节点尽量设置为GONE。 3、优化draw过程 去掉不必要的背景比如如果子节点和父节点size一样那么父节点的background可以不设或者设为null。 尽可能少用或者不用高质量图片以提高运行效率。
4、优化数据访问 有些属性需要在 onCreate 就获取而这些属性保存在 ContentProvider 中。可以从下面两方面进行优化 1少用 cursor.getColumnIndex。可以在建表的时候用 static 变量记住某列的 index直接调用相应index而不是每次查询。 2查询时返回更少的结果集及更少的字段。只返回需要的字段和结果集更多的结果集和字段会消耗更多的时间及内存。 5、优化自定义控件或UI部件 自定义控件和UI部件不管这些控件是否支持 xml 化实现它们的代码质量很重要要尽可能简化它们的构造过程。
6、代码方面的优化 1使用缓存。尽量将需要频繁访问或访问一次消耗较大的数据存储在缓存中。 2使用多线程。比较耗时的过程尽可能的使用异步加载。避免UI主线程阻塞发生长时间不响应。 3只需要获取图片的高宽时可以设置 InJustDecodeBounds 为 true。这样就不会去 decode 图片减少了图片解析的时间。 4判断语句如果较多时尽量使用 switch..case..而不是使用 if..else..。因为 if..else.. 是从上到下进行判断而 switch..case.. 有对判断条件进行优化。 5for() 循环中有 if() 判断考虑实现为将 if() 判断语句放在 for() 语句外面减少判断次数for 语句可以快速执行。 6String的拼接尽量使用io流。 7数据类型和数据结构的选择。比如hash 系列数据结构查询速度更优ArrayList 存储有序元素。 7、延迟执行 对于 onCreate onStartonResume 函数中的数据或变量初始化不着急使用的可以放到使用时在进行初始化或者放到子线程中处理。
8、空闲时间利用 合理利用程序的空闲时间等待页面都完全渲染完毕之后再执行。例如使用IdleHandler具体使用如下
Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() {Overridepublic boolean queueIdle() {// 执行你的任务return false;}
}); 空闲时执行多个任务:
public class DelayTaskQueue {private final QueueRunnable mDelayTasks new LinkedList();private final MessageQueue.IdleHandler mIdleHandler () - {if (mDelayTasks.size() 0) {Runnable task mDelayTasks.poll();if (task ! null) {task.run();}}// mDelayTasks非空时返回ture表示下次继续执行为空时返回false系统会移除该IdleHandler不再执行return !mDelayTasks.isEmpty();};public DelayTaskQueue addTask(Runnable task) {mDelayTasks.add(task);return this;}public void start() {Looper.myQueue().addIdleHandler(mIdleHandler);}
}
9、锁优化 锁是我们解决并发的重要手段但是如果滥用锁的话很可能造成执行效率下降更严重的可能造成死锁等无法挽回的场景。 当我们需要处理高并发的场景时同步调用尤其需要考量锁的性能损耗 1能用无锁数据结构就不要用锁。 2缩小锁的范围。能锁区块就不要锁住方法体能用对象锁就不要用类锁。 10、内存优化 内存优化的核心是避免内存抖动。不合理的内存分配、内存泄漏、对象的频繁创建和销毁都会导致内存发生抖动最终导致系统的频繁 GC。 1解决应用的内存泄漏问题。这里我们可以使用LeakCanary 或者 Android Profile 等工具来检查我们查询可能存在的内存泄漏。平时编码应当注意避免内存泄漏。 2如避免全局静态变量和常量、单例持有资源对象ActivityFragmentView等资源使用完立即释放或者recycle回收等。 3避免创建大内存对象频繁创建和释放对象尤其是在循环体内频繁创建的对象需要考虑复用或者使用缓存。 4加载图片可以适当降低图片质量小图标尽量使用SVG大图/复杂的图片考虑使用webp。尽量使用图片加载框架如glide这些框架都会帮我们进行加载优化。 5避免大量bitmap的绘制。 6避免在自定义View的onMeasure、onLayout和onDraw中创建对象。 7使用 SpareArray、ArrayMap 替代 HashMap。 8避免进行大量的字符串操作特别是序列化和反序列化。不要使用(加号)进行字符串拼接。 9使用线程池可设置适当的最大线程池数执行线程任务避免大量Thread的创建及泄漏。 11、线程优化 当我们创建一个线程时需要向系统申请资源分配内存空间这是一笔不小的开销所以我们平时开发的过程中都不会直接操作线程而是选择使用线程池来执行任务。所以线程优化的本质是对线程池的优化。 12、IO优化 IO优化的核心是减少IO次数。
网络请求优化 1避免不必要的网络请求。对于那些非必要执行的网络请求可以延时请求或者使用缓存。 2对于需要进行多次串行网络请求的接口进行优化整合控制好请求接口的粒度。比如后台有获取用户信息的接口、获取用户推荐信息的接口、获取用户账户信息的接口。这三个接口都是必要的接口且存在先后关系。如果依次进行三次请求那么时间基本上都花在网络传输上尤其是在网络不稳定的情况下耗时尤为明显。但如果将这三个接口整合为获取用户的启动初始化信息这样数据在网络中传输的时间就会大大节省同时也能提高接口的稳定性。 磁盘IO优化 1避免不必要的磁盘IO操作。这里的磁盘IO包括文件读写、数据库sqlite读写和SharePreference等。 2对于数据加载选择合适的数据结构。可以选择支持随机读写、延时解析的数据存储结构以替代 SharePreference。 3避免程序执行出现大量的序列化和反序列化会造成大量的对象创建。 参考Android APP启动速度优化
