Question

Android的设计方式是，为了让方法能够读取资源，它必须能够访问Context。

由于我的应用程序中的大多数类依赖于字符串资源的灵活性（例如，更改语言而不必更改代码等），我的简单解决方案是在构造函数中传递Context，以便为每个类提供资源访问权限。这样的课程。

我只在构造函数中传递一个字符串是没有意义的，因为该类需要灵活地访问不同数量的字符串。

因此，为简化起见，我只传递Context，每当需要字符串资源时，我只使用Context.getString()。

这是不良设计的标志吗？

有没有更好的方法来实现这一目标？

Answer 1

这是Service locator pattern - 您传递服务定位器（通常称为“上下文”）并从中获取所需的依赖项。它不是一种反模式，并不是一个糟糕的设计，但通常dependency injection被认为是优越的。

您正在做的是 - 将服务定位器更进一步传递到对象图中。可取的是给每个类只提供它需要的依赖项。因此，不是在构造函数中传递Context，而是传递它需要的所有字符串。这样您就不会违反Law of Demeter

Answer 2

这是全球可访问的singleton类可能比将Context传递给每个类更好的极少数情况之一。

我会考虑创建一个用于本地化的单例，然后使用其中的Context（除非你需要Context的其他方面）。

当然，这是品味和偏好的问题。 YMMV

Answer 3

定期发送上下文作为参数并记住它们是危险的，请阅读：http://developer.android.com/resources/articles/avoiding-memory-leaks.html

更好的是继承Application并使用它生成单例（应用程序对象也是上下文）。这种溶剂没有明显的缺点。

Answer 4

我不知道以这种方式使用它是否是一个坏习惯，但是我进行了时间比较，将200个轻量对象加载到Array-list中，其中一个构造函数将Context作为参数，而另一个通过@Eric Farr建议的静态方法获取所需的上下文。最终结果是通过静态方法而不是传递给构造方法访问上下文始终快5-25％。

@Override
public void surfaceCreated(SurfaceHolder surfaceHolder) {
    initBlocks(map); // takes context through static method
    blocks.clear();
    initBlocks(getContext(), map); // pass context down to every block object
    mainthread = new GameThread(getHolder(), this);
    mainthread.setRunning(true);
    mainthread.start();
}


I/art: Background sticky concurrent mark sweep GC freed 1070(51KB) AllocSpace 
objects, 44(3MB) LOS objects, 27% free, 8MB/11MB, paused 27.450ms total 132.688ms
I/art: Background partial concurrent mark sweep GC freed 1638(66KB) AllocSpace 
objects, 36(3MB) LOS objects, 29% free, 9MB/13MB, paused 13.982ms total 184.900ms
I/art: Background sticky concurrent mark sweep GC freed 916(44KB) AllocSpace objects, 
37(3MB) LOS objects, 16% free, 11MB/13MB, paused 17.710ms total 127.963ms
**I/System.out: TIME IT TOOK TO PROCESS >> 2254155160**
I/art: Background partial concurrent mark sweep GC freed 1780(77KB) AllocSpace 
objects, 208(8MB) LOS objects, 38% free, 6MB/10MB, paused 22.850ms total 193.625ms
I/art: WaitForGcToComplete blocked for 5.262ms for cause Background
I/art: Background sticky concurrent mark sweep GC freed 959(46KB) AllocSpace objects, 
39(3MB) LOS objects, 24% free, 7MB/10MB, paused 15.160ms total 101.055ms
I/art: Background partial concurrent mark sweep GC freed 1873(71KB) AllocSpace 
objects, 32(2MB) LOS objects, 32% free, 8MB/12MB, paused 17.253ms total 154.302ms
I/art: Background sticky concurrent mark sweep GC freed 888(42KB) AllocSpace objects, 
36(3MB) LOS objects, 17% free, 10MB/12MB, paused 42.191ms total 179.613ms
I/art: Background partial concurrent mark sweep GC freed 1243(50KB) AllocSpace 
objects, 30(2MB) LOS objects, 27% free, 10MB/14MB, paused 29.423ms total 283.968ms
**I/System.out: TIME IT TOOK TO PROCESS >> 3079467060**
I/art: Background sticky concurrent mark sweep GC freed 343(16KB) AllocSpace objects, 
14(1232KB) LOS objects, 0% free, 21MB/21MB, paused 20.481ms total 162.576ms
I/art: Background partial concurrent mark sweep GC freed 396(13KB) AllocSpace 
objects, 4(280KB) LOS objects, 15% free, 21MB/25MB, paused 21.971ms total 243.764ms
I/art: Background sticky concurrent mark sweep GC freed 471(166KB) AllocSpace 
objects, 0(0B) LOS objects, 0% free, 37MB/37MB, paused 26.350ms total 133.655ms
I/art: Background partial concurrent mark sweep GC freed 356(10KB) AllocSpace 
objects, 1(10MB) LOS objects, 12% free, 27MB/31MB, paused 41.909ms total 299.517ms

我不认识你，但是我会提高表现（y）。

是否必须将Context传递给大多数类，这是一个糟糕设计的标志？

4 个答案: