1

这是所有 Android 程序员的问题：

在我的应用程序中使用新旧 API 方法时，我发现了两种处理不同 API 方法的方法。

  1. 测试 SDK_INT，如

    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN) {
    holder.content.setBackground(background);
} else {
    holder.content.setBackgroundDrawable(background);
}

  2. 编写一个使用反射来测试方法存在的“Compat”类，如

    private static final Method sApplyMethod = findApplyMethod();

private static Method findApplyMethod() {
    try {
        Class<?> cls = SharedPreferences.Editor.class;
        return cls.getMethod("apply");
    } catch (NoSuchMethodException unused) {
        // fall through
    }
    return null;
}

public static void apply(final SharedPreferences.Editor editor) {
    if (sApplyMethod != null) {
        try {
            sApplyMethod.invoke(editor);
            return;
        } catch (InvocationTargetException unused) {
            // fall through
        } catch (IllegalAccessException unused) {
            // fall through
        }
    }
    editor.commit();
}

现在，后者取自 Carlos Sessa 的一本好书“50 Android hacks”。我被教导使用异常处理来进行流控制是一件坏事，而且不应该这样做。如果您可以针对某些东西进行测试，请不要故意遇到异常处理。因此，方法 2 不会被认为是“干净的”。

但是：在移动设备上，哪个是首选方法？从长远来看，哪个更快？

感谢您的所有意见！

4

1 回答 1

1

哪个是首选方法？

恕我直言，使用Build。

从长远来看，哪个更快？

Build.

更重要的是，Build它告诉您支持什么，因为您正在阅读 JavaDocs 并根据该文档确定是否要执行某些操作。

公共 Java 类上有很多公共方法，其中类在 Android SDK 中，但方法不在。@hide这些在 AOSP 源代码中被标记，并在创建android.jar我们链接到的、创建 JavaDocs 等时被剥离。这些代表在 Android 团队眼中“尚未准备好迎接黄金时间”的方法，但需要在框架内公开供内部使用。反射技术会很高兴地报告这些隐藏的方法可供使用，即使：

  • 由于 Android 团队更改或制造商更改，它们的方法签名可能与最终在 SDK 中发布的不同（参数、返回类型、异常）

  • 这些隐藏方法的行为未记录在案，因此可能与发布这些方法时记录的功能不匹配

我是@Macarse的忠实粉丝，但这是我们必须同意不同意的一种情况。

于 2013-07-03T13:58:34.740 回答