公司产品最近提出恶劣的需求,让我们的app像微信一样永远不被杀掉,随时给用户最友好的体验,当时我想到的是根据手机壳变色的产品经理,心中翻滚着MMP,当然功能还是要做的;
1,除了微信这样的白名单大佬,没有app可以青春永驻
2,保活只能是使用一些歪门邪道来延长进程的持续时间
3,如果在原生的安卓系统去做,可能会好很多,但介于国内环境,只能尽力而为,有些机型可谓圣斗士一样
4,网上保活方案众多,不可能全部用上,分析使用
5,所谓保活是延长我们核心进程的寿命,比如推送,或者IM,推送其实各厂家做了很多的保活机制,多数为共享长链接,小米这种系统级别的不说,IM也一样,但我们其实也可以在他们的基础上想办法再做一层保活,像个推需要自己集成实现一个service.
研究一下市面上常见的保活方法
1,经典的一像素保活,据说QQ是这门干的(据说),很流氓,很有效,就是在锁屏和解锁的时候创建一个一个像素的Activity,这样做的目的是提升进程的优先级,不过有部分手机好像把解锁屏幕的广播给拿掉了
2,双进程守护,开俩个进程相互唤起,因为系统的进程回收机制是一个个回收的,利用这个时间差来相互唤起,当一个进程被磨灭掉,另一个马上重启,缺点是现在大部分机型只要一键清理就玩完了,不过也没有更好的办法,而且8.0之后对这个做了限制,想要在一个后再服务中启动另一个服务会报错,可以用startForegroundService方法,但是会有一个通知在通知栏,这就有点不太友好了,不过介于8.0以下手机还有很多,可以考虑
3,native进程(已报废)
4,JobIntentService,这个好多人不知道,其实就是之前JobService,利用系统的调度去开启一个服务,不过这个很简单,比JobService的使用简单多了,这个东西会在解锁屏幕,充电啊这一些动作的时候去重启执行里面的job,甚至手机重启,所以用它来总一些事情再核实不过了,不过它也是会被杀死的.
5,利用账号同步机制拉活,不过貌似被改了,失效了
6,在后台播放一个无声的音频,看起来很不错,不过总感觉该方案有点….
7,将service设置为前台进程,通2方法一样,会强制有个通知,可以考虑用innerService发送俩个id一样的通知,然后结束掉一个(8.0之后无效),该方法很好
一,先创建一个OnePixelService来监听屏幕的广播,之后就假设这个OnePixelService是我们的核心进程,我们就保活它
public class OnePixelService extends Service implements ScreenStateListener {
private ScreenBroadcastReceiver screenBroadcastReceiver;
@Nullable
@Override
public IBinder onBind(Intent intent) {
return null;
}
@Override
public void onCreate() {
super.onCreate();
screenBroadcastReceiver = new ScreenBroadcastReceiver(this);
//动态注册广播
IntentFilter filter = new IntentFilter();
filter.addAction(Intent.ACTION_SCREEN_OFF);
filter.addAction(Intent.ACTION_SCREEN_ON);
if (getApplication() == null) return;
getApplication().registerReceiver(screenBroadcastReceiver, filter);
}
@Override
public void onDestroy() {
super.onDestroy();
getApplication().unregisterReceiver(screenBroadcastReceiver);
}
/**
* 屏幕打开
*/
@Override
public void onScreenOn() {
//屏幕关闭之后->启动一个activity一个像素的留在界面上
if (getApplication() == null) return;
WeakReference<Activity> mActivityWref = OnePixelLive.getmActivityWref();
if (mActivityWref != null) {
Activity activity = mActivityWref.get();
if (activity != null) {
activity.finish();
}
}
}
/**
* 屏幕关闭
*/
@Override
public void onScreenOff() {
//屏幕关闭之后->启动一个activity一个像素的留在界面上
//当app在后台,或者按下home键之后,创建一个activity会慢,可能会在再次解锁之后创建
if (getApplication() == null) return;
//boolean runBackground = BackFogetUtil.isRunBackground(getApplicationContext());
getApplication().startActivity(new Intent(getApplication(), OnePixelActvity.class));
}
}
然后创建一像素Activity
public class OnePixelActvity extends Activity {
public static final String TAG = OnePixelActvity.class.getSimpleName();
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
Log.e(TAG, "onCreate");
Window window = getWindow();
//放在左上角
window.setGravity(Gravity.START | Gravity.TOP);
WindowManager.LayoutParams attributes = window.getAttributes();
//宽高设计为1个像素
attributes.width = 1;
attributes.height = 1;
//起始坐标
attributes.x = 0;
attributes.y = 0;
window.setAttributes(attributes);
boolean screenon = BackFogetUtil.isScreenon(this);
if (screenon) {
finish();
} else {
OnePixelLive.setActivity(this);
}
}
@Override
protected void onDestroy() {
super.onDestroy();
Log.e(TAG, "onDestroy");
}
这里启动activity通过Application启动,所以即使你按了back键回退到后台还是会启动这个一像素的,但是又个问题就是现在安卓对这种情况启动界面会有个五秒的延迟限制,然后就会出现刚锁屏有解锁的情况下,activity被创建,然后没有解锁广播了,无法销毁了,卡住了的现象,所以我做了一个判断如果屏幕真亮着的时候创建activity,那么马上把他销毁掉;
然后很重要的一个地方
1,启动模式要设置成singleInstance,不然会有问题,当你的app在后台的时候,你解锁屏幕,创建销毁OnePixelActvity的同时会把整个栈的activity弹出来,然会用户就会莫名其妙的看到你的app自己打开了;
2,一定要把主题设置为透明,不然在你操作飞速的时候,屏幕总是会闪过一抹五彩斑斓的黑;
<activity
android:name=".preserving.ui.OnePixelActvity"
android:launchMode="singleInstance"
android:theme="@android:style/Theme.Translucent.NoTitleBar" />
然后效果实现了
08-18 22:27:55.304 10201-10201/com.lxf.processpreserving E/live: ScreenBroadcastReceiver --> ACTION_SCREEN_OFF
08-18 22:27:55.319 10201-10201/com.lxf.processpreserving E/OnePixelActvity: onCreate
08-18 22:27:56.282 10201-10201/com.lxf.processpreserving E/live: ScreenBroadcastReceiver --> ACTION_SCREEN_ON
08-18 22:27:56.285 10201-10201/com.lxf.processpreserving E/OnePixelActvity: onDestroy
一像素这个锁屏问题实现了,但是没锁屏的情况下被干掉怎们办,想到可以开启一个进程用jobservice来进行拉活,因为他是一个足够强大的机制,开一个定时任务去检测OnePixelActvity的存活状态来进行拉活,虽然它也会挂掉,但它会在各种情况下重启,而且锁屏状态下不会被强制杀掉;但是又一个问题,8.0以上不能后台拉起服务,8.0下可以直接启动服务;怎们解决,这里我用了一种比较恶心的做法,就像上面一像素玩法一样,当我们要拉起这个服务的时候,启动一个一像素的activity,然后再启动服务,然后销毁activity;这个很好使,完美拉起,但是呢用户有时候会莫名其妙的感觉到屏幕一卡,我们也成功的甩锅到手机商和其他应用;不过稳妥的办法还是在屏幕锁屏的状态下进行拉活,不然会出问题的;
public class LiveJobService extends JobIntentService {
public static String serviceName = "CLASSNAME";
private String liveService;
private Timer timer = new Timer();
private long count;
private TimerTask timerTask = new TimerTask() {
@Override
public void run() {
count++;
if (TextUtils.isEmpty(liveService)) return;
boolean serviceWork = BackFogetUtil.isServiceWork(getApplicationContext(), liveService);
if (!serviceWork) {
Log.e("LiveJobService", "服务" + liveService + "被干掉了" + count);
count = 0;
try {
Class<Service> serviceClass = (Class<Service>) Class.forName(liveService);
//尝试拉起该服务
if (Build.VERSION.SDK_INT >= 26) {
getApplication().startActivity(new Intent(getApplication(), JobActvity.class));
} else {
startService(new Intent(getApplicationContext(), serviceClass));
}
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
} else {
Log.e("LiveJobService", "服务" + liveService + "正在运行" + count);
}
}
};
@Override
public void onDestroy() {
super.onDestroy();
Log.e("LiveJobService", "进程被杀掉了");
}
@Override
protected void onHandleWork(@NonNull Intent intent) {
liveService = intent.getStringExtra(serviceName);
//LiveJobService使用的是队列的数据结构
//我们搞一个定时任务来拉活传过来的服务
if (timer != null && timerTask != null) {
timer.schedule(timerTask, 1000, 1000);
}
}
}
其实jobservice也就是为了锁屏的情况下去拉活,因为锁屏之后它不会被干掉,这个样子就有多了一份生存的希望,但是还不够;如果服务挂掉了,用户也一直没有锁屏怎们办?不考虑通知栏的情况下通过aidl双进程拉活可以很好的起到作用,但鉴于8.0通知栏这个问题暂时不考虑守护的做法,同时将服务设为前台的做法也就不考虑,当然也可以判断系统8.0以下去加上这个做法;
目前没有发现8.0以上不显示通知栏又能拉活的办法,所以只判断8.0以下开启一个进程去守护,8.0等用户锁屏之后器拉活(当然也可以流氓点)
总结感觉可行的做法:
1,假入我们要保活一个HttpService
2,HttpService中加入一像素的保活代码
3,8.0以下将HttpService设置为前台进程(基本就不会被杀了)
4,开启一个jobService去定时拉活HttpService,8.0启动一像素activity去启动进程(时机自己决定)
5,jobService也有几率被杀,可以考虑在8.0以下开启进程守护互相拉活
6,不要花太多时间去挑战rom系统的意见清理,目前发现只有部分手机可能清理不赶紧,大部分手机手机清理非常彻底
7,8.0以上真心不太好搞,貌似9.0更加不好弄,加入了服务分组,电量优化等一系列内容
8,白名单最可靠
9,优化产品最实在
