在android的项目开发中,都会遇到后期功能拓展增强与主程序代码变更的现实矛盾,也就是程序的灵活度。 由于linux平台的安全机制,再加上dalvik的特殊机制,各种权限壁垒,使得开发一个灵活多变的程序,变得比较困难,不像pc平台下那么容易。
这里实际上可以借鉴传统软件中扩展程序的方法: 也就是插件的实现. 如目前所有的浏览器,比如我们使用的eclipse,以及很多优秀的软件,都使用了此种方式. 这样轻松实现了软件的功能扩展,而升级功能时只用更新对应插件, 而不是需要更新整个应用,降低了程序的耦合度.
而在android中的实现思路,即为将一个较大的apk,分离为一个主程序的apk,和其他各种较小的apk.
典型的应用为手机qq换肤的实现方式:
qq的皮肤是一个无界面apk应用,这个皮肤应用中的资源和主程序的资源命名一致,通过主程序和皮肤程序共享进程实现主程序对皮肤程序中资源的访问,在程序运行时通过代码显示指定皮肤资源,缺点是在主程序中每个activity要增加复杂的使用哪种皮肤逻辑
本例实现效果如下:
下面分析下具体思路:
android下,默认的情况是,每个apk相互独立的,基本上每个应用都是一个dalvik虚拟机,都有一个uid,再配合上linux本身的权限机制,使得apk互通很难直接进行。但作为一个独立应用的集成,不管多少个apk,都可以并为一个单独的dalvik虚拟机,直观的反映给开发人员就是在shell下列出进程,那几个apk同时加载后,会一个进程存在。
可以在清单文件中加入如下配置:
?
1 |
|
android:shareduserid是指共用一个uid,也就是,凡是这个属性相同的工程,都会共用同一个uid,这样,权限壁垒就消除了,dalvik也会融合为一个,可以测试一下,写几个工程,没有这个属性和有这个属性的情况下,同时运行,在列出当前进程,就直观的说明了。
下面还是用代码说明,一共分为两部分. 主程序 re_skin和皮肤程序re_skin1
首先是主应用程序代码:
1. 清单文件androidmanifest.xml:
?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
2. 布局文件:
?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
3. re_skinactivity;(主要的皮肤更换逻辑实现类)
?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 |
|
皮肤应用中不需要界面显示
这个皮肤应用中的资源和主程序的资源命名一致即可.
清单文件:
?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
本文链接:https://my.lmcjl.com/post/8016.html
4 评论