Android组件化设计开发模式

传统开发模式

• 创建android项目
• 划分功能包：工具、业务模块、UI、业务实现包。
• 在同一个项目里面，实现整个APP的架构。
• 以命名的方式区分业务

优点：业务层次清晰。并且业务之间调用方便。适用于中小型团队建设。
缺点：代码烦乱，维护性差。使用SVN，代表你的项目不是独立的，是共用体。
如果程序内部部分代码发生异常。将导致整个项目崩溃。并且开发人员的各司其责并没有到位（如遇负责该模块的员工离职）。导致维护性差。

不适用于整个大型团队或敏捷开发团队的开发。

传统更新模式

1. 初次进入程序更新方式。

2. 程序内部更新方式。

这种更新方式都是要：

1.  客户端发送版本一些信息请求服务端，返回是否要更新。如果要更新弹出对话框。

2. 更新完成后，都需要重装APP。这样一来，每更新一个业务功能，都要打包成一个APP。

缺点：版本更新频繁。用户体验差。

改进方式：默默在后台在后台替换现有版本。技术实现起来困难（静默安装的方式，需要ROOT权限）

用户体验要求

1. 安装该APP以后，无须更新，即可享受最新功能（如腾讯QQ、微信）

2. 下载的APP大小需要适中。最好是下载越快越好，越省流量。

3. 私人订制化的需求。

4. 用户对通知栏十分厌恶。尤其是安装多应用的手机用户。

如何达到用户体验

l 减少不必要的通知信息。

l 减少不必要的操作请求。判断是否是WIFI的情况下，如果是WIFI的情况下，则直接更新并下载。

l 版本更新时（强制更新），不做出让用户感觉该版本要更新的举动。从而让用户欣赏其它信息。

l （案例：QQ、微信。）更新时，给出一段视频、新闻信息、图片

HTML5

当下很多公司所采用的H5模式

优点:

1. 跨平台。

      APP出现新的功能时，无须更新APP，即可直接访问。

2. 实现简单。

      只需要会前端的网页的开发人员即可完成一个APP的开发。

3. 维护成本低。

      本地缓存H5界面，即可更新功能，更新界面，兼容性高，一套代码，运行多个平台。

缺点:

1. HTML5对于移动端本地化支持较弱。

2. 占用网络资源大。HTML5一些资源都在于服务端。导致访问速度延迟。

3. 原生的APP运行速度快。

基于组件模块化的开发方式

1. 每个组件包含了具体的主Activity。每个组件都是一个独立的运行模块。

2. 保障并行的开发。组件的独立，减少开发人员项目的协作和沟通。

3. 业务流程开发简单，分工明确。程序结构一目了然。易于各自的维护和测试。

4. 组件模式。使得开发人员的编程习惯不受约束。可以快速的开发以及扩展。

5. 即插即用。根据业务的需要，开发人员根据需求加入组件或者减少组件。也可以由用户自行安装。

 

实现方式

1. 宿主程序（即组件管理层）只是一个装载各个组件的壳子。

2. 宿主程序初始化以后，程序运行时第一个运行的是主应用组件的类。

3. 通过主应用组件的类，借助反射的方式去实现主应用组件调用其它业务组件。

4. 宿主程序完成对所有组件的初始化，以及组件的更新、安装与卸载。

5. 每个组件都是一个APK包。各自都能独立运行自己的业务。

6. 通过特定的规范，主应用组件的APK必须遵从宿主程序的约定（即宿主程序约定主应用组件的入口类为MainApplicationActivity）。

7. 每个组件都必须有一个ShareId，即组件的编号（android自带）。通过ShareId，可以实现宿主程序对组件的初始化以及检测。

8. 通过主应用组件，去整合各自独立的业务组件，从而启动一个应用程序。（类似总线的概念。）

实现方式流程

1、用户首次开启应用程序（Tinker+在线更新）

2、启动宿主服务

3、遍历组件目录，查找对应的组件信息

4、初始化所有组件信息

5、向服务端询问是否更新某些组件（）

6、更新组件信息

7、进入主应用组件（可以进行更新）

8、根据业务需求调用起相应的组件

组件装载执行方式

宿主后台服务（Service）检测：

1、检测组件版本。

2、装载新的组件。

3、移除旧的组件。

4、检测宿主程序是否要更新。（一般来说，宿主程序不更新。除非遇到重大情况。）

本片文档来自：最全的ADSL拨号服务器，www.117idc.com