android方案,安卓方案定制开发

Android -- 保活方案

1、前台进程：当前运行的进程，除非APP的内存超过系统给定的最大内存，导致OOM才会被杀掉

创新互联专业为企业提供贺兰网站建设、贺兰做网站、贺兰网站设计、贺兰网站制作等企业网站建设、网页设计与制作、贺兰企业网站模板建站服务，十多年贺兰做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。

2、可见进程、服务进程：当前可见、运行的音乐这种

3、空进程：给新打开的APP使用，优先级最低

Service 的启动方式有两种，一种是startService(),一种是bindService().这两种方式有有什么区别.

startService()，启动完之后该service就在后台运行，其生命周期跟启动它的Context没有任何关系。也不能跟Context通讯。

bindService()启动之后生命周期跟启动它的Context有关，比如Activity、fragment、service等。在Context中解绑之后，如果改Service没有任何绑定后该Service也就结束。

Service 的生命周期跟启动方式有关。

stratService的生命周期： onCreate() - onStartCommand() - onDestroy()

bindService的生命周期: onCreate() - onBind() - onUnbind() - onDestroy()

1.PARTIAL_WAKE_LOCK：保证CPU保持高性能运行，而屏幕和键盘背光（也可能是触摸按键的背光）关闭。一般情况下都会使用这个WakeLock。

2.ACQUIRE_CAUSES_WAKEUP：这个WakeLock除了会使CPU高性能运行外还会导致屏幕亮起，即使屏幕原先处于关闭的状态下。

3.ON_AFTER_RELEASE：如果释放WakeLock的时候屏幕处于亮着的状态，则在释放WakeLock之后让屏幕再保持亮一小会。如果释放WakeLock的时候屏幕本身就没亮，则不会有动作。

1.PARTIAL_WAKE_LOCK：保证CPU保持高性能运行，而屏幕和键盘背光（也可能是触摸按键的背光）关闭。一般情况下都会使用这个WakeLock。

2.ACQUIRE_CAUSES_WAKEUP：这个WakeLock除了会使CPU高性能运行外还会导致屏幕亮起，即使屏幕原先处于关闭的状态下。

3.ON_AFTER_RELEASE：如果释放WakeLock的时候屏幕处于亮着的状态，则在释放WakeLock之后让屏幕再保持亮一小会。如果释放WakeLock的时候屏幕本身就没亮，则不会有动作。

对于 API level 18 ：调用startForeground(ID， new Notification())，发送空的Notification ，图标则不会显示。

对于 API level = 18：在需要提优先级的service A启动一个InnerService，两个服务同时startForeground，且绑定同样的 ID。Stop 掉InnerService ，这样通知栏图标即被移除。

该方案过于流氓，而且效果不好，所以不写。

JobSchedule 允许在特定状态与特定时间间隔周期执行任务。我们可以利用它的这个特点来完成保活功能，效果就像开启一个定时器，与普通定时器不同的是其调度由系统来完成。

在发送特定系统事件时，系统会发出广播，通过在AndroidManifest中静态注册对应的广播监听，即可在发送响应事件时拉活。

但是Android7.0开始，对广播进行了限制，而且在8.0更加严格。

Android8.0开始对广播有了限制：很多隐式广播接收器不能在清单中静态注册。但清单注册广播接收器仍是可以的（豁免广播或自定义广播-注意，自定义广播要显式发送）。实现隐式广播（系统广播）的接收也是可以的，但只能通过动态注册来实现了。

有多个app在用户设备上安装，只要开启其中一个， 就可以将其他的app也拉活。

具体实现：

一、系统同步机制拉活

总结 - Android UI适配方案

1、最原始的dp+自适应布局+weight，多套dimens.xml

缺点：只能满足90%以上的手机，同一像素的手机，dpi不一样

2、smallestWidth适配,res 文件夹下创建各种屏幕分辨率对应的 values-sw{xxx}dp 文件夹

缺点: 1、包会增加500kb左右

2、只支持3.2及以上的系统

3、AutoSize今日头条屏幕适配方案

当前设备屏幕总宽度（单位为像素）/ 设计图总宽度（单位为 dp) = density

原理：调用Android API，根据设备某一维度（宽或高）的真实长度（单位是px）与这一维度在UI设计图上的dp值之间的关系，重新计算density来实现

缺点: 第三方库适配

Android保活方案

系统出于性能和体验上的考虑，APP退到后台后并不会真正的kill、掉进程，而是将其缓存起来。

打开的应用越多，缓存的应用也就越多，在系统进程不足的情况下，系统根据自己的一套进程回收机制，来判断kill掉哪些进程，以腾出进程给需要的app，这套进程回收机制叫做low memory killer。

内存阀值，每个手机都不一样，当可用内存小于该值得时候，Android就会杀死对应优先级得进程。

进程的优先级通过oom_adj来判断，oom_adj取值如下：

0-3是比较安全的oom_adj一般不会被系统杀死的，所以我们只要保证自己的app oom_adj在0-3之间就可以了。

可以通过adb命令：cat /proc /4181/oom_adj来查看自己app的oom_adj的值

4181是进程号

原理：手机关闭屏幕的时候，偷偷创建一个activity，让应用成为前台进程，打开屏幕时关闭activity，这样用户就不会发现什么异常，我们知道前台应用的oom_adj为0是不会被杀死的，这样就达到看保活的目的。

缺点：activity不够干净，只有在息屏的时候才生效，存在局限性比较大，而且谷歌原生的系统息屏的时候不会清理进程，但是现在很多厂商会在息屏的时候清理内存，所以本方案的可行性不高，可以作为了解。

保活原理：启动一个前台服务，从而拉高整个应用的优先级。

因为一旦通知被用户干掉那么该保活方案就不好用了，所以通知图标存在与否是该方案是否可行的关键。

但是该方案是谷歌官方承认的保活方案，所以可行性还是很高的。

需要适配

API18通知图标不会显示

API=18API26可以启动双服务，绑定同样的D,然后stop

这个方法的原理是8.0系统之前会根据服务的id来判断通知，那么第二个id设置跟第一个相同，然后自杀，系统就会误认为此通知已死就不会通知了，那么通知栏上面就不会显示

API=26后暂时没有方式能够隐藏

8.0之后不可以创建同样的id的通知，所以此隐藏通知的方法就不好用了，当然了，通知显示与否不是该方案成功的评判标准，所以说还是可以用的。

在发生特定系统事件时,系统会发出广播,通过在 Androidmanifest中静

态注册对应的广播监听器,即可在发生响应事件时拉活

但是从 android7.0开始,对广播进行了限制,而且在8.0更加严格该方法就不适用了。

有多个app在用户设备上安装,只要开启其中一个就可以将其他的app也拉

活。比如手机里装了手Q、QQ空间、兴趣部落等等,那么打开任意一个app后,其

他的app也都会被唤醒

系统每隔一段时间会进行账户同步，当系统去账户同步的时候(不一定多长时间，跟系统有关)，我们就去拉活app，这个方案是非常稳定的，当然了国内的系统都是定制的，所以还是需要一定的适配的。

优点：系统唤醒，比较稳定

缺点：时间不能把控

JobScheduler允许在特定状态与特定时间间隔周期执行任务。可以利

用它的这个特点完成保活的功能，效果即开启一个定时器，与普通定时器不

同的是其调度由系统完成。

同样在某些ROM可能并不能达到需要的效果

android布局解决方案(汇总)

概述：记录一下常见布局的编写方式。

答：使用recyclerView的网格布局即可。

答：使用别人的开源组件。

应用场景，b站视频的标签，商品标签等等。

答：使用LinearLayout布局，设置weightSum属性，子view设置layout_weight属性。记住需要把设定的宽度或者高度设置0dp。

答：使用RelativeLayout布局，最后一个子View会显示在屏幕的最上方，不会被遮挡，常用来做activity标题头(titlebar)。

答：使用如下属性即可。

答：推荐使用NestedScrllView。

答：参考：

答：如下

在布局中添加如下属性

待补充。。。

Android后台进程保活方案

思想： 使用 Linux 中的 fork 机制创建 Native 进程，在 Native 进程中监控主进程的存活，当主进程挂掉后，在 Native 进程中立即对主进程进行拉活。

原理： 在 Android 中所有进程和系统组件的生命周期受 ActivityManagerService 的统一管理。Android5.0以下通过 Linux 的 fork 机制创建的进程为纯 Linux 进程，其生命周期不受 Android 的管理。

该方案主要适用于 Android5.0 以下版本手机。

该方案不受 forceclose 影响，被强制停止的应用依然可以被拉活，在 Android5.0 以下版本拉活效果非常好。

详情

对于 Android5.0 以上手机，系统虽然会将native进程内的所有进程都杀死，这里其实就是系统“依次”杀死进程时间与拉活逻辑执行时间赛跑的问题，如果可以跑的比系统逻辑快，依然可以有效拉起。在 某些 Android 5.0 以上机型有效。

详情

作者5.0以下系统用一个java进程和一个fork出来的纯native进程双管道互锁监听对方的状态，无论哪个被杀后都拉起第三个进程，第三个进程来拉活常驻进程，实现拉活。

5.0以上同一进程组的进程会被同时杀死，所以5.0以上使用双java进程在native层互锁文件实现监听，但任务管理器会在短时间内杀死所有进程，只能用反射提前初始化pacel，在进程被杀的时候和系统抢那几十毫秒的时间发送一个拉活的广播。用4个文件来让两个进程实现互锁来做监听，但实际效果很一般，测试了几个5.0以上的国产机型都不行，效果是根本监听不到进程被杀，目测原因是当任务管理器查杀进程的时候将所有的进程都挂起了，随后全部杀掉，并在一段时间内禁止进程启动。

PersistedJobService.java

BootReceiver.java静态注册BroadcastReceiver

注册，开机，网络切换、拍照、拍视频时候，利用系统产生的广播也能唤醒app，不过Android N已经将这三种广播取消了

常用的拉活权限

BackgroundService.java

WakeLock

作为前台应用运行，提高应用存活几率

service被关掉后自动启动

START_STICKY

如果系统在onStartCommand返回后被销毁，系统将会重新创建服务并依次调用onCreate和onStartCommand（注意：根据测试Android2.3.3以下版本只会调用onCreate根本不会调用onStartCommand，Android4.0可以办到），这种相当于服务又重新启动恢复到之前的状态了）。

START_NOT_STICKY

如果系统在onStartCommand返回后被销毁，如果返回该值，则在执行完onStartCommand方法后如果Service被杀掉系统将不会重启该服务。

START_REDELIVER_INTENT

START_STICKY的兼容版本，不同的是其不保证服务被杀后一定能重启。

service注册，权限设置为高优先级

KeepAliveService.java

注册，在新的独立进程内启动，适用5.0以下的原生系统，5.0以上同样会被杀死

他的局限性在于：

第一，用户会在系统设置的账户列表里面看到一个不认识的账户；

第二，同步的事件间隔是有限制的，最短1分钟，见源码，如果小雨60秒，置为60秒。而且各种国产机怎么改的源码我们未可知，是不是都能用仍然未可知；

第三，很致命，某些手机比如note3需要手动设置账户，你如何骗你的用户给你手动设置账户完了之后不卸载你；

第四，也很致命，必须联网！google提供这个组件是让你同步账户信息，不联网你同步个鬼，我们要保活，可以不联网不做事，但是不能不联网就死

集成三方推送平台sdk，友盟极光等