具有共享代码库的多个应用程序

Question

由于在同一应用程序的Android市场中同时拥有免费和付费版本，所以我决定也这样做。起初，我只是复制了完整的代码库，并在一些地方修改了一些代码（添加了广告，内置了一些限制等），因为当时没有选择做图书馆项目的选择，但是这给我带来了两个管理修复非常可怕的项目因为我需要做两次这些bug。

既然r14我们可以使用库项目的资源，所以这将是一个很好的解决方案，这个特殊的问题，据我所知。因此，我已阅读library projects和conciderations，并且我很想知道不同版本的项目中所需的最小文件数量是多少。因此我的问题是;

• 我可以拥有共享项目中的所有代码，并且基本上只有一个清单就拥有裸骨项目吗？
  • 如果是这样，我应该吗？这是从概念上的最佳方式吗？ （所以除了这个事实，这取决于我的代码库）
• 我应该如何处理库包命名，是否有特定的规则？
• 是否有工具可以比较来自两个不同项目的代码，并且可能会自动进行魔法或自动手动合并，以及哪一个更受欢迎？

Answer 1

1. 是的，你可以有一个项目，基本上是一个清单指定应用程序的名称，命名空间，图标等等，所有的实际代码和库项目资源的99％。

2. 是的，我认为你应该使用这种方法。使用库项目处理免费/付费应用程序问题非常常见。

3. 我对命名没有任何问题，尽管您应该小心使用单独项目中的任何资源以避免使用相同的名称。

4. 我不知道有任何工具，如果是我，我想手动做，以确保我合并什么需要合并，并保持需要分开的东西。你有一个重要的重构要做，但一旦所有的重复被删除，我相信它会容易得多。

Answer 2

如果我正确理解你的问题，你想创建多个Android应用程序是彼此相似（即，有很多相同的源代码），但它是在特定的（未成年人）的方式不同，并希望这些应用中的每一个都有独特的软件包，以便可以将其分别上传并分发到应用商店，例如Google Play。项目库是实现这些目标的绝佳工具。

我假设各种版本之间的差异较小，涉及资源和应用程序名称和软件包等内容，以及为付费版本启用某些功能而将它们关闭以免费版本的开关。

即使情况并非如此，通过以下述方式使用多态性，您的各种应用程序可能会有很大的不同，并且仍共享一个通用的项目库。

在Eclipse中可以像定义任何Android项目一样定义项目库，但它被标记为项目库（通过检查Android页面底部附近的“Is Library”框库的“项目属性”对话框），无法编译并自行运行。相反，它旨在通过引用包含在一个或多个其他真实应用程序项目中（通过在每个此类应用程序的“项目属性”对话框的Android页面上添加对其的引用）。这些应用程序将使用项目库，因此将共享其代码和功能。

每个这样的引用应用程序都会有自己的清单文件（可以声明它们各自不同的包），还可以定义它们自己的类（包括从项目库的Activity和/或Application类派生的类），使得这些类可以多态的使用项目库（每个应用程序进行专门例如，通过重写方法或通过提供定义为被定义为项目库的活动 - 中抽象或应用程序派生类）的方法，虽然你也可以使用这些库类，而不会改变（只要它们不是抽象的），通过简单地引用它们的清单文件中（例如，在活动或应用标签）使用函数库的每个应用程序的，就像你引用的活动或应用程序在应用程序本身中定义的类派生类。

如果你决定使用这种方法，那么你会放一个项目库的主源文件，并会为您创建要产生每个应用，每个将引用项目库单独的项目。项目库的清单文件将通过使用图书馆（实际上，我认为项目库本身的表现完全被忽略，不只是覆盖正在创建的任何项目的清单被覆盖，但仍然是创建清单有用对于库，以便您可以手动模板 - 复制和编辑 - 从库自己的清单中使用它的每个项目的清单）。

我已经用这种方法来创建共享一些相同的能力的多个Android应用，并且它一直对我非常好。

关于包命名，所有旧的包名会为库项目工作，但当然是有道理的，你用你的各种个人（例如，自由与使用相同的前缀库项目的包付费）使用它的应用程序，诸如“.library”作为名称的最后部分，而各种应用程序可能具有诸如“.myappfree”和“.myapppaid”之类的结尾。自然地，您会希望对库的包装前缀使用反向域名约定来防止冲突，就像您对待发布应用程序的包名称一样。

在Windows中，用于比较的代码库一个很好的开源工具的WinMerge：

http://winmerge.org/

如果我处在你的位置，但是，我只会用这个工具来手动识别的差异，并且不会尝试使用它来自动将代码重构为库项目。这最好在你自己的（手动）控制下完成。最后，作为一种替代方案，您可以考虑使用一个免费的应用程序，该应用程序默认具有免费应用程序的功能，并且可以选择通过输入法升级到完整应用程序的功能（在相同的APK中提供）应用程序支付，而不是分开的免费和付费应用程序。在过去的几个月中，应用内支付有了很大的改进（随着IAB第3版的发布），尽管仍然存在一些小问题，但它们已经成为免费/完全二分法更实用的替代方案第一。