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、检测宿主程序是否要更新。(一般来说,宿主程序不更新。除非遇到重大情况。)