【问题标题】:AOSP Stubs vs getSystemServiceAOSP 存根与 getSystemService
【发布时间】:2013-10-11 18:34:00
【问题描述】:

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

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

这是完成的,而不是使用 mContext 请求它们,如下所示:

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

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

应用程序不能使用存根方法自然有安全原因,但它们使用存根方法进行系统服务肯定有一些原因。

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

【问题讨论】:

    标签: android android-source


    【解决方案1】:

    因此,在深入了解 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);
                    }});
    

    看起来很眼熟?但是当您取回系统服务时,服务获取器将执行一些其他开销,例如缓存您的服务,以便您可以在后续调用中更快地取回它。 (那里有更多开销,我没有详细研究,但我认为是为了优化)

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

    如果你是系统应用,通过存根获取服务可能会更快。

    【讨论】:

      猜你喜欢
      • 2020-08-11
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多