Android面试一天一题（Day 31：Android技术难题解决方案）

最近在看一些认知、脑科学和学习相关的书籍，看似和面试不相关，其实一想关系非常大。面试，特别是软件开发的面试，其实最重要的是区分出面试者的认知能力，而且最好能判断对方是否具备理工科（较理性客观）的思维能力。

所以我也多次提过，除了太基础的题目（原则）之外，面试者答错题并不算是严重的问题，严重的是面试者思路让别人难以理解，或者说面试者没有很好的表达能力让别人更容易理解他的思路。工作过几年的人都有感受吧：“不怕神一样的对手，就怕猪一样的队友”，这个“猪一样”大多数时候都是用来描述思维奇葩的同事吧。

那么，在Android开发中，如何结合技术点和思维认知方面一起考查呢？请看今天的主题。

面试题：你在Android开发中遇到的技术难题是什么，你是怎么解决的？

一个工作过几年的程序员肯定会有工作中遇到技术难点问题，虽然这个问题有可能对于别人不是技术难点，但只要对于当时的你是技术难点，只要让你抓耳挠腮毫无头绪就往往会在你的大脑中留下深刻的印象。

这个问题，我也比较难教大家怎么回答，我只能给大家做一个示范，如果问到我，我怎么回答。

因为我这两年主要的工作是给一家公司做Android插件框架的开发，所以我的第一反应就是刚做插件时遇到的茫然无助。先给大家说一下插件是什么以及为什么要做插件，估计面试官不太了解的话，也会这样问你的。

如上图所示，随着应用的业务和功能代码的无节操增大，技术上代码方法数到达了一个DEX文件（那时Google还没有推出MultiDex）的上限（65536），业务上太多的模块和业务逻辑混在一个应用中，部署和升级都遇到很麻烦的问题，不能快速响应业务的发展。

基于这些痛点，我们想到了“动态插件”方面，把各个业务模块独立出来成为一个个可以动态加载、独立升级的插件，而原来的应用做为一个平台承载这些插件。思路是很不错的，可是当时（2014年底）关于Android插件的资源和开源项目都很有限，并没有那么多现成的开源框架让我们借鉴。如果你现在做插件你的烦恼是选择的开源框架太多了，不知道该选那个，正如我在一篇文章所写的那样：

2015年Android的插件开发热情空前高涨，开源的插件框架也如雨后春笋，初步了解对比了一下各个开源框架，感觉各有千秋。因为面对不同的业务需求，所以在针对性和实现方式上都略有不同。

在没有开源框架的时候，世界很安静，大家只能低头研究android机制和framework的代码自己闭门造车，一直怨恨无人同行且不能踩在前辈的肩膀向上。而今面对扑面而来的开源插件时，大家又陷入选择的泥潭而不能自拔，这真是幸福的烦恼。每个插件框架都各有各的优缺点，当你花时间去熟悉对比完各个插件框架后，你也不一定能百分百确定某某框架一定适合你用。你终于在绕了一圈后又回到起点，是自己写一个框架呢还是用开源框架呢？因为你始终不能确认开源的框架是否能经得起实际项目的检测，害怕还有N多不知道的坑在等着你。

不过问题总是要解决的，我的解决方案如下：

• 当时有一家叫ApkPlug的小公司做出了一套插件框架，我打电话和他联系看能否交流（回答当然是买产品可以，技术就免了），如果对方能提供优质的服务是可以考虑花钱使用他们的框架。
• 试用ApkPlug的产品把它能做到的功能点记录下来，对比一下是否完全符合我们的业务需求。这一步至少给我一个意识：“只要ApkPlug能实现的就证明技术上是行得通的”， 对于还在起步阶段的我们信心很重要。
• 收集其他相关的信息以评估自己实现插件框架的可行性，如Apache flex的OSGI模块化开发框架也进入我们的尝试提案。

最终我们决定自己来实现插件框架，当时遇到过很多技术“难点”，如“如何实现在插件中不改变开发者的习惯正常调用startActivity”，“自定义View的在插件Activity切换时的类加载有问题”，“插件升级时so不能正常加载的问题”等等。问题很多，解决这些问题，基本上都是靠先理一遍正常的一个APK应用在Android系统上是个怎么样的流程，详细的查看Framework层代码的调用过程，最后找到问题的解决点。

小结

其实很多人的问题在于“他没有问题”！很多工作了多年的程序员，你问他有什么印象深刻的问题困扰过自己吗？没有！有在参与过的项目中有提供什么非常关键的解决方案吗？没有！有发现过测试没测出来但很严重的问题吗？没有！

太多的“没有”了，这样的人不在少数，包括工作很多年的资深程序员。那么真的是我们没有遇到过问题吗？答案显然不是，问题是我们遇到问题时没有对问题进行过深入的思考，没有把它记录或者当成案例分享给别人，渐渐地你自然会遗忘它们，然后你还有可能遇到同一个（或相似的）问题又被它再次弄得焦头烂额。

努力吧，做个有“问题”的程序员。