JobScheduler

1、首先添加引用 <!-- https://mvnrepository.com/artifact/com.dangdang/elastic-job-lite-core --> <!-- 有 elastic-job-lite-spring 就不需要下面这个 pom 引用了，因为已经包含了 --> <!-- <dependency>--> <!-- <groupId>com.dangdang</groupId>--> <!-- <artifactId>elastic-job-lite-core</artifactId>--> <!-- <version>2.1.5</version>--> <!-- </dependency>--> <!-- https://mvnrepository.com/artifact/com.dangdang/elastic-job-lite-spring --> <dependency> <groupId> com.dangdang </groupId> <artifactId> elastic-job-lite-spring </artifactId> <version> 2.1.5 </version> </dependency> 2、添加配置文件信息。 server : port : 8081 elasticjob : regCenter :

上一篇我们讲了java的引用机制，今天我们来一下和它有关的app性能优化(其实也不是很大)。 性能优化的目标 在网上也看到过很多相关的文章，他们基本总结为：快,稳,省,小,描述的很准确.如下图 (注：此图不知道啥时候收集的，如有侵权，立删)： 快 如何让app在运行过程过不卡顿，运行流畅，速度快,也就是说如何解决卡顿呢？我们先看看那些因素影响卡顿？ 1. UI,包括ui的绘制,刷新等 2. 启动,包括冷启动,热启动,温启动等 3. 跳转,页面跳转,前后天切换 4. 及时反馈，点击事件,滑动,系统事件 UI 这个涉及到android的系统显示原理，我们简单了解一下： Android 显示过程可以简单概括为：Android 应用程序把经过测量,布局、绘制后的 surface 缓存数据，通过 SurfaceFlinger 把数据渲染到显示屏幕上， 通过 Android 的刷新机制来刷新数据。也就是说应用层负责绘制，系统层负责渲染，通过进程间通信把应用层需要绘制的数据传递到系统层服务，系统层服务通过刷新机制把数据更新到屏幕上。 换一种方式说：Android 系统每隔 16ms 发出 VSYNC 信号，触发对 UI 进行渲染，如果每次渲染都成功，这样就能够达到流畅的画面所需的 60FPS。（注：FPS 表示每秒传递的帧数。）在理想情况下，60 FPS 就感觉不到卡

原文地址： 《Android功耗改进》 by 保罗的酒吧 最近几年中，Google在一直极力的改进Android系统的续航能力。在本文中，我们将看到Andrdoi自5.0到8.0这几个版本中对于功耗方面的改进。 前言 移动设备的续航时间无疑是所有用户都非常在意的。我们都希望自己的手机一次充电可以使用更长的时间。但遗憾的是，近几年移动设备的电池元件一直都没有重大的技术突破。并且，随着硬件性能的提升却带来了更多的电量消耗。 如果你对比过近几年的Android和iPhone手机，你就会发现：通常情况下，Android手机的电池要比同时期的iPhone电池容量大很多，但是待机方面却没有太大的优势。这显然是Android系统需要改进的地方。 在最近几年中，Google在一直极力的改进Android系统的续航能力。在本文中，我们将看到Andrdoi自5.0到8.0这几个版本中对于功耗方面的改进。 iOS之所以续航优秀，其很大的原因就在于对于后台进程的限制。在iOS上， 后台进程是无法长时间处于活跃状态的 。而Android系统正好相反，通过监听广播，添加后台服务等方式，应用程序可以一直在后台保持活跃。太多进程的长时间活跃，显然会导致电量的快速耗尽。 而反过来，想要 延长电池寿命的重要措施就是尽可能减少后台应用的活跃性 。后文中我们将看到，Android 5.0到8.0的功耗改进，一直都是围绕着

目前市面上的应用，貌似除了微信和手Q都会比较担心被用户或者系统（厂商）杀死问题。本文对 Android 进程拉活进行一个总结。 Android 进程拉活包括两个层面： A. 提供进程优先级，降低进程被杀死的概率 B. 在进程被杀死后，进行拉活 本文下面就从这两个方面做一下总结。 1. 进程的优先级 Android 系统将尽量长时间地保持应用进程，但为了新建进程或运行更重要的进程，最终需要清除旧进程来回收内存。 为了确定保留或终止哪些进程，系统会根据进程中正在运行的组件以及这些组件的状态，将每个进程放入“重要性层次结构”中。 必要时，系统会首先消除重要性最低的进程，然后是清除重要性稍低一级的进程，依此类推，以回收系统资源。 进程的重要性，划分5级： 前台进程(Foreground process) 可见进程(Visible process) 服务进程(Service process) 后台进程(Background process) 空进程(Empty process) 前台进程的重要性最高，依次递减，空进程的重要性最低，下面分别来阐述每种级别的进程 1.1. 前台进程 —— Foreground process 用户当前操作所必需的进程。通常在任意给定时间前台进程都为数不多。只有在内存不足以支持它们同时继续运行这一万不得已的情况下，系统才会终止它们。 A. 拥有用户正在交互的

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 这个文章只是Android历史保活方案总结，没有什么特别的参考意义，Android 已经到10了，100%保活本身就已经不复存在，文章中所有的方案，都是有可能有用，毕竟4.4还有人用，至于要不用可以自己参考，毕竟当PM就是让你应用不死，你能不写代码吗？ 保活通常分为2种方案，一种为提高进程优先级，防止被杀，另一种为进程被杀死拉活 1. 进程优先级 Android系统会尽可能的保持应用进程，但是当需要建立新的进程或者运行更重要的进程，便会回收优先级低一些的进程,这个就是lowmemorykiller的工作。而进程的优先级其实就是 /proc/pid/oom_adj 进程的优先级排序 前台进程（Foreground Process） 可见进程(Visible Process) 服务进程(Service Process) 后台进程(Background Process) 空进程(Empty Process) 前台进程 拥有 用户正在交互的 Activity(正处于 onResume中) 拥有 Service绑定到正处于 onResume的 Activity 拥有 Service 调用 startForeground 成为前台服务 拥有 Service 正在执行生命周期回调（onCreate、onStart

此文是从思维导图中导出稍作调整后生成的，思维脑图对代码浏览支持不是很好，为了更好阅读体验，文中涉及到的源码都是删除掉不必要的代码后的伪代码，如需获取更好阅读体验可下载脑图配合阅读： 此博文共分为四个部分： DAG定义 Job动态生成 数据的产生与导入 容错 在 Spark Streaming 程序的入口，我们都会定义一个 batchDuration，就是需要每隔多长时间就比照静态的 DStreamGraph 来动态生成一个 RDD DAG 实例。在 Spark Streaming 里，总体负责动态作业调度的具体类是 JobScheduler。 JobScheduler 有两个非常重要的成员：JobGenerator 和 ReceiverTracker。JobScheduler 将每个 batch 的 RDD DAG 具体生成工作委托给 JobGenerator，而将源头输入数据的记录工作委托给 ReceiverTracker。 1. 启动 1.1. JobScheduler job运行的总指挥是JobScheduler.start()， JobScheduler 有两个非常重要的成员：JobGenerator 和 ReceiverTracker。JobScheduler 将每个 batch 的 RDD DAG 具体生成工作委托给 JobGenerator

电量优化 Android应用开发中的网络、定位、传感器等都是比较耗电的特性，我们应该正确使用API来有效降低应用的耗电量。 1.BroadcastReceiver： 在代码实现中需要尽量避免无用操作代码的执行，减少应用损耗的电量。 对于BroadcastReceiver，通常的做法是在界面onPasuse之后取消广播监听器的监听操作，同时根据具体业务需求选择当应用位于后台时是否禁用广播接收器。 2.数据传输： 数据传输方式：蓝牙传输，Wi-Fi传输，移动网络传输等。 优化： 后台数据传输的管理：根据具体业务需求，严格限制应用位于后台时是否禁用某些数据传输，尽量能够避免无效的数据传输。 数据传输的频度问题：通过经验值或者数据统计的方法确定好数据传输的频度，避免冗余重复的数据传输，数据传输过程中要压缩数据大小，合并网络请求，避免轮询等。 3.位置服务： 三种位置服务： GPS定位:通过接收全球定位系统的卫星提供的经纬度坐标信息实现位置服务，精度是最高的，通常在10米以内，在时间和电量的消耗上也是最高的。 网络定位：通过移动通信的基站信号差异来计算出手机所在的位置，精度比GPS定位差很多，通常在几百米范围内。 被动定位：最省电的定位服务，如果应用使用被动定位服务，这个应用会等待手机中其他应用、服务或者系统组件发出定位请求，并和这些组件的监听器一起接收位置更新。 正确有限地使用位置服务器

本文主要分享Android应用耗电量的统计分析方法和工具。 众所周知，Android系统内置了应用的耗电量统计分析功能，但是并没有提供相应的API和文档，只是可以查看耗电量排行榜前10的应用的耗电百分比。此外，随着Android系统版本的迭代，各个版本耗电量统计的方式略有不同，但庆幸的是其统计模型并没有什么大变化。本文在前人的研究基础上总结Android平台的耗电量统计相关的计算方法和辅助工具。 (1)Android系统是如何进行应用的耗电量统计的？ 如果想了解Android系统是如何对应用进行耗电量统计计算的话建议先阅读： Android耗电统计算法 这篇文章， 作者是小米的MIUI系统工程师Gityuan(如果你想了解Android系统中常见模块的实现细节的话，非常推荐阅读这位开发者的博客，他的博客文章的质量都非常高) ，此文从Android 6.0系统源码的角度详细分析了应用的耗电量的计算方法。阅读上文可知，耗电量计算包括软件耗电量计算和硬件耗电量计算，并且有各自的计算方法。 下图是软件的耗电量统计项以及它的功耗计算公式： 下图是硬件的功耗计算公式： 其他文章推荐： 1. 深入浅出Android App耗电量统计 该文是耗电量统计方面最早的文章，分析的是Android 4.3系统源码中的应用耗电量统计 2. Android应用的耗电量统计 该文是在上面的文章2的基础上做的分析