gpt4 book ai didi

android - AOSP stub 与 getSystemService

转载 作者:行者123 更新时间:2023-11-29 01:49:16 25 4
gpt4 key购买 nike

我一直在研究 AOSP,我注意到了一些关于系统服务的东西。他们中的很多人喜欢像这样直接访问系统服务 stub :

IDevicePolicyManager dpm = IDevicePolicyManager.Stub.asInterface(
ServiceManager.getService(Context.DEVICE_POLICY_SERVICE));

这是完成的,而不是像这样使用 mContext 请求它们:

DevicePolicyManager dpm = (DevicePolicyManager)  
context.getSystemService(Context.DEVICE_POLICY_SERVICE);

起初我认为这可能是因为没有可用的上下文,但有。一个很好的例子是 deletePackageX 方法,它是 PackageManagerService 类的一部分。您可以将 stub 方法更改为 getSystemService 方法,并且一切仍然SEEMS 正常工作。

应用程序不能使用 stub 方法自然有安全原因,但系统服务使用 stub 方法肯定有一些原因。

所以问题是,为什么他们在上下文中使用 stub 来获取其他系统服务?

最佳答案

因此,在深入了解 ContextImpl.java 以查看 getSystemService 调用的作用后,它实际上只是 Stub.asInterface 调用的包装器,您经常在系统服务中看到它。因此,当您创建系统服务并希望将其公开给 SDK 时,您需要将其注册到上下文中,以便非系统应用程序能够获取它的句柄。大多数服务的注册看起来像这样:

registerService(ALARM_SERVICE, new ServiceFetcher() {
public Object createService(ContextImpl ctx) {
IBinder b = ServiceManager.getService(ALARM_SERVICE);
IAlarmManager service = IAlarmManager.Stub.asInterface(b);
return new AlarmManager(service, ctx);
}});

是不是很眼熟?但是当你取回系统服务时,服务 getter 会做一些其他的开销,比如缓存你的服务,这样你就可以在后续调用中更快地取回它。 (那里有更多的开销,我没有详细研究,但我认为是为了优化)

所以基本上,通过 stub 直接获取服务可以节省开销并比通过上下文更快地执行操作。上下文只是为了让非系统应用程序可以访问您的服务,并且您希望通过 SDK 公开它。但最终,相同的代码最终会被执行。

如果您是系统应用程序,通过 stub 获取服务可能会更快。

关于android - AOSP stub 与 getSystemService,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19325010/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com