}

return;

}

if (listener == null) {

listener = new ShareListener() {

@Override

public void onCallback(int state, String msg) {

Log.i(“DEBUG”, “ShareListener is null”);

}

};

}

shareImpl(item, listener);

}

private void shareImpl (ShareItem item, ShareListener listener) {

if (item.type == TYPE_LINK) {

// 分享链接

if (!TextUtils.isEmpty(item.link) && !TextUtils.isEmpty(item.title)) {

doShareLink(item.link, item.title, item.content, listener);

} else {

listener.onCallback(ShareListener.STATE_FAIL, “分享信息不完整”);

}

} else if (item.type == TYPE_IMAGE) {

// 分享图片

if (!TextUtils.isEmpty(item.imagePath)) {

doShareImage(item.imagePath, listener);

} else {

listener.onCallback(ShareListener.STATE_FAIL, “分享信息不完整”);

}

} else if (item.type == TYPE_TEXT) {

// 分享文本

if (!TextUtils.isEmpty(item.content)) {

doShareText(item.content, listener);

} else {

listener.onCallback(ShareListener.STATE_FAIL, “分享信息不完整”);

}

} else if (item.type == TYPE_IMAGE_TEXT) {

// 分享图文

if (!TextUtils.isEmpty(item.imagePath) && !TextUtils.isEmpty(item.content)) {

doShareImageAndText(item.imagePath, item.content, listener);

} else {

listener.onCallback(ShareListener.STATE_FAIL, “分享信息不完整”);

}

} else {

listener.onCallback(ShareListener.STATE_FAIL, “不支持的分享类型”);

}

}

可以看到，上面的代码分为外部接口share和内部接口shareImpl，ShareItem和ShareListener的判断都放在share里完成，那么shareImpl就减少了if else的嵌套了，相当于把if else分摊了。这样一来，代码的可读性好很多，嵌套也不超过3层了。

但可以看到，shareImpl里还是包含分享类型的判断，也即业务判断，我们都清楚产品经理的脑洞有多大了，分享的类型随时会改变或添加。嗯说到这里相信大家都想到用多态了。多态不但能应付业务改变的情况，也可以用来减少if else的嵌套。

减少 if else 方法二：多态

利用多态，每种业务单独处理，在接口不再做任何业务判断。把ShareItem抽象出来，作为基础类，然后针对每种业务各自实现其子类：

public abstract class ShareItem {

int type;

public ShareItem(int type) {

this.type = type;

}

public abstract void doShare(ShareListener listener);

}

public class Link extends ShareItem {

String title;

String content;

String link;

public Link(String link, String title, String content) {

super(TYPE_LINK);

this.link = !TextUtils.isEmpty(link) ? link : “default”;

this.title = !TextUtils.isEmpty(title) ? title : “default”;

this.content = !TextUtils.isEmpty(content) ? content : “default”;

}

@Override

public void doShare(ShareListener listener) {

// do share

}

}

public class Image extends ShareItem {

String imagePath;

public Image(String imagePath) {

super(TYPE_IMAGE);

this.imagePath = !TextUtils.isEmpty(imagePath) ? imagePath : “default”;

}

@Override

public void doShare(ShareListener listener) {

// do share

}

}

public class Text extends ShareItem {

String content;

public Text(String content) {

super(TYPE_TEXT);

this.content = !TextUtils.isEmpty(content) ? content : “default”;

}

@Override

public void doShare(ShareListener listener) {

// do share

}

}

public class ImageText extends ShareItem {

String content;

String imagePath;

public ImageText(String imagePath, String content) {

super(TYPE_IMAGE_TEXT);

this.imagePath = !TextUtils.isEmpty(imagePath) ? imagePath : “default”;

this.content = !TextUtils.isEmpty(content) ? content : “default”;

}

@Override

public void doShare(ShareListener listener) {

// do share

}

}

（注意：上面每个子类的构造方法还对每个字段做了空值处理，为空的话，赋值default，这样如果用户传了空值，在调试就会发现问题。）

实现了多态后，分享接口的就简洁多了：

public void share(ShareItem item, ShareListener listener) {

if (item == null) {

if (listener != null) {

listener.onCallback(ShareListener.STATE_FAIL, “ShareItem 不能为 null”);

}

return;

}

if (listener == null) {

listener = new ShareListener() {

@Override

public void onCallback(int state, String msg) {

Log.i(“DEBUG”, “ShareListener is null”);

}

};

}

shareImpl(item, listener);

}

private void shareImpl (ShareItem item, ShareListener listener) {

item.doShare(listener);

}

嘻嘻，怎样，内部接口一个if else都没了，是不是很酷~ 如果这个分享功能是自己App里面的功能，不是第三方SDK，到这里已经没问题了。但如果是第三方分享SDK的功能的话，这样暴露给用户的类增加了很多（各ShareItem的子类，相当于把if else抛给用户了），用户的接入成本提高，违背了“迪米特原则”了。

处理这种情况也很简单，再次封装一层即可。把ShareItem的子类的访问权限降低，在暴露给用户的主类里定义几个方法，在内部帮助用户创建具体的分享类型，这样用户就无需知道具体的类了：

public ShareItem createLinkShareItem(String link, String title, String content) {

return new Link(link, title, content);

}

public ShareItem createImageShareItem(String ImagePath) {

return new Image(ImagePath);

}

public ShareItem createTextShareItem(String content) {

return new Text(content);

}

public ShareItem createImageTextShareItem(String ImagePath, String content) {

return new ImageText(ImagePath, content);

}

或者有人会说，这样用户也需额外了解多几个方法。我个人觉得让用户了解多几个方法好过了解多几个类，而已方法名一看就能知道意图，成本还是挺小，是可以接受的。

其实这种情况，更多人想到的是使用工厂模式。嗯，工厂模式能解决这个问题（其实也需要用户额外了解多几个type类型），但工厂模式难免又引入分支，我们可以用Map消除分支。

减少 if else 方法三：使用Map替代分支语句

把所有分享类型预先缓存在Map里，那么就可以直接get获取具体类型，消除分支：

private Map<Integer, Class<? extends ShareItem>> map = new HashMap<>();

private void init() {

map.put(TYPE_LINK, Link.class);

map.put(TYPE_IMAGE, Image.class);

map.put(TYPE_TEXT, Text.class);

map.put(TYPE_IMAGE_TEXT, ImageText.class);

}

public ShareItem createShareItem(int type) {

try {

Class<? extends ShareItem> shareItemClass = map.get(type);

return shareItemClass.newInstance();

} catch (Exception e) {

return new DefaultShareItem(); // 返回默认实现，不要返回null

}

}

这种方式跟上面分为几个方法的方式各有利弊，看大家取舍了~

写在最后

讲到这里大家有没收获呢？总结下减少if else的方法：

• 把接口分为外部和内部接口，所有空值判断放在外部接口完成；而内部接口传入的变量由外部接口保证不为空，从而减少空值判断。

• 利用多态，把业务判断消除，各子类分别关注自己的实现，并实现子类的创建方法，避免用户了解过多的类。

• 把分支状态信息预先缓存在Map里，直接get获取具体值，消除分支。

好了，到此就介绍完了，希望大家以后写代码能注意，有则避之，无则加勉。希望大家写的代码越来越简洁~

最后

如果你觉得文章写得不错就给个赞呗？如果你觉得那里值得改进的，请给我留言。一定会认真查询，修正不足。谢谢。

希望读到这的您能转发分享和关注一下我，以后还会更新技术干货，谢谢您的支持！

转发+点赞+关注，第一时间获取最新知识点

Android架构师之路很漫长，一起共勉吧！

更多Android知识点分享

---

架构师筑基必备技能

目前Android APP开发主流语言就是Java语言，Java语言最大的特性就是提高了软件的交互可能性，可以说安卓手机几乎所有应用程序都是利用Java语言来进行编写的。

知识要点：

1、深入理解Java泛型

2、注解深入浅出

3、并发编程

4、数据传输与序列化

5、Java虚拟机原理

6、高效IO

设计思想解读开源框架

随着互联网企业的不断发展，产品项目中的模块越来越多，用户体验要求也越来越高，想实现小步快跑、快速迭代的目的越来越难，插件化技术应用而生。如果没有插件化技术，美团、淘宝这些集成了大量“app”的应用，可能会有几个g那么大。

所以，当今的Android移动开发，不会热修复、插件化、组件化，80%以上的面试都过不了。

知识要点：

1、热修复设计

2、插件化框架设计

3、组件化框架设计

4、图片加载框架

5、网络访问框架设计

6、RXJava响应式编程框架设计

360°全方位性能调优

在不同层次的开发工程师手里，因为技术水平的参差不齐，即使很多手机在跑分软件性能非常高，打开应用依然存在卡顿现象。

另外，随着产品内容迭代，功能越来越复杂，UI页面也越来越丰富，也成为流畅运行的一种阻碍。综上所述，对APP进行性能优化已成为开发者该有的一种综合素质，也是开发者能够完成高质量应用程序作品的保证。

1、设计思想与代码质量优化

2、程序性能优化

• 启动速度与执行效率优化

• 布局检测与优化

• 内存优化

• 耗电优化

• 网络传输与数据储存优化

• APK大小优化

3、开发效率优化

• 分布式版本控制系统Git

• 自动化构建系统Gradle

4、项目实战

• 启动速度

• 流畅度

• 抖音在APK包大小资源优化的实践

• 优酷响应式布局技术全解析

• 网络优化

• 手机淘宝双十一性能优化项目揭秘

• 高德APP全链路源码依赖分析

• 彻底干掉OOM的实战经验分享

• 微信Android终端内存优化实践

• Android框架体系架构

Android框架体系架构（高级UI+FrameWork源码） 这块知识是现今使用者最多的，我们称之Android2013~2016年的技术。

Android开发者也往往因为网上Copy代码习惯了而导致对这块经常“使用”的代码熟悉而又陌生：熟悉的是几乎天天在和它们打交道， 天天在复制这些代码 ；陌生的是虽然天天和这些代码打交道，但是并没有深入研究过这些代码的原理，代码深处的内涵。

本篇知识要点：

1、高级UI晋升

2、Android内核组件
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

最后送福利了，现在关注我可以获取包含源码解析，自定义View，动画实现，架构分享等。
内容难度适中，篇幅精炼，每天只需花上十几分钟阅读即可。
大家可以跟我一起探讨，有flutter—底层开发—性能优化—移动架构—资深UI工程师 —NDK相关专业人员和视频教学资料，还有更多面试题等你来拿

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！

1712689700227)]

[外链图片转存中…(img-MbzbF90w-1712689700227)]

[外链图片转存中…(img-iKStZhBH-1712689700228)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

最后送福利了，现在关注我可以获取包含源码解析，自定义View，动画实现，架构分享等。
内容难度适中，篇幅精炼，每天只需花上十几分钟阅读即可。
大家可以跟我一起探讨，有flutter—底层开发—性能优化—移动架构—资深UI工程师 —NDK相关专业人员和视频教学资料，还有更多面试题等你来拿

[外链图片转存中…(img-LchPnGfI-1712689700228)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！