Android应用架构变更背后的经验、失误与推论应用架构变更背后的经验、失误与推论
摘要:Android的开发生态系统发展迅速,本文作者在开发Android应用超过三年的时间里,用来构建Android应用的架
构与技术一直在不断进化,具体阐述这些架构变更背后的经验、失误还有推论。
软件代码库各个不同的部分应当彼此独立,其整体却犹如一部运转良好的机器
Android的开发生态系统发展迅速,每周都有变化,人们不停地创建新工具、更新资源库、撰写博文、发表演讲。只要
享受一个月的假期,回来的时候支持库和/或Play Services都更新换代了。
笔者与ribot团队合作开发Android应用已有超过三年时间。在这段时间里,我们用来构建Android应用的架构与技术一
直在不断进化。在本文中,我们将具体阐述这些架构变更背后的经验、失误还有推论。
过去
早在2012年,我们的代码库总是采用基础架构,并未使用任何网络库,还是用老一套的AsyncTasks。下面的图表粗略
地演示了这个架构。
初始架构
代码共分两层:控制从REST API检索/保存数据的数据层(data layer),还有负责在UI上控制与展示数据的视图层
(view layer)。
APIProvider提供方法,让Activities和Fragments能够很容易地与REST API交互。运用URLConnection和AsyncTasks
来执行单独线程中的网络调用,并通过回调向Activities返回结果。
类似地,CacheProvider包含了从SharedPreferences或SQLite数据库检索存储数据的方式,通过回调将结果返回给
Activities。
问题
这个办法的主要问题在于,视图层责任过大。试想一个简单的通用场景:应用程序在加载文章列表时,将其缓存到
SQLite数据库中,并最终展示在ListView中。具体执行如下:
1. 调用APIProvider中的loadPosts(回调)方法;
2. 等待APIProvider成功回调,然后调用CacheProvider中的savePosts(回调);
3. 等待CacheProvider成功回调,然后在ListView中显示文章;