2020年9月，面对“金九银十”，一个无法跳槽的程序员附答案

面试如作战，我们看战争影视剧的时候，经常看到这些剧作往往主要聚焦于作战过程、战场战略，对战前准备给的篇幅往往很少。实际上，战前准备也是关键的一环，没有充足的粮草、车马、兵器的准备。别说赢得战争，投入战斗都不可能。

这个道理在面试中也是一样。如果不做面试准备，就犹如不磨刀枪上战场，胜负更多则靠运气。尤其是对于刚刚毕业的大学生来说，成功的面试，往往基于充分的准备。充足的准备，有可能做到十发九中，面试一家成一家。

那么面试之前，我们需要做哪些准备，才能做到胸有成竹呢？这个话题将从对于简历的准备、对面试公司的了解等方面来说。今天在这里给大家之后的面试提出3个走心的面试建议，希望对大家有帮助，也祝大家面试顺利~

经常会有朋友私聊我帮他看下简历，发现了一些共性问题；除此以外，我偶尔面试一些同学，有一些个人的感受分享给大家。

写在前面

一直以来，技术圈里面只要涉及 Android Library 的文章，几乎都在讲如何发布到 Maven/Jcenter，却很少见到有文章来指导大家如何编写一个规范又好用的 Android Library。

这几年 Android 各式各样的开源库层出不穷，国内的很多开发者都慷慨地将自己的一些成果做成开源库发布出去，然而当我们兴致盎然地想去试用一下这些库的时候，却时常会遇到“引用”“依赖”“冲突”“API 调用”等各种问题，这其中有很多问题，其实是库的作者本身造成的。

魅族的联运 SDK 从去年8月份开始立项，10月份开始逐渐有合作伙伴开始接入，经过半年多以来已经有超过50家 cp 应用接入，期间版本仅升级了1次，其余时间一直在稳定运行并寻求新的合作伙伴。在期间我们也收到了很多 cp 应用开发者的反馈，但更多的都表示这个库接起来非常轻松易上手，这也让我非常欣慰。

事实上，我在正式参加工作之前，已经做了2年多时间的个人开发者，这段经历让我深刻地体会到了开发者究竟喜欢什么，不喜欢什么。如果每一个 Android Library 的作者在编写的时候能够常去换位思考，多站在接入者的角度审视自己这个库的设计与实现，那么往往出来的 Android Library 效果都不会差。所以我会在接下来的内容中跟大家分享一些我们的做法，这些做法有一些也是踩了坑之后才填上的，我会把他们写出来，希望对大家今后的开发工作有所帮助。

规范工程结构

一个规范的 Android Library 工程应该由一个 library模块与一个demo模块共同组成。

demo模块的好处有两点：

1. 方便开发时自己调试，自己写的库，自己写的过程中就要不停尝尝咸淡才能保证“真香”
2. 库发布后可以编译出 apk 供人先行体验

注意 demo 模块的 build.gradle 在引用 library 时应该做出区分，如果是 debug编译模式，则直接引用 library 项目，如果是 release编译模式，则应该引用你发布的版本。相信 android 开发者都有过“开发调试的时候好好的，编出来的正式版就有问题”的经历，使用这样的引用模式，万一你发布的库有问题，则可以在编译 demo apk 的时候立刻发现。好在 build.gradle 在引用的时候可以很方便做出区分：

        debugImplementation project(':library') //debug 版本直接引用本地项目
        releaseImplementation '远程库地址'   //release 版本引用远程版本用来最终测试发现问题

指导接入者快速依赖全部 aar

如果你的库没办法发布到 mavenCentral，那么提供 SDK 给别人的时候 可能会有多个 aar 需要对方添加到项目里。我们经常在网上看到一做法，要求接入者在依赖时，先把 aar 文件拷贝到项目下，然后修改 build.gradle 申明参与编译，接入者必须仔细看 aar 的名字是什么，因为在 build.gradle 是需要声明清楚的。

事实上，你的接入者没有义务去弄清你的 aar 命名。接你的库已经够累了，为什么还要人家仔细看你的命名呢？这里推荐一种做法：

1. 让你的接入者在他们项目 app 模块下新建 libs/xxx 目录，将你们提供的所有 aar拷贝进去，这个 XXX 可以是你们渠道的名字，以后这个下面的 aar 就全是你们的，跟其它的隔离开。
2. 打开 app 的 build.gradle，在根节点声明：

repositories {
    flatDir {
        dirs 'libs/xxx'
    }
}

3.在 dependencies{} 闭包内添加如下声明：

//递归 'libs/xxx` 下所有的 aar 并引用
def xxxLibs = project.file('libs/xxx')
xxxLibs.traverse(nameFilter: ~/.*\.aar/) { file ->
    def name = file.getName().replace('.aar', '')
    implementation(name: name, ext: 'aar')
}

或者，我们可以参考依赖的第一行，直接用下面的代码一步到位（感谢评论区 @那时年少）：

    implementation fileTree(include: ['*.aar'], dir: 'libs/xxx')

这么一来，gradle 在编译前就会自动进到 xxx 目录下面，遍历并引用所有 aar 文件。之后哪个 aar 有更新，就让你的接入者直接把新的扔到 XXX 目录，删除老的就行。至于你的 aar前缀是啥，他们根本不用关心。

Kotlin？大胆用!

Google 早在2017年就官宣了 Android 与 Kotlin 的关系。我在这次写 SDK 的时候最大胆的决定就是全部使用 Kotlin，事实证明我是正确的。Kotlin 的引入帮我省去了大量的胶水代码，各种语法糖吃起来也是真香。所以从现在起如果你决心造一个轮子，大胆全部使用 Kotlin 来写吧，但是请注意。因为你的引用者大部还是 Java 程序员，甚至可能还不熟悉 Kotlin，因此一些兼容点还是值得注意的。

引用者的项目必须添加 Kotlin 支持

如果你的库是 Kotlin 编写的，不管用你库的人是用 Java 调还是 Kotlin，请他们把项目添加 Kotlin 支持，否则在编译期间没问题，但在运行期间很有可能遇到No