正文  基础知识 > 项目结构 >

Android 软件平台架构设计

试想你做的不是一个软件, 而是一个软件族, 这个些软件需要在Android平台发布, 你应该做何种规划? 这些问题需要在以下真实场景中考虑:QQ发布的特有手机, 需要继承多个软件: QQ空间、股票、聊天、游戏等一个......

试想你做的不是一个软件,  而是一个软件族, 这个些软件需要在Android平台发布, 你应该做何种规划?  这些问题需要在以下真实场景中考虑:

  • QQ发布的特有手机, 需要继承多个软件: QQ空间、股票、聊天、游戏等
  • 一个具有学习平台功能的手机, 需要多个软件: 电子词典、数学工具、学习进度安排、在线教学、绘图板、考试系统
  • 机械物联网应用, 需要多个服务: 电子商务、工况查询、专家系统、行业信息检索等

事实上, 随着客户端的独占性/垂直型需求的增加, 这类跟硬件绑定的诉求将日益增加, 因此软件的平台规划能力要求会逐步加强。 Android系统在设计之初也考虑到不同应用(进程)之间的通信, 为此实现了非常多的机制来解决进程通信的问题。这些正是本文需要探求的问题。

需要关注的典型问题包含:

  • 为了方便低耦合的管理, 要求一个应用能拆分成多个下级apk. 单个APK以足够自我管理.
    1. apk自我升级到能力, 不会对整体造成影响
    2. 应用能对下级APK进行权限控制(比如访问、卸载、剔除)
    3. apk与上级应用以及平级apk之间, 保持最大限度的低耦合
    4. apk保持良好的高内聚能力, 不会跟其它APK产生功能上的相似点

 

  • APK之间的能保持紧密的发生关系
    1. apk能保持调用
    2. apk能传递数据
    3. apk之间可共享库或者共享数据

 

曾经走过的弯路:

1.  软件分离带来的问题, 就是管理, 典型的问题就是插件过多的问题。 分离的代价, 需要在管理上下功夫。

2. 一些个人经验:

  • 严格命插件或者可分离软件的命名规范
  • 无需分开的插件/软件尽量合并, 避免后期软件带来的膨胀
  • 摒弃个人陋习, 自己曾经的想法是: 本项目的代码, 直接可以搬移到另外一个项目中运行, 甚至可以到达无需移植的效果, 其实这个想法是很脑残的。 允许一定范围内的修改和移植, 这已经是可重用插件不错的境界了。不要过于追求完美。