我在应用程序中使用Pushwoosh来接收推送通知。我使用的是Pushwoosh库3.1.14的最新版本。
我有一个这样的屏幕结构。
Login Activity -> Main Activity with multiple tabs.
因此,我正在MainActivity中实现我的pushwoosh相关逻辑。我想注销推送注销,然后返回登录活动。
我的代码如下。我已经过滤掉了所有其他与Pushwoosh无关的部分。坦率地说,此代码与Pushwoosh文档中的代码完全相似。唯一的区别是在onLogout()方法中,我尝试从pushwoosh注销并返回LoginActivity。
TabbarActivity.java
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
//Pushwoosh Registration
registerReceivers();
PushManager pushManager = PushManager.getInstance(this);
pushManager.setNotificationFactory(new PushNotificationFactory());
try {
pushManager.onStartup(this);
} catch(Exception e) {}
//Register for push!
pushManager.registerForPushNotifications();
checkMessage(getIntent());
}
@Override
protected void onNewIntent(Intent intent) {
super.onNewIntent(intent);
setIntent(intent);
checkMessage(intent);
}
@Override
protected void onResume() {
super.onResume();
registerReceivers();
}
@Override
protected void onPause() {
super.onPause();
unregisterReceivers();
}
BroadcastReceiver mBroadcastReceiver = new BaseRegistrationReceiver() {
@Override
public void onRegisterActionReceive(Context context, Intent intent) {
checkMessage(intent);
}
};
private BroadcastReceiver mReceiver = new BasePushMessageReceiver() {
@Override protected void onMessageReceive(Intent intent) {
//JSON_DATA_KEY contains JSON payload of push notification.
}
};
public void registerReceivers() {
IntentFilter intentFilter = new IntentFilter(
getPackageName() + ".action.PUSH_MESSAGE_RECEIVE");
registerReceiver(mReceiver, intentFilter,
getPackageName() +".permission.C2D_MESSAGE", null);
registerReceiver(mBroadcastReceiver, new IntentFilter(
getPackageName() + "." + PushManager.REGISTER_BROAD_CAST_ACTION));
}
public void unregisterReceivers() {
try {
unregisterReceiver(mReceiver);
} catch (Exception e) {
e.printStackTrace();
}
try {
unregisterReceiver(mBroadcastReceiver);
} catch (Exception e) {
e.printStackTrace();
}
}
private void checkMessage(Intent intent) {
if (null != intent) {
if (intent.hasExtra(PushManager.REGISTER_EVENT)) {
uploadPushTokenToServer(PushManager.getPushToken(this));
}
resetIntentValues();
}
}
private void resetIntentValues() {
Intent mainAppIntent = getIntent();
if (mainAppIntent.hasExtra(PushManager.PUSH_RECEIVE_EVENT)) {
mainAppIntent.removeExtra(PushManager.PUSH_RECEIVE_EVENT);
} else if (mainAppIntent.hasExtra(PushManager.REGISTER_EVENT)) {
mainAppIntent.removeExtra(PushManager.REGISTER_EVENT);
} else if (mainAppIntent.hasExtra(PushManager.UNREGISTER_EVENT)) {
mainAppIntent.removeExtra(PushManager.UNREGISTER_EVENT);
} else if (mainAppIntent.hasExtra(PushManager.REGISTER_ERROR_EVENT)) {
mainAppIntent.removeExtra(PushManager.REGISTER_ERROR_EVENT);
} else if (mainAppIntent.hasExtra(PushManager.UNREGISTER_ERROR_EVENT)) {
mainAppIntent.removeExtra(PushManager.UNREGISTER_ERROR_EVENT);
}
setIntent(mainAppIntent);
}
//Finally on logout
private void onLogout() {
//other cleanup
//pushwoosh
PushManager.getInstance(this).unregisterForPushNotifications();
//goback to login activity
}
我收到了来自服务器的推送,没有任何问题。我面临的唯一问题是,在我注销并返回LoginActivity后,TabbarActivity保留在内存中,而内存又保留了许多其他片段和视图。我试着使用MAT进行调试,结果就是这样。
Class Name | Ref. Objects | Shallow Heap | Ref. Shallow Heap | Retained Heap
--------------------------------------------------------------------------------------------------------------------------------------------------
com.pushwoosh.internal.request.RequestManager$1 @ 0x12f89ce0 Thread-1737 Thread| 1 | 88 | 360 | 536
'- val$context in.myproject.activities.TabbarActivity @ 0x12d8ac40 | 1 | 360 | 360 | 18,520
--------------------------------------------------------------------------------------------------------------------------------------------------
我还与LeakCanary工具进行了交叉检查,这也表明Pushwoosh正在坚持我的活动。
所以我的问题是,我该如何清理pushwoosh以避免我的活动被泄露?
您所引用的文档,通过简单的查看,给出了一个示例,这些示例并不总是将api实现为具有其他活动的全功能应用程序的最佳方式。我理解通过使用getInstance,您试图使用singleton,但怀疑这没有得到很好的管理。
我将控制在您的应用程序期间使用的PushManager实例。
问题可能是PushManager的多个实例是从作用域创建的,也可能是在类中创建多个PushManager实例,可能是在程序的生命周期内。这将导致泄漏。
我会将pushManager作为一个类变量,而不是两次使用pushManager.getInstance,并考虑创建一个pushManager的静态实例,以便在应用程序期间使用,就像在整个应用程序中使用单个数据库实例一样。
在阶级层面上:
PushManager pushManager;
并在oncreate 中初始化
pushManager = PushManager.getInstance(this);
//Finally on logout
private void onLogout() {
//other cleanup
//pushwoosh
// Here the first instance is left dangling.
// PushManager.getInstance(this).unregisterForPushNotifications();
pushManager..unregisterForPushNotifications();
//goback to login activity
}
通过这种方式,您已经为pushmanager的一个实例清理了资源。
要使用应用程序范围的静态PushManager:
static PushManager pushManager;
初始化为:
pushManager = new PushManager(this.getApplicationContext());
什么时候单身汉不是单身汉?
@CommonsWare的评论很到位。查看Pushwoosh SDK的(反编译的)源代码,PushManager.onStartUp()
将提供的上下文直接转发到其RequestManager
,后者将其移交给基本上无限运行的Thread
。这意味着它将在您的活动实例失效后很长一段时间内挂起。
请注意,这正是MAT试图告诉你的(可能还有LeakCanary)。
换句话说,在应用程序的整个生命周期内,无论您传递到onStartUp()
中的内容,都将在内部保留一个强引用。因此,请确保您提供的上下文具有适当范围的生命周期。换句话说:这里只有正确的选项是应用程序上下文。
你可能想向Pushwoosh提交一份错误报告,并通知他们问题是:
public void onStartup(Context context) throws Exception {
Context applicationContext = context.getApplicationContext();
this.pushRegistrar.checkDevice(applicationContext);
sendAppOpen(context); // <--- ISSUE
...
}
我只能猜测有人在办公室度过了糟糕的一天,忘记把有问题的线路改成sendAppOpen(applicationContext)
。
没有人承诺在这一变化之后,所有的泄漏都将成为历史(我没有深入挖掘来源),但它至少应该解决眼前的问题。
此外,这一点再强调也不为过,一般来说,如果您不知道(或控制)组件的使用寿命,请使用应用程序上下文。如果一个活动真的需要,方法签名会/应该表明这一点。如果它只是询问上下文,请谨慎行事。(是的,当然,这条经验法则也有很多例外,但通常情况下,追踪由此产生的问题比追踪内存泄漏的问题更容易)。
我收到Pushwoosh的回复,说他们已经解决了这个问题。我下载了他们最新的SDK,瞧,漏洞消失了。用户@MH似乎对罪魁祸首代码一针见血。
这是来自新SDK的反编译源代码,
public void onStartup(Context context) throws Exception {
Context applicationContext = context.getApplicationContext();
this.pushRegistrar.checkDevice(applicationContext);
sendAppOpen(applicationContext); // <--- NO ISSUE
...
}