android设计方案
1. IOS与Android的UI设配方案
IOS与Android共用一套设计效果图 1242*2208
IOS与 Android常用的尺寸中,最大尺寸为6p的尺寸,即1242*2208px
IOS常用尺寸: 1242*2208 750*1334 640*1136 640*960,其中750*1334 640*1136 640*960 同为@2x 1242*2208为@3x,所以750*1334 640*1136 640*960只做一套640*1136就好。
Android 常用尺寸:1080*1920 720*1080 480*800,他们之间相邻是可以整除1.5的,也就是1080除以1.5等于720,720除以1.5等于480,即这三个尺寸可以等比缩放大小,只做一套1080*1920就可以。
那么问题来了。
IOS要做两套尺寸,1242*2208与640*1136
Android要做一套尺寸,1080*1920
这样不就是三套设计图了吗?设计师们会被气死的?
其实,6p的尺寸1242*2208整除1.15就刚好就等于1080*1920,也就是说,1242*2208与1080*1920是可以等比缩放的。
现在就剩下IOS的640*1136。
那么就有人问,那IOS的1242*2208可以直接等比缩放成640*1136。答案是不可以的,因为他们之间不能整除的,但是我们把1242*2208的设计图直接在Photoshop里面直接等不缩放到宽度为640的尺寸,我们会发现原本的2208变成了1138,也就是说比1136多了2个像素,2个像素的误差对于没有有强迫证的也就无所谓了,2个像素的误差我们会将1138硬改成1136,现在你会发现,里面的图标,1136跟1138大小其实是一样。
为什么提到图标呢?因为我们交付的物只需要一套效果图与五套切图就好了。即
一套效果图 1242*2208
五套切图 1242*2208 640*1136 1080*1920 720*1080 480*800
最后注意缩放的图标要细调一下,由于转换有误差,共用一套效果图是有一定风险的,例如UI细节上的风险。开发前,设计师与开发人员要先共同确认此适配方案,要全程沟通,及时改正UI方面的问题。
IOS与Android共用一套设计效果图 750*1334
上面提到过,750*1334 640*1136 640*960 同为@2x,所以750跟640用同一套图标,同一套字体,至于其他尺寸大小,只要跟着尺寸延伸就没问题啦。尺寸750*1334应用1242*2208,则需要把@2x导出成@3x,也就是把字体放大1.5倍,其余的直接放到1242就可以啦。
至于Android版本,我个人的做法是把750*1334直接换算成1080*1920,因为只有1PX像素只差,直接忽略。换算出1080*1920,Android的其他尺寸就按他们之间的规律处理就可以啦。
因为我们交付的物只需要一套效果图与五套切图就好了。即
一套效果图 750*1334
五套切图 1242*2208 640*1136 1080*1920 720*1080 480*800
IOS与Android各做两套设计效果图
原理跟方案一、二差不多,但为了追求细节上的完美,可以多做一套设计图,即两套设计图:1242*2208和640*1136.
1242*2208适配6P、Android三种尺寸。
1242*2208整除1.5等于1080*1920:
1080*1920整除1.5等于720*1280:
720*1280整除1.5等于480*800:
640*1136适配6 5 5S等尺寸。
如果追求完美,那就需要三套图。即:
1242*2208 640*1136 1080*1920
还可以加上一套640*960,总之分开做越多套,出来的效果图就会越精细,反之,你懂得,不过这也取决设计师本人和公司领导的决策,会不会给那么多时间。不说废话了,希望能帮到各位!
2. android界面设计有什么好的方案
多看android官方规范,灵活使用8dp(一般间距)与48dp(一般可触摸区域)。
灵活使用点九切图。图标与按钮分开切,字全让研发自己输入。千万不要切死图。
早期的时候跟研发约好时间。比如某个半天,你弄个笔记本,跟研发坐一起,严格的把你的规范执行下去,后期大家合作起来就方便了。
图一定要像素级别(包括720的图标),所有锚点都优化好。
还是研发吧,没事多往那边跑,带点干果花生什么的一边吃一边改。他是怎么实现的,你一定要问清楚,你想怎么实现,你也得跟他讲清楚。
仍然还是研发,他们不怕麻烦,只是怕做好后又改。所以不要老让他们尝试,自己多做效果图,严谨一点,多用axure把效果图转手机里看看。
做一个UI套件(dribbble上搜索UI kit看下别人怎么做的),后期你也会方便很多,重要的是交接工作会很好。
多看知乎,有些关于ps的技巧,作图技巧还蛮实用的。
3. 安卓APP的主要开发原理以及其主要过程是什么
开发原理:
Android应用程序是用Java语言编写的。编译过后的字节码,以及应用程序要求的其他数据和资源文件,通过aapt工具被绑定在一起,称为 Android包,这是一个带.apk后缀的档案文件。这个文件也是用户下载到他们设备上的文件。所有的代码在一个单一的.apk文件中,组成一个“应用程序”。
主要过程:
1、需求分析:
大部分创业型项目在这个阶段只是一些比较抽象的想法。有一份相对完善的需求文档,不仅有助于创业者自身对项目的理解和周全性分析,如果项目是交由设计公司去完成的话,也更有利于对方准确把握项目的定位和商业模式,以便给出专业的建议和解决方案。
2、原型设计
接下来会根据上面提到的具体需求文档,项目经理进行会进行原型图的设计。
3、UI设计
原型图经过反复推敲修正后,UI 设计师会进行UI界面相关的配色设计、功能具象化处理、交互设计、以及各种机型、系统的适配。UI 设计师经过多次与项目经理沟通修改后,最终的到定稿的高保真设计图。
4、开发
经过以上几个过程之后,会正式进入到开发阶段。
5、测试调试
APP 功能开发完成之后,测试人员会对整项目进行系统性测试。这个环节会调动起项目组内所有人相关人员。而测试这个环节的重要性不亚于前期功能的规划,如果团队没有经过专业系统性训练的测试人员,很可能会导致项目出现与设计初衷存在落差,以及遗漏下一些逻辑上的坑。
6、发布app
经过至少两轮的内部测试以及小范围外测(或者完成满足测试要求的周期)后,会进行最终版本的上架。
(3)android设计方案扩展阅读
APP开发工具
1、MOTODEV Studio for Android
MOTODEV Studio for Android,这是基于Android的开发环境,为开发者们提供新的MOTODEV App Accelerator Program使他们可以开发出更适合摩托罗拉Android手机的应用程序。
2、J2ME开发插件 Mobile Tools for Java
Mobile Tools for Java (MTJ) 是Nokia公司开发的一款 Eclipse插件,用于支持 Java 手机应用程序开发。其前身就是大名鼎鼎的 EclipseME。
3、apk文件修改工具 Root Tools
RootTools是一个新的工具软件,Android开发者可以在这一工具软件的支持下,对.apk格式的文件进行再次修改,让程序表现更加出色,满足用户的需求。Root Tools里面自带有很多工具,比如BusyBox,它里面集成压缩了很多Linux的工具和命令,这样软件开发者在对....
4、IDEA的Android开发插件 idea-android
idea-android 是在 IDEA 集成开发环境中开发 Android 应用程序的插件。
参考资料
网络-app开发
4. 如何制作一个安卓版的APP软件方案
一、打开速度快
开发者的任何一行代码都可能延迟应用的响应时间,对于这方面的解决方案的话,就是代码的优化方面了, 比如说内存优化、UI的优化、加载图片时的优化等都是项目成功的关键,在很多公司开发的产品中,一大部分的应用基本上都是用算法来进行优化的,这也就是很多开发者,无论是对于哪个领域哪个行业 来说,只要你算法学的精通,那么也就不愁你的项目性能上的问题了,一款成功的应用=好的创意+好的设计+高质量代码,虽说的比较笼统,但这几环也是环环相扣的。
二、用户体验好
开发一款安卓APP应用软件的最终目的就是为了迎合大众的胃口从而赢得用户的亲睐,所以用户体验是必不可少的功能。如果你下载了一款应用,花费了很长一段时间在程序的启动上,你会等待吗?或者说这款手机安卓APP客户端应用软件在真正运行的时候,突然卡死了,然而再也无法启动了,你还会选择继续使用吗,然而换做用户的角度思考遇到这种类似的问题,一般都会选择卸载,所以用户体验的质量决定了这块APP的成败。失去了用户,开发的APP也就失去了价值!
三、关注可用性和响应性能
响应性能,这也是影响手机安卓app的一个重要的因素,对每个开发APP的开发商来说,都不希望APP开发出来后,会因为响应性能受到影响,解决这个问题的唯一办法就是在开发APP的过程中开发技术人员要做好基础性的工作,不断的对项目进行优化。让项目做的更为精致。其实我们的每一次努力和优化都是在逐步的完善和改进APP的不足,不要在你还不容易成功的开发出了一款安卓APP手机客户端,然后却输在了APP的运行上,那样就太不划算了。
因此在开发手机APP安卓版客户端时,我们会遇到的问题还有很多基于条件有限,不能跟您一一讲述,但是以上的三点因素绝对是决定您的APP能够开发成功的关键,所以广大开发商应该尤为重视。
5. Android设备的界面适配设计
Android设备App设计中有一个问题可能会被设计师忽略,在各种分辨率各种尺寸“杂屏”的界面适配。可能产出的界面稿在常用的720*1280的分辨率中是完美,但一到各个不同分辨率不同尺寸的设备后
这里就谈谈适配,了解适配让设计从PS、sketch到移动设备上都能完美呈现。
如此繁杂的安卓设备,采用哪个标准设计呢?
1.选择一种尺寸一种分辨率作为基准。
2.选择2-3款主流的Android设备,制定一套适配规则。(国内主流设备、分辨率可参考友盟指数)
3.部分极端效果特别注释说明。
目前移动端设计师多采用iPhone 5与6的分辨率设计,这两个分辨率也最接近Android xhdpi的720*1280,设计之后再做等比适配(不做设计元素等比适配会导致Android设备上视觉呈现较小)。
我则倾向于选取720*1280的分辨率设计。优点是处于常用分辨率的中间值,对小分辨率大分辨率调整也较容易。另外iOS@1x的320与720刚好是2.25的倍率关系,使用sketch等比输出快捷多了。(如果时间成本允许的话可以将Android的标注单位用dp,具体的设备尺寸、分辨率知识这里不详描述,可见文章最后面的“Android基础知识”)
案例说明:
雅虎新闻为各个dpi做了优化,图片等比缩放,文字区域等比缩放,并且考虑到在低dpi下会被推移至第二屏,就减小图片了高度,保持文字区域最小高度。
老司机都不会忘记的,仅提醒下新手,每个图标记得输出多个比例。并且记得查看各个比例下图标的显示效果。
案例说明:
还是拿一个雅虎新闻的例子,大家感受下。
Android设备的系统各个厂商都做了定制化,默认的字体库可能不同,且字体占空间大小可能不同。不同设备显示文字会出现不同效果。设计时考虑3点:
多采用流式布局,不对单行做字数限制(如“单行显示多少个字”“文本宽度多少”),而是定义文本容器的高宽,超出则用“…”“渐隐”或者“遮挡”等方式省略。
若较长的文本需要完整显示,设计时预留换行空间。
若文本需要在单行完整显示(如提示类文字),尽量控制字数(建议16字内),避免小屏不够放置。
案例说明:
图文混排同一行显示时,图片等比固定在右侧显示,文字部分区域宽度会因设备不同出现较大的差异,预留文字多行高度。如下图不同设备下文字的展示空间有差异,需要考虑小分辨率下预留多行文字空间。如图2第二条新闻标题文字溢出的丑陋展示,建议设定一个文字区域最大高度,超出部分则隐藏。
单行出现多个文字符素时,注意元素在低dpi下的显示层级,提前说明好该情况的覆盖或者隐藏规则。如下图第一个用户名称,在低dpi下,避免各元素交错,而省略了超出的用户名称。
图片常用的方式有固定宽度dp等比缩放高度(用于非通栏图片);固定高度dp等比缩放宽度(用于横向滚动图片,如全屏相册中的纵向图片);根据屏幕宽度等比缩放(横向通栏图片)。设计时考虑3点:
注意图片占用的宽高比,避免大屏设备上占据大量空间,导致内容比例不协调同时降低了屏幕利用率。
考虑到设备屏幕密度不同,输出图片时别忘了输出多个分辨率。
考虑图片宽高比过大的缩略图处理(最常见的处理方式:高度远大于宽度时,是给出最大区域,让图片等宽居中填充该区域,只显示该区域;宽度远大于高度时,与展示区域等高居中取部分显示。当然也可能出现特殊显示要求,需要根据具体情况具体处理。)
案例说明:
网易游戏相册的全屏浏览中,大于设备宽高比的宽图按照最大宽度放置,小于设备宽高比的高度按照最大高度放置。
一行多张图片要考虑图片的在不同设备下等比缩放带来显示效果的差异。排列时会有两种情况:
1.要求在一行内显示完,根据图片的显示效果决定放置的数量,超过则不显示(如下图1第二条新闻)
2.流式布局,当图片宽度小于设定值时自动换行(如下图2相册展示,低dpi低分辨率设备一行显示3张,高的显示4-5张,且按比例撑满屏幕宽度)。
宽高比超出设计区域时的处理,如网络贴吧中列表的小图模式,给出了正方形区域,当图片非正方形时,根据宽高中的短边等比撑满正方形区域后,截取了图片居中的部分显示。
在固定区域内多元素混合放置时,文字一般采取流式布局,图片多采用等比缩放,图标元素多采用 弹性布局,即元素内容本身规格不变,考虑水平、垂直方向的间距做相应扩展。设备屏幕越大,在扩展方向上可以显示更多内容,发挥了大屏幕的优势。
弹性布局需要给出哪一个元素dp不变,哪一个元素缩放的策略。
弹性布局下部分距离标注采用百分比标注。
当有两个等比缩放元素时考虑避免重叠的情况。
案例说明:
网易游戏的新闻列表样式,每一条新闻区域,要求图片dp不变,而文字区域进行弹性缩放。
下图网易游戏专区中间的幽灵按钮图标为确保点按效果,按照固定dp显示,中间间隔的宽度按照设备宽度的百分比来确定
网易游戏求交往的界面,中间卡片区域大小根据设备等比缩放,如中间用户头像与“同喜欢2款游戏”的文字,在设计时需要考虑产品的目标设备中最小设备下的布局显示效果,避免出现重叠的情况。而纵向的元素数量也需要如此考虑。
Android界面适配的案例说明就写到这里啦。
设计时多考虑各个元素(图标、文本、图片、区域)在不同设备的情况。当然,做设计时也不是死板的按照建议来实现,特别是固定区域下的元素放置,根据实际情况来处理即可。
Android系统的UI也在不断进化完善,随着设计趋势的改变,Android除了常见的卡片、列表、浮层外,可能会有更多的展示方式,而Android设备也是逐渐淘汰ldpi与mdpi,设备的分辨率逐渐变大。也就要求我们需要不断的去了解尝试新的设计趋势,产出最好的方案。
这不是彩蛋哈,仅仅补充安卓设备的基础知识,老司机完全可以忽略,供新手参考阅读。
为展示设备的多样化,贴出Android屏幕尺寸示意图(蓝色矩形的大小代表不同尺寸,颜色深浅则代表所占百分比的大小。)
屏幕大小以屏幕尺寸来衡量,指屏幕的对角线的长度,单位是英寸,1英寸=2.54厘米
目前的主流尺寸:5.0" ~ 5.5" (有继续往更大尺寸发展的趋势,但趋于稳定)
常见的设备尺寸: 4" ~ 10" 。
手机适配参考尺寸: 4" ~ 6"
手机 + 平板适配参考尺寸: 4" ~ 10”
屏幕分辨率是指在横纵向上的像素点数,单位是px,1px=1个像素点。一般以纵向像素*横向像素,如1960*1080。
屏幕像素密度是指每英寸上的像素点数,单位是dpi,即“dot per inch”的缩写。目前每个屏幕像素可以认为就是一个“点”。
屏幕 dpi 的计算方式:
Android 设备中 dpi 分几个段:
•ldpi:~ 120 dpi (几乎绝迹)
•mdpi:~ 160 dpi (罕见)
•hdpi:~ 240 dpi (逐渐减少中)
•xhdpi:~ 320 dpi
•xxhdpi:~ 480 dpi
•xxxhdpi:~ 640dpi (目前较少)
dp(与 dip 同义) 是在 160dpi 下每个像素对应的物理尺寸,可近似理解为:
•160 dp = 1 inch
•1 dp = 1 / 160 inch = 0.15875 mm
•1 dp = 1 px (160 dpi 屏幕下)
•1 dp = 2 px (320 dpi 屏幕下)
Android的屏幕适配指标都基于物理尺寸(即屏幕的物理大小),而非像素(分辨率)。为什么呢?这里根据dp与px适配出两种效果来说明。
按 dp 适配不同屏幕的效果如下,内容的物理尺寸变化不大:
若直接按照像素适配,出现以下情况,高像素密度的设备内容显得特别小,影响布局与可用性:
屏幕长边和短边的比例。
目前手持设备的 长边 dpi 和 短边 dpi 普遍非常接近,可认为屏幕比例和屏幕水平、垂直像素比例一致
屏幕比例目前趋于 16:9 ~ 16:10 (8:5)
因不少设备使用了虚拟按键,所以通常非全屏的 app 可用面积略低,屏幕比例更接近 16:10
6. android开发框架有哪些
主要总结了7个好用的android 开发框架推荐给你:
一、 Afinal
Afinal是一个Android的ioc,orm框架,内置了四大模块功能:,FinalBitmap,FinalDb,FinalHttp。通过,我们可以通过注解的方式进行绑定ui和事件。通过finalBitmap,我们可以方便的加载bitmap图片,而无需考虑oom等问题。通过finalDB模块,我们一行代码就可以对android的sqlite数据库进行增删改查。通过FinalHttp模块,我们可以以ajax形式请求http数据。
功能:
一个android的ioc,orm框架,内置了四大模块功能:,FinalBitmap,FinalDb,FinalHttp。通过,我们可以通过注解的方式进行绑定ui和事件。通过finalBitmap,我们可以方便的加载bitmap图片,而无需考虑oom等问题。通过finalDB模块,我们一行代码就可以对android的sqlite数据库进行增删改查。通过FinalHttp模块,我们可迟戚以以ajax形式请求http数据。
优点:功能比较全面,文档完善,代码效率比较高。
缺点:没有项目demo,框架的时间比较久,代码冗余比较多(这也是无可避免的),文档比较老跟不上代码更新进度。
二、 xUtils
xUtils:可以说是Afinal的升级版。
xUtils 包含了简旦陪很多实用的android工具。
xUtils 支持大文件上传,更全面的http请求协议支持(10种谓词),拥有更加灵活的ORM,更多的事件注解支持且不受混淆影响...
xUitls 最低兼容android 2.2 (api level 8)
三、
是一个免费的开源的、简易的、遵循Apache2开源协议发布的Android开发框架,其开发宗旨是简单、快速的进行Android应用程序的开发,包含Android
mvc、简易sqlite orm、ioc模块、封装Android
httpclitent的http模块,具有快速构建文件缓存功能,无需考虑缓存文件的格式,都可以非常轻松的实现缓存,它还基于文件缓存模块实现了图片缓存功能,在android中加载的图片的时候,对oom的问题,和对加载图片错位的问题都轻易解决。他还包括了一个手机开发中经常应用的实用工具类,如日志管理,配置文件管理,android下载器模块,网络切换检测等等工具
四、 LoonAndroid
如果你想看ui方面的东西,这里没有,想要看牛逼的效果这里也没有。这只是纯实现功能的框架,它的目标是节省代码量,降低耦合,让代码层次看起来更清晰。整个框架一部分是网上的,一部分是我改的,为了适应我的编码习惯,还有一部分像orm完全是网上的组件。在此感谢那些朋友们。
整个框架式的初衷是为了偷懒,之前都是一个功能一个jar,做项目的时候拉进去,这样对于我来说依然还是比较麻烦。最后就导致我把所有的jar做成了一个工具集合包。
有很多框架都含有这个工具集合里的功能,这些不一定都好用,因为这是根据我个人使用喜欢来实现的,如果你们有自己的想法,可以自己把架包解压了以后,源码拉出来改动下。
目前很多框架都用到了注解,除了没有入侵我们应用的代码以外,其他的基本上都有,要么是必须继承框架里面的activity,要么是必须在activity的oncreat里面调用某个方法。
整个框架式不同于,Roboguice等ioc框架,这是一个类似spring的实现方式。在整应用的生命周期中找到切入点,然后对activity的生命周期进行拦截,然后插入自己的功能。
五、
又叫KJLibrary,是一个android的orm 和 ioc
框架。同时封装了android中的Bitmap与Http操作的框架,使其更加简单易用;
的设计思想是通过封装Android原生SDK中复杂的复杂操作而达到简化Android应用级开发,最终实现快速而又安全的开发APP。我们提倡用最少的代码,完成最多的操作,用最高的效率,完成最复杂的功能。
功能:
一个android的orm 和 ioc 框架。同时封装了android中的Bitmap与Http操作的框架,使其更加简单易用;
开发框架的设计思想是通过封拦蠢装Android原生SDK中复杂的复杂操作而达到简化Android应用级开发,最终实现快速而又安全的开发APP。总共分为五大模块:UILibrary,HttpLibrary,DBLibrary。
六、 dhroid
dhroid 是基于android 平台,
极速开发框架,其核心设计目标是开发迅速、代码量少、学习简单、功能强大、轻量级、易扩展.使你更快,更好的开发商业级别应用
功能:
1.Ioc容器: (用过spring的都知道)视图注入,对象注入,接口注入,解决类依赖关系
2.Eventbus: android平台事件总线框架,独创延时事件,事件管理轻松
3.Dhnet: 网络http请求的解决方案,使用简单,减少代码,自带多种网络访问缓存策略
4.adapter模块: 数据绑定轻松,不用写多余的adapter,天生网络支持(一行代码搞定加载,刷新问题)
5.DhDb: android中sqlite的最轻量orm框架(增删改查轻松搞定)
6.Perference: android自带Perference 升级版,让你的Perference更强大,更方便
工具集合 JSONUtil(安全处理json),ViewUtil(数据绑定更快) (异步任务工具)...
七、
SmartAndroid是一套给
Android开发者使用的应用程序开发框架和工具包。它提供一套丰富的标准库以及简单的接口和逻辑结构,其目的是使开发人员更快速地进行项目开发。使用
SmartAndroid可以减少代码的编写量,并将你的精力投入到项目的创造性开发上。
功能:
SmartAndroid 拥有全范围的类库,可以完成大多数通常需要的APP开发任务,包括:异步网络操作相关所有功能、强大的图片处理操作、轻量级ORM数据库Sqlite库、zip操作、动画特效、Html等解析采集、事件总线EventBus/Otto、Gson(Json)、AQuery、主流所有UI控件(例如:ActionbarSherlock,SlidingMenu,BottomView,Actionbar,DragListView等10多种UI库)等。
7. Android模块化设计方案之使用代理模式解耦
Android模块化设计方案系列文章:
1、 Android模块化设计方案模型图
2、 Android模块化设计方案之接口API化
3、 Android模块化设计方案之使用代理模式解耦
本篇是Android模块化设计方案的第三篇,也是对 第一篇 中ThridLibs Proxy模块进行说明。
很多人觉得对那些优秀的第三方依赖库再次封装是一件多余的事情,因为这些库可能出自大神/大厂,或有非常高的star并且使用起来十分稳定,可以在项目中直接拿来使用。当然每个开发者都有自己的态度,我也只是根据以往的经验,表达一下自己的看法。
作为从了解四大组件就不愁找不到工作的互联网大时代中一路走来的Android老鸟,经历了网路请求框架从HttpConnection到Volley再到OkHttp,也经历了图片加载框架从UniversalImageLoader到Picasso再到Gilde,技术的迭代随时都会发生。让项目架构具有良好的扩展性是在设计之初就需要考虑的东西。
那么接下来我用一个简单的demo来演示一下如何使用代理模式对第三方框架进行解耦。
现在我们有一个名为 thirdlib 的模块,为我们提供图片加载功能。
第一步:我们创建了一个新的模块 thridlibproxy ,并且该模块依赖于 thirdlib ,我们在该模块中创建包私有的接口ImageLoaderInterface,这个接口中把thirdlib模块中提供的功能抽象为接口:
第二步:创建包私有的接口的实现类ImageLoaderOneImpl,类中图片加载的业务逻辑是通过调用 thirdlib 中的ImageLoader类实现的:
第三步:我们提供一个供外部调用的ImageLoaderOneImpl接口代理类ImageLoaderProxy:
最后我们就可以通过ImageLoaderProxy中提供的loadImage方法进行图片的加载了。
看到这里有些盆友就会问了,在第二步的时候,我们就完成了 thirdlib 的封装工作,为什么还要有第三步?还有我写一个单例类直接对 thirdlib 进行封装不就行了,为什么还要抽象出接口?
原因很简单,为的就是尽可能的满足软件设计七大原则中的第一个: 开闭原则 。
一个好的软件设计,需要对拓展开放,对修改关闭。我们在设计之初就要想到,在更换图片加载框架之后如何最大程度上满足开闭原则。
如果直接对 thirdlib 进行封装,是面向类的开发而不是面向接口。如果此时更换图片加载类库,那必然会对封装出来的类进行大量的修改,把原来的实现替换为新的实现。
使用代理模式的好处就是,我新创建一个被代理的类ImageLoaderTwoImpl:
然后只需要对第三步中的被代理类进行替换就行了。
在想要达到相同效果的时候,最大程度的满足了开闭原则。
我们业务层模块也和第三方库实现了完全的解耦,我不需要知道 thridlibproxy 是如何帮我完成图片加载工作的,但是只要调用它提供的方法就完事儿的,这也符合软件设计七大原则中的: 最少知道原则 。
关于为何以及怎么通过代理调用第三方依赖库,到这里就介绍完毕了,赶快动手试试吧~
我只想说: 原则是死的,人是活的😹
如果觉得有收获的话,欢迎点赞评论以及关注~