我正在构建要在托管应用中使用的SDK。该SDK将集成到具有大量用户的应用程序中。
我们开始使用分层架构构建它 - UI，管理器与模型和网络层交互。总共三层。 UI正在通过回调获得更新。
旁注：我是团队中的一员，用很多用户构建了一些Android应用程序，在所有这些应用程序中我们使用了相同的分层架构。 这些应用程序拥有活跃的用户，直到现在还有很好的反馈。
我们有测试版，似乎一切都按预期工作。
一周前，我们的一名团队成员前来表示他认为我们需要改变 我们的架构以事件驱动为基础。我们将在SDK中具有处理所有侦听器的静态事件句柄，并且将从其他组件触发调度。
我认为这有点冒险，我认为在多线程环境中以这种方式处理具有大量依赖关系和服务的大型SDK会很困难。 另外，因为我们正在构建SDK，所以我们希望将我们的主类从主机应用程序中隔离出来，我认为这几乎是不可能的。
我的问题：
您认为正确的方法是什么，分层架构是好的，我们需要坚持下去，或者基于事件是首选的？
您是否认为它是适合SDK的合适解决方案，需要尽可能高效？
您认为这对多线程环境来说是一个很好的解决方案吗？
感谢任何反馈，谢谢。
我读过的一些文章：
architecting-android-the-clean-way
答案 0 :(得分：6)
Android本身基于基于事件的模型。 Android应用程序使用名为 looper 线程的特殊线程，一次从一个事件队列中选择事件，并通过执行其处理程序顺序处理它们。可能存在使用传统同步操作在彼此和looper线程之间通信的附加常规线程。 looper线程的主要作用是不断检查其事件队列，一次选择并处理一个事件。
据我所知，Android使用基于事件的模型的主要动机是它必须处理大量事件（触摸屏，点击，传感器，网络，内部和外部事件等）和基于事件的模型的选择是有道理的。
如果您的主要关注点是并发性和多任务处理，则事件驱动和被动模型恰好是多线程（或一般并发）的更好选择。但分层结构也不错，事实上我觉得它更好。
在一天结束时，这取决于工作的性质。如果你认为你的SDK证明了什么，类似于Android的工作（处理大型事件），那么去基于事件的模型，否则分层结构更好。
如果并发（多线程）是您的主要问题，并且您希望利用多核架构并且您的作业是CPU密集型的，那么您应该看到其他架构。
答案 1 :(得分：1)
在前一段时间performance tips for android我遇到了以下建议：
始终衡量
在开始优化之前，确保您遇到问题 需要解决。确保您可以准确地测量现有的 表现，或者你将无法衡量的好处 你尝试的替代方案。
简而言之
如果没有损坏，请不要修理