前言
前不久,几个朋友聚会,谈到了现在的后辈,我就说起了那个大三就已经拿到网易offer的小学弟。
这个学弟是00后,专升本进入我们学校的。进来后就非常努力,每次上课都是第一个到教室的,每次都是坐第一排,不是演,而是实实在在的非常认真的在听讲,也是班上为数不多的上课会额外带一个专门的笔记本的学生之一。
半个月前,我看见他的空间上传了网易offer的照片,就私下和他交流了一下。
他说,他们公司不远的地方就是阿里,他的下个目标是阿里P7。我在夸赞之余更多的是感叹:现在的年轻人真的是太拼命了,网上漫天飞舞的35岁中年危机也不是空穴来风。
启动模式
要准确的测量APP的启动时间,首先我们要了解APP整个启动过程。 启动过程,一般可以分为以下三类:
爱奇艺Android客户端启动优化与分析
从上图可以看出,启动过程中,Cold的模式下,生命周期中做的事情最多,启动的时间最长,因此,我们以冷启动来衡量APP启动时间。启动过程中,如何判断哪些生命周期影响启动速度呢?
启动过程
我们知道,APP的启动和运行,就是Linux系统创建进程和组件对象,并在UI线程中处理组件消息的过程。
启动过程图:
App的启动过程,可以划分为三个阶段:
3.1 创建进程
当APP启动时,如果当前app的进程不存在,便会创建新的进程;App主进程启动后,如果启动某个组件,并且该组件设置了android:process属性,组件所运行的进程不存在,也会创建新的进程。
需要注意的是,如果在启动阶段,初始化的组件中,包含了多个进程,便会创建多次进程,BindApplication操作也会重复执行多次
3.2 创建UI线程及Handler
进程创建后,会通过反射,执行ActivityThread入口函数,创建Handler,并在当前线程中prepareMainLooper,并在Handler中接收组件的消息,我们来看一下Handler中处理的消息:
- LAUNCH_ACTIVITY,启动,执行Activity
- RESUME_ACTIVITY,恢复Activity
- BIND_APPLICATION,启动app
- BIND_SERVICE,Service创建, onBind
- LOW_MEMORY,内存不足,回收后台程序
sMainThreadHandler中,处理的消息很多,这里只罗列了,可能在启动阶段可能会执行的操作, 这些操作都是运行在Main Thread中,对启动而言,属于阻塞性的。
Activity生命周期,自然需要在启动阶段执行,但,对于Service的创建,Trim_memory回调,广播接收等操作,就需要重点考虑,其操作耗时性。
3.3 Activity运行及绘制
前两个过程,创建进程和UI线程及Handler,都是由系统决定的,对APP开发者而言,并不能控制其执行时间,在本阶段,执行BindApplication,和Acitivity生命周期,都是可以由开发者自定义。
Activity执行到onResume之后,会执行至ViewRootImpl,执行两次performTraversals,第二次traversal操作中,会执行performDraw操作,同时通知RenderThread线程执行绘制.
从启动的三个阶段,我们可以看出,启动启动时间的长短,决定因素在于,主线程中所做事情消耗的时间的多少,所以,我们的优化工作主要集中在,排查主线程中耗时性的工作,并进行合理的优化。Android手机,系统的资源是有限的,过多的异步线程,会抢占CPU,导致主线程执行时间片间隔增大。同样的,内存消耗状态,GC频率,也会影响启动的时间
总结
现在新技术层出不穷,如果每次出新的技术,我们都深入的研究的话,很容易分散精力。新的技术可能很久之后我们才会在工作中用得上,当学的新技术无法学以致用,很容易被我们遗忘,到最后真的需要使用的时候,又要从头来过(虽然上手会更快)。
我觉得身为技术人,针对新技术应该是持拥抱态度的,入了这一行你就应该知道这是一个活到老学到老的行业,所以面对新技术,不要抵触,拥抱变化就好了。
Flutter 明显是一种全新的技术,而对于这个新技术在发布之初,花一个月的时间学习它,成本确实过高。但是周末花一天时间体验一下它的开发流程,了解一下它的优缺点、能干什么或者不能干什么。这个时间,并不是我们不能接受的。
如果有时间,其实通读一遍 Flutter 的文档,是最全面的一次对 Flutter 的了解过程。但是如果我们只有 8 小时的时间,我希望能关注一些最值得关注的点。
附
(跨平台开发(Flutter)、java基础与原理,自定义view、NDK、架构设计、性能优化、完整商业项目开发等)
自定义view、NDK、架构设计、性能优化、完整商业项目开发等)
[外链图片转存中…(img-Gmf7Z5Js-1621325389229)]