苏州培训网 > 苏州JAVA培训机构 > 苏州其然软件开发培训
首页 培训网 最新资讯 热门问答

苏州其然软件开发培训

13013833891 免费试听

您当前的位置: 苏州IT认证培训 > 苏州JAVA培训 > 张家港学会java需要

张家港学会java需要_JAVA培训

¥详询

班制:周末班

苏州其然软件开发
上课(咨询)地址:苏州市昆山市震川西路111号名仕大厦
报名咨询 预约试听
课程介绍
张家港学会java需要
其然IT 教育师资

王红元高级讲师

专注移动开发领域,多年iOS开发和教学经验,曾经带领团队开发出众多款 优秀APP作品。

国内知名视频聊天软件 < 新浪秀场 > 就出自王老师之手,王老师全 面负责 < 新浪秀场 > iOS客户端的设计和开发,并参与了 < 新浪秀场 > Android、Windows 、web端

开发。同时王老师还曾兼职担任过多家公司技术顾问,帮助其解决开发中的 重点难题。

除此之外,王老师还主导开发了< 智慧城市 > < 天翼看交通 > < 公交wifi > 等热门APP。王老师开发过的作品涉及旅游、交通、社交、视频等方面,对即时聊天、流媒体等技术有深入研究。      

王老师不但开发经验丰富,授课风趣幽默,且激情四射。擅长以各种生活中 的案例出发,帮助学生理解消化学习中的各种难点。另外,王老师教学总是以学生角度思考讲解,备受学生喜爱。

张家港学会java需要

现在学习Java还有前途吗?

张家港学会java需要

在互联网行业,Java工程师是一个技术含量非常高的岗位,支撑了互联网行 业的半壁江山,全世界有一千万Java程序员,目前还在有更多的计算机爱好者向Java的大门奔来。Java发展了20多年,关于Java的悲观论调也不时出现 ,现在学Java还有前途吗?是否已经过了红利期了呢?

Java作为所有编程语言中热门技术,可以说它无处不在,目前全球有着数十 亿的设备正在运行着Java,很多服务器程序都是用Java编写,用以处理每天超过数以千万的数据。

无论是手机软件、手机Java游戏还是电脑软件,每一次购物到每一笔支付成 功,都离不开Java,越来越多的企业也正采用Java语言开发网站,而在所有程序员中,Java开发工程师就占据了20%的比例。

从国内排名靠前网站的主要开发语言,也可以看出Java在各大开发语言中的 地位。淘宝、搜狐、网易等一线互联网公司,都在使用Java开发语言。

这也不难理解,为什么Java现在这么火爆,吸引越来越多的人学习,根本原 因,还是因为企业对Java的认可和应用。

Java有没有前途,需要我们认清自己今后应该怎么走自己的路线,是走技术 ,还是走管理。走技术路线:从初级、中级、高级再到软件架构师。如果说走管理路线:项目经理、部门经理、技术总监。只有清楚了自己要走的路线 后,再往决定的那一方面去努力,学习。除此以外,还有一些人学了这一专业后,从事销售顾问、培训讲师、自己创业的都有,关键是自己要认识自己 ,自己更适何哪一条路。

所以,先认清“正确的结果”,根据正确的结果去设计你的过程。当一个人 具有明确的职业目标时,就会对有助于实现目标的蛛丝马迹都特别敏感,做事情相应也就会很有目的性,而不是稀里糊涂的。所以,就容易到达自己的 目的。如果没有职业目标,脚踩西瓜皮滑到哪里是哪里,学什么技术都没前途。

在未来的几年,Java工程师人才的需求还在不断的加大,由于人才的紧缺, 这个岗位相对于其它专业薪资待遇还是不错的,而且Java工程师的待遇是与工作经验直接挂勾的,当你有了丰富的经验以后,你在这个行业里就比较抢 手了,而且企业所出的薪酬也是相当高的,到时只有你选择他们了。

大数据核心知识

张家港学会java需要

大数据核心知识

Hadoop基础

Hadoop1介绍

hadoop1架构

hadoop2架构(对比hadoop1)

hadoop2环境搭建

HDFS操作

yarn操作

Hadoop应用

Hive数据仓库

zookeeper系统服务

HBase非关系型数据库

Sqoop数据库抽取工具

Flume日志抽取工具

Spark基础

环境搭建

Spark平台介绍

RDD弹性分布式数据集

Scala编程

Spark应用

Spark-SQL组件

DataFrame组件

课程优势

1.真实的企业项目;

2.目前企业中应用广泛的技术路线;

3.部分Spark源码剖析,从源码层面提升问题解决能力。

4.从hadoop1到hadoop2机制原理详细解说;

5.生产环境hadoop集群调优经验;

6.企业真实项目实战;

本阶段学习目标

1.了解hadoop机制原理 ;

2.了解hadoop集群搭建过程;

3.了解Hdfs API使用以及mr编程模型;

4.了解hive、hbase、sqoop、flume等组件的使用方法;

5.Spark平台的优势以及Spark集群的搭建过程;

6.Scala程序设计基础;

7.Spark-SQL和DataFrame API详解。

本阶段学习效果

1.了解hadoop集群的搭建过程;

2.能够**mr和hive来实现简单的数据清洗的业务需求;

3.能够了解数据的抽取,转换,清洗,建模,入库过程;

4.掌握Spark集群的搭建;

5.掌握函数式编程思想,能够根据业务需求编写高质量的Scala程序;

6.掌握大规模离线数据的计算、分析能力。

SystemUI架构分析


>

SystemUI架构分析

SystemUI架构分析 前言 1SystemUI介绍 1SystemUI摘要 2什么是SystemUI 2SystemUI的启动过程 3SystemUI的SERVICES 1音量控制 11音量控制简介 12音量控制SERVICE的初始化 13控制音量过程 2RingtonePlayer 3电源管理 4任务管理 5存储通知 6锁屏 7通知栏 4总结

前言

本文描述Android系统中一个核心应用SystemUI,详细赘述SystemUI中几大模块功能的实现过程。由于作者水平有限,如发现本文中错误的地方,欢迎指正。

1、SystemUI介绍

1.1、SystemUI摘要

在Android系统中SystemUI是以应用的形式运行在Android系统当中,即编译SystemUI模块会生产APK文件,源代码路径在frameworks/base/packages/SystemUI/,安装路径system/PRiv-app/-SystemUI。

1.2、什么是SystemUI

在前文1.1章节中可知,SystemUI是一个普通的APK文件,即是一个普通的APP,但是,手机使用者看见的所有SystemUI的内容都不像是一个APP,为什么?既然是一个应用,就是完成特定的功能,SystemUI主要完成的功能有: (1)、Status bars (2)、Navigation bars (3)、Notification (4)、Lockscreen (5)、Quick settings (6)、Overview(recent task switcher) (7)VolumeUI

2、SystemUI的启动过程

正如1.2中所述,SystemUI任何内容都不像一个APP,自然它的启动也不像大多APP一样启动一个Activity。SystemUI顾名思义就是全局UI,必须在开机过程中完成启动,并不可退出。 回顾Android系统开机的过程,会创建server进程维护系统各种服务,当服务启动完成后调用systemReady方法(如果读者不了解这个过程自行学习Android Boot Flow),如下图:

继续跟踪startSystemUi()方法的实现如下图:

上图中可以看到**熟悉的startServiceAsUser()方法启动SystemUI中的SystemUIService。由APP的启动过程可知(如果读者不了解这个过程可自行学习),Android系统会给应用创建独立的进程,并实例化application对象,在SystemUI源码中的AndroidManifest.xml文件可以看到下图的配置:

上图中在application标签中指定了SystemUIApplication对象,因此在启动SystemUI应用时会创建SystemUIApplication对象并回调onCreate()方法,如下图:

onCreate()中注册ACTION_BOOT_COMPLETED广播,并调用mServices.onBootCompleted()方法,将在后面的内容中赘述该方法。应用成功启动后便可执行上文中提到的SystemUIService服务,并回调onCreate()方法,如下图:

上图中**获取应用的Application实例SystemUIApplication对象,调用startServiceIfNeeded(),如下图:

上图中读者可能会问:mService的实质是什么?回顾1.2章节中的内容,SystemUI主要分几大模块,即在SystemUI中每个模块是一个Service,这样一来,各个模块就非常独立。上图中用java映射机制把每个Service的对象实例化,并调用start()方法启动各个服务,start()方法的具体实现在分析各个服务时再赘述。先了解mService实质都包含哪些具体“对象”,如下图:

如上图所示,SystemUI需要启动的Service包括KeyguardViewMediator、Recent、VolumeUI、SystemBars、StorageNotification、PowerUI、RingtongPlayer共7个,每个service的具体实现和功能将在下文中描述。在图6中可以看到,实例化每个对象是向上转型为SystemUI对象,即图7中的所有service统一继承了SystemUI类,如下图:

SystemUI类提供start()、onConfigurationChanged()、dump()等重要方法,每个方法在各个service中实现不一样,下面将一一描述每个service在SystemUI类中的方法的实现。 至此,SystemUI的启动基本完成,从上文可知,SystemUI是系统中非常核心的应用,在Android系统开机过程中Server进程直接发起SystemUI启动,SystemUI也是固化程序,在保证系统正常运行发挥了非常重要的作用。

3、SystemUI的SERVICES

3.1、音量控制

3.1.1、音量控制简介

如图章节1.2中的VolumeUI所示,当用户操作音量键时,会弹出相应的UI显示,并可以设置音量大小和情景模式。VolumeUI的主要代码在SystemUI/volume下。在不同模式下,音量键触发的UI显示样式不一样,分别是通话、铃声(通知)、音乐、闹铃、蓝牙输出等,如下图 9-13


3.1.2、音量控制SERVICE的初始化

在第二章节中SystemUI的启动过程提到,SystemUI的所有Service**SystemUI类的start()方法启动,并且**图7可以知道,volume service的VolumeUI继承了SystemUI类,所以start()实质是执行VolumeUI中的方法,如下图:

如上图中的代码,首先读取VolumeUI的开关,如果mEnabled为true,则调用initPanel()方法实例化UI等控件元素(如图15),实例化VolumeController控制器(如图17),调用putComponent()保存对象实例,调用updateController()设置控制器(如图18)。

上图中主要是new一个VolumePanel对象,VolumePanel是Handler的子类,且又是VolumeUI的Pannel,因此,VolumePanel负责绘制VolumeUI的内容和控制VolumeUI的显示。先看看VolumeUI的创建过程:


从上图中的代码可见,VolumeUI是以Dialog的形式显示UI,VolumePanel的实例化过程创建Dialog实例和初始化ZenModePanel,到此VolumePanel将会待命。上文中提到VolumePanel同时是Handler的子类,一旦VolumePanel收到相关的Message时,将会处理UI的显示和关闭。

上图是VolumeController的实现代码,主要实现对VolumeUI的Panel的控制,例如上图中的volumeChanged()控制Panel的显示和变化,dismissNow()控制Panel的关闭。那么VolumeController是被谁管控呢?如下图:


图中可以看到先**设置Provider读取是否允许systemui控制volume,如果允许,则设置**AudioManager的实例设置VolumeController到AudioService(读者如果不了解这个过程,可以自行阅读Android Audio策略)。至此,VolumeUI的初始化全部完成。 **本节的学习,VolumeUI的架构如下图:

3.1.3、控制音量过程

当SystemUI的VolumeUI当前不是活动窗口时,一般情况下,音量的设置是**音量键进行操作,当用户操作音量键时,如果用户不拦截音量键事件,那么默认音量键的事件将会在Window中被消化,Window将捕获到的音量键事件**Binder机制将音量变化信息传送到MediasessionService,MediaSessionService同样**Binder机制接着传送到AudioService,**后AudioService也同样**Binder机制把信息传送给SystemUI(VolumeUI),VolumeUI将会作出相应的变化。下面将详细了解这个过程: 当手机设备当前活动窗口在Laucher桌面,Laucher没有对音量键事件作拦截操作,音量键事件将会在PhoneWindow中被消化。在Android的单次点击事件中,分down和up两种事件,分别被分发到PhoneWindow的onKeyUp()和onKeyDown()方法中,如下图20-21:

图20是消化down事件,图21是消化up事件,但音量键还有上音量键( )和下音量键(-),从这两张图可以看到,KEYCODE_VOLUME_UP没有作任何处理,上音量键( )的事件会在下音量键中消化(-), 在down和up事件中都是调用sendAdjustVolumeBy()同一个方法,传递三个参数,**个参数是指定音量类型,mVolumeControlStream为默认值,取值Integer.MIN_VALUE,图20和图21相同,第二个是delta,音量控制类型,即增加或减少,图20传递direction,图21传递0,direction取值1或-1,即1:增加、0:不变、-1:减少,第三个参数是flags,控制VolumeUI显示,每个参数具体的控制的实现代码将在下文中描述。继续跟踪流程,Laucher进程**Binder机制把信息传送到MediaSessionService,如下图:

上图中有获取MediaSessionRecord的对象来控制音量,这里的session变量的值是null,如果读者对此感兴趣可自行阅读相关资料。继续看dispatchAjustVolumeLocked()方法:


图23中可以知道参数只是多了一个packageName,其它的都是图20或图21中的参数值。接着往下看:

在图20或图21中有描述suggestedStreamType的值是Integer.MIN_VALUE,在上图中**getActiveStreamType()方法对值进行转换,变成streamType,它的取值可能是0到10,分别控制不同类型的音量,如3.1.1章节中所以,本例子streamType的值是2,即调整的是铃声(通知)的音量。接着又调用了adjustStreamVolume()方法,如下:


adjustStreamVolume()方法对direction和streamType的合法进行校验,direction取值-1到1,streamType取值0到10。之后**mStreamState获取oldIndex、newIndex和index值,其中oldindex和index作为sendVolumeUpdate()方法的参数,将会影响音量变化的广播和AudioProfile,关于AudioProfile读者感兴趣可以自行学习。图中还可以看到这里还设置了HDMI接口输出。继续看sendVolumeUpdate()方法:

在sendVolumeUpdate()方法中处理了几个事件,一个postVolumeChanged()方法,**终通知SystemUI,后面赘述。接着发送注册到AudioManager.VOLUME_CHANGED_ACTION的action的广播,通知音量改变并携带音量大小的原值oldIndex和新值index,**后通知AudioProfile。继续看postVolumeChanged()方法:


这里**mControlle对象调用volumeChanged(),mController实质是一个什么类的实例,回顾3.1.2章节中的图18,updateController()方法设置了VolumeController的实例,因此mController正是VolumeController在AudioService中的句柄,**Binder机制,把音量变化的信息从AudioService传输到SystemUI进程。转移到SystemUI,如下图:

从AudioService回调到volumeChanged()方法,接着调用mPanel的postVolumeChanged()方法,mPanel在前文3.1.2章节的图15中有描述,是VolumePanel的实例,前文中提到,VolumePanel是Handler的子类,也是VolumeUI的Panel,下面结合代码分析VolumePanel的具体功能:

上文提到VolumePanel是Handler的子类,图29中VolumePanel将发送MSG_VOLUME_CHANGED的Message到自身持有的线程,接着看MSG_VOLUME_CHANGED的代码:


上图中直接又调用了onShowVolumeChanged()方法,顾名思义是显示音量变化的UI,后面接着继续调用resetTimeout()方法,先跟踪onShowVolumeChanged()方法:

上图中首先调用getStreamVolume()方法获取对应streamType当前的音量值,**StreamControl匹配streamType的UI,StreamControl是一个容器,在VolumeUI的初始化时被实例化,装载不同streamType的UI配置,并保存到mStreamControls数组对象中,因此streamType的值确定了StreamControl的类型,StreamControl确定了Dialog显示的UI类型。确定StreamControl的类型后,调用updateSliderProgress()方法更新界面控件,**后调用mDialog.show()方法绘制界面。至此,从按下音量键到调用mDialog.show(),设备对点击事件作出相应,并显示相应的UI到界面上。 回顾图31,resetTimeout()方法的实现如下:

这里会延时发送一个空消息到VolumePanel,what为MSG_TIMEOUT,mTimeoutDelay的值为3000,跟踪MSG_TIMEOUT的处理过程:

很简单,实现的功能就是在VolumeUI显示后,延时3秒自动把VolumeUI关闭。 到此SystemUI的VolumeUI service分析完毕,VolumeUI的流程简单清晰,代码简洁,阅读方便。回顾VolumeUI整个控制流程,可用下图总结:

上图中PhoneWindow是当前活动窗口的进程的PhoneWindow实例捕获音量键事件,当前活动窗口的可以**自身的PhoneWindow对象实例设置streamType,即控制音量键事件触发的VolumeUI类型。当应用程序拦截音量键事件,那么PhoneWindow将无法捕获到音量键事件,此时音量键事件将不遵行上图的流程。如果当前活动窗口时SystemUI,则直接由SystemUI所在进程的活动窗口的PhoneWindow对象实例获取到音量键事件,这时音量键事件的转发和处理和在其它进程(如Laucher)中略有不同,读者感兴趣可以自行比较,本文不再论述。

3.2、RingtonePlayer

RingtonePlayer在SystemUI中扮演播放者的角色,代码在SystemUI/media/目录下,RingtonePlayer的代码很少,功能很简单,同VolumeUI,RingtonePlayer继承SystemUI类,SystemUI应用启动时调用start()方法:

Start()方法很简洁,**AudioService的句柄mAudioService的setRingtonePlayer()方法设置mCallback,mCallback实质是IRingtonePlayer对象的实例,如下图:

IRingtonePlayer有play()、stop()等方法,分别是播放音乐和停止音乐。关于RingtonePlayer的作用,读者可以参考下图:

SystemUI启动后**Binder机制把IRingtonePlayer的句柄设置到AudioServie,其它应用便可**AudioService获取IRingtonePlayer的句柄,在**Binder机制操作RingtonePlayerService去播放声音文件。如果读者感兴趣可自行深入学习Ringtone策略和架构。

3.3、电源管理

电源管理即PowerUI,负责监控电源的变化和通知,源码路径在SystemUI/power。同样PowerUI继承SystemUI类,start()方法如下:

上图可以知道,start()方法注册鉴定Setting.Global.LOW_POWER_MODE_TRIGGER_LEVEL的变化,接着调用mReceiver.init()方法,如下:

图 39注册一个action包含Intent.ACTION_BATTERY_CHANGED的广播接收器,监听电量的变化。然后调用updateSaverMode()方法:

如上图,updateSaverMode()的**终实现也是很简单,根据不同状态显示不同的notification。这就是PowerUI主要的功能,关于PowerUI本文就描述到这里,如果读者对PowerUI的更多细节感兴趣,可参考相关资料。

3.4、任务管理

任务管理即Recents,代码路径在SystemUI/recents。Recents是手机设备基本和常用的功能,主要功能表现为:展示所有任务,可以进行任务切换,可以进行任务的清除。同样Recents是SystemUI类的子类,同样启动时从start()方法开始启动。

Recents的start()方法很简洁,主要是sAlternateRecents.onStart()方法,sAlternateRecent是AlternateRecentsComponent的实例,AlternateRecentsComponent作为一个组件服务,担负着管理Recents的变化过程,AlternateRecentsComponent是单例设计模式,但一般sAlternateRecent只创建一次,过程如下:


图 42**getRecentsComponent()方法new一个AlternateRecentsComponent的对象实例,forceInitialize值是false,AlternateRecentsComponent实例化是会执行图43中的RecentsTaskLoader.initialize()方法实例化RecentsTaskLoader,RecentsTaskLoader是Recents读取器。接着又new一个SystemServicesProxy的实例,mSystemServicesProxy具有ActivityManage和PackageManage的功能,在读取Recents发挥了很重要的作用。回头看RecentsTaskLoader.initialize()的方法:


在RecentsTaskLoader.initialize()的方法中,除了实例化RecentsTaskLoader自己的同时,在RecentsTaskLoader的构造函数中同时实例化比较重要的两个变量,一个是TaskResourceLoadQueue,Recents资源队列,另外一个是TaskResourceLoader,Recents的资源读取器。下面根据SystemUI(Recents)的启动过程了解这些类的作用。 在大多设备当中,**长按HOME键打开任务管理器,HOME长按事件触发由输入输出事件派发者派发到系统进程(system_process)后被WindowManagerService拦截派发到PhoneWindowManager,如图:

上图中handleLongPressOnHome()将事件进一步发送到StatusBarManagerService,如图:

StatusBarManagerService**CommandQueue发送到SystemUI进程,关于StatusBarManagerService和CommandQueue在StatusBar service中论述。**后发送到AlternateRecentsComponent,如图:

到图47,事件经过了几个进程,终于到准备启动任务管理器的界面了,topTask是ActivityManager.RunningTaskInfo的实例,即正在系统运行的Activity,第二参数值为true。RecentsActivity启动回调onCreate()方法:

onCreate()方法完成了实例化RecentsTaskLoader、SystemServicesProxy、RecentsConfiguration,在前面的内容已提到,RecentsTaskLoader.initialize()方法同时实例化TaskResourceLoader和TaskResourceLoadQueue,然后注册一个监听Intent.ACTION_SCREEN_OFF action的广播接收器,即当屏幕熄灭后关闭RecentsActivity。RecentsActivity还复写了onStart()方法:

上图AlternateRecentsComponent.notifyVisibilityChanged(this, ssp, true)通知StatusBar RecentsActivity已经起来,StatusBar需要配合做相应的调整,之后调用updateRecentsTasks(),由于篇幅问题,下文将重点描述Tasks的管理,不再跟随代码的执行流程。 RecentsTasks的管理过程主要包括读取task,读取task资源,显示在RecentsActivity上,清除task。主要包括下面这些类: SystemUI/src/com/android/systemui/recents/model/RecentsTaskLoader.java SystemUI/src/com/android/systemui/recents/model/RecentsTaskLoader.ActivityInfoHandle SystemUI/src/com/android/systemui/recents/model/RecentsTaskLoader. TaskResourceLoadQueue SystemUI/src/com/android/systemui/recents/model/RecentsTaskLoader. TaskResourceLoader SystemUI/src/com/android/systemui/recents/model/RecentsTaskLoadPlan.java SystemUI/src/com/android/systemui/recents/model/RecentsTaskLoadPlan.Options RecentsTaskLoader是一个管理者,RecentsTaskLoader持有TaskResourceLoader,TaskResourceLoadQueue等实例,可以创建RecentsTaskLoadPlan实例,所以RecentsTaskLoader实质并没有去取读取task和task资源,只是负责发起读取task任务。ActivityInfoHandle 唯一持有一个AcitivityInfo的对象,保存Activity的信息,Activity的信息会在RecentsTaskLoadPlan中被查询。TaskResourceLoader 负责task的资源读取,和RecentsTaskLoader一样,它是一个管理者,实质实现读取task资源的是TaskResourceLoadQueue 。RecentsTaskLoadPlan对象实例也是被RecentsTaskLoader持有,实质上RecentsTaskLoadPlan是task读取的参与者和实现者,Options 是RecentsTaskLoadPlan的内部类,主要功能是控制RecentsTaskLoadPlan的读取task的条件。RecentsTaskLoadPlan读取task主要分两个阶段,**个个阶段是 上图中loader是RecentsTaskLoader的实例,调用preloadTasks()方法,即task读取的**阶段,plan是RecentsTaskLoadPlan的实例,第二个参数mConfig.launchedFromHome是boolean值,作用是isTopTaskHome,在启动RecentsActivity之前被赋值。这个阶段主要完成对task的读取。第二个阶段是: 上图中loadTasks()方法就是启动RecentsTaskLoadPlan的第二个阶段,同上图50,loader是RecentsTaskLoader的实例,**个参数this是Context的实例,plan是RecentsTaskLoadPlan的实例,loadOpts是Options的实例,loadOpts在这里的作用是控制RecentsTaskLoadPlan读取task的规则,第二个阶段必须基于**个阶段,也就是说在调用loadTasks()方法前,必须先执行preloadTasks()方法,loadTasks()基于preloadTasks()中读取到的task,从task中读取task的资源。 这两个阶段紧密连连,有先有后,完成不同的功能,下文将具体描述这两个阶段的过程。Loader. preloadTasks()实质调用RecentsTaskLoadPlan的如下方法 在这里会实例化一个TaskStack的对象实例,TaskStack封装了包含List类型的类,TaskStack包含两种类型的List,一种是存储所有的task,一种是filter task list,同时提供一个TaskFilter工具类接口,过滤主要**PakcageName作为匹配。然后调用preloadRawTasks()方法实例化mRawTasks,mRawTasks是一个ListActivityManager.RecentTaskInfo>实例,mRawTasks存储了RecentTaskInfo类型的实例,所以mRawTasks是读取task的关键,看mRawTasks的实例化过程 上图中mSystemServicesProxy是SystemServicesProxy的实例,调用图中的方法,再往下看 上图中mAm是ActivityManager的实例,getRecentTasksForUser()方法实质是**binder调用了远程的ActivityManagerService的方法,关于getRecentTasksForUser()这个方法在ActivityManagerService中的实现,读者可以自行阅读。在这里得到一个ListActivityManager.RecentTaskInfo>的对象实例tasks,RecentTaskInfo实质包含什么数据呢?如图 上图中是RecentTaskInfo的变量,得到这些数据,回到前面图52的地方,看下图

上图中获取到RecentTaskInfo后,把信息重新打包封装到TaskKey中,然后读取Activity的名字,Acitivity的图标,和thumbnail,然后把数据保存到TaskStack中。到此,**个阶段就完成了,在这个阶段完成了读取task的基本信息RecentTaskInfo,然后读取Activity的基本信息ActivityInfo,把数据保存到TaskStack中。 回到图50,**阶段完成后,接着就行图51中的第二阶段loader.loadTasks(),如下图

上图可以看到,这里获取icon和thumbnail都是在**个阶段就已经完成了动作,在这里在根据inRunningTask等条件再次刷新数据罢了。 到这里task和task资源读取完成,上上文中提到TaskResourceLoadQueue和TaskResourceLoader,这两个类在RecentsTaskLoadPlan的两个阶段都有使用,用于异步读取Activity Icon,TaskResourceLoadQueue会管理这些任务。 所有的Task数据到这里已准备就绪,接下下就是把数据显示在Activity上(屏幕上),对于数据怎样绑定到View,本文不再论述。

3.5、存储通知

存储通知即StorageNotification service,在SystemUI中主要完成对存储器变化的通知,即USB连接的变化,存储器的变化SystemUI发送相应的Notification。StorageNotification的启动如下:

StorageNotification的启动很简单,创建一个StorageNotification-EventListener的实例,把StorageNotificationEventListener**StorageManager注册到到MountService。当USB连接或存储器发生变化是远程回调到StorageNotificationEventListener的方法,如下图:

USB变化回调到onUsbMassStorageConnectionChangedAsync()进行处理,存储器发生变化回调到onStorageStateChangedAsync()处理,就是在发送notification通知USB和存储器的变化。这个模块本文就论述到这里,在SystemUI中StorageNotification结构清晰,功能简单,读者感兴趣可以自行了解。

3.6、锁屏

锁屏(Keyguard)service在SystemUI是一个比较特殊的模块,特殊在于SystemUI启动的service只是一个信息传递者,也就是KeyguardViewMediator,并没有做锁屏或解屏的实质操作。在这里,涉及到三个比较关键的类是: /SystemUI/src/com/android/systemui/keyguard/KeyguardViewMediator.java /SystemUI/src/com/android/systemui/keyguard/KeyguardService.java Keyguard/src/com/android/keyguard/KeyguardUpdateMonitor.java KeyguardViewMediator和KeyguardService在源码中位于同一个GIT库(SystemUI)中,而KeyguardUpdateMonitor则位于KeyGuard库中。在KeyguardViewMediator的初始化中主要做了三件事,如图

实例化KeyguardUpdateMonitor的实例mUpdateMonitor,KeyguardUpdateMonitor负责更新已经锁屏界面上的内容,如时间,当然,KeyguardUpdateMonitor只是一个信息传递着,实际去刷新界面的是StatusBar模块。Keyguard模块通知StatusBar刷新解密那**KeyguardUpdateMonitorCallback这个类就行远程回调,该类的实例在StatusBar模块启动时**KeyguardService获取到IKeyguardService的远端实例,**IKeyguardService远程调用IKeyguardService的addStateMonitorCallback()方法实例化KeyguardUpdateMonitorCallback对象,如下图

SystemUI启动的Keyguard模块并没有真正的去操作锁屏界面,而是作为一个信息传递着把信息传递给StatusBar模块。这个模块本文就介绍到这里。

3.7、通知栏

通知栏(SystemBars)service是SystemUI中**重要的service,代码量**多,**复杂的,界面结构也复杂。根据前面的内容可知,启动SystemBars是**调用start()方法,如下图:

这里实质是回调到到SystemBars的onNoService()方法(这里涉及到安全设置启动的模式不一样,本文只讨论正常模式),**后是调用SystemBars的createStatusBarFromConfig()方法

上图可以看到,从string资源文件里面读取class name,**java的映射机制实例化对象,然后调用start()方法启动,class name的值如下图: 该配置文件在SystemUI/res/values/config.xml中。所以实质是PhoneStatusBar调用了start()方法。 SystemBars模块本文分两个阶段论述,**阶段是SystemBars的初始化过程,第二阶段是Notification的显示过程。**阶段主要涉及的类是: SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBar.java SystemUI/src/com/android/systemui/statusbar/BaseStatusBar.java SystemUI/src/com/android/systemui/statusbar/phone/PhoneStatusBarPolicy.java PhoneStatusBar的父类是BaseStatusBar继承于SystemUI,上文提到,SystemBars调用PhoneStatusBar中的start()方法,下面跟随代码看看这个过程。

如上图,调用父类中的start()方法,即BaseStatsuBar中的start()方法。然后调用addNavigationBar()方法实例化导航条,这里不再赘述此功能。继续看BaseStatsuBar中的方法。

如上图BaseStatsuBar中的start()方法,实例化一个StatusBarIconList的对象,此处iconList对象是“空值”,然后**IStatusBarService的实例mBarService对象注册到StatusBarManager?Service。mCommandQueue是CommandQueue的实例,在Status?Bar-ManagerService的远程回调,实现StatusBarManagerService和SystemUI的通信。然后调用createAndAddWindows()方法,方法初始化status bar,notification,quick settings等的View控件。在这里,还需要注意NotificationListenerService的实例mNotificationListener的registerAsSystemService()方法,该方法主要实现StatusBarManagerService和SystemUI的notification的控制通道,也就是说,StatusBarManagerService收到notification变化时,**此通道通知SystemUI显示notification的变化。下文将介绍notification从StatusBarManagerService到SystemUI的过程。 一个APP需要显示notification首先需要实例化一个NotificationManager的对象,然后调用NotificationManager的方法notify()方法把创建好的Notification对象作为参数传进去。

上图中可以看到一个service的对象调用了enqueueNotification-WithTag()方法,该方法实质是远程调用NotificationManagerService中的enqueueNotificationWithTag()方法,该方法如下:

这里会把NotificationManager传递过来的Notification对象进行很多处理,比如变换成NotificationRecord,实质就是把Notification缓存下来。在上图的这个过程,还有一些其它的处理逻辑,在这里就不详细说明了,读者可以自行了解。上图中在代码的末尾调用了buzzBeepBlinkLocked()方法,该方法主要处理Notification的声音和震动的逻辑,本文也不再详述。接着看mListeners调用了notifyPostedLocked()方法,此方法**终会执行到如下图的代码

首先留意上图中final INotificationListener listener = (INotificationListener)info.service;这句代码,info.service返回一个INotificationListener的实例对象,该对象在上文中图66中的mNotificationListener.registerAsSystemService()方法进行设置,所以listener.onNotificationPosted()方法实质是远程回调SystemUI中的方法,如下图

如上图,这里又调用了Notification.Builder.rebuild()方法,该方法主要把**Binder机制传递过来的数据重新组装一些显示View所需要的数据,如notification的布局文件等等。重新组装notification数据后,调用NotificationListenerService.this.onNotificationPosted()方法,然后代码会执行到BaseStatusBar中的如下代码

上图中,代码运行又回到熟悉的BaseStatusBar.java类中,从APP调用NotificationManager的notify()方法到BaseStatusBar的addNotification()或updateNotification()方法,经历了一个复杂的过程,涉及的模块多,模块交互复杂。到此,本文就不再往下详情说明Notification到达SystemUI的处理过程了,读者感兴趣可自行阅读代码。

4、总结

本文详细描述了SystemUI中KeyguardViewMediator、Recents、VolumeUI、SystemBars、StorageNotification、PowerUI、RingtonePlayer 7个模块(SERVICE),其中SystemBars是SystemUI中起到中枢作用的一个模块,因为这个模块和其他模块交互**紧密,而且SystemUI中大多数UI的View都是在SystemBars中初始化和控制显示。不过,SystemUI的功能不止本文中说论述到的,SystemUI还有例如情景模式控制、流量警告和常用的屏幕截屏等功能,本文不再去说明它们,读者可自行去研究SystemUI中的每个功能。


相关推荐:


苏州JAVA培训   苏州JAVA培训班   苏州JAVA培训机构

体验课预约试听

倒计时

12:00:00

课程热线:

13013833891
在线咨询

客服在线时间:早上9点~下午6点,其他时间请在线预约报名或留言,谢谢!

苏州JAVA

免费体验课开班倒计时

11: 41: 09

稍后会有专业老师给您回电,请保持电话畅通

咨询电话:13013833891
推荐机构 全国分站 更多课程

本周仅剩 个试听名额

请键入信息,稍后系统将会把领奖短信发至您的手机

申请试听名额

已有10254人申请免费试听

01电话咨询 | 13013833891

QQ:1413838287
加盟合作:0755-83654572