一个Android开发的2018年

2018年就要过去了，感觉今年对自己来说变化比较大，翻了翻自己的git记录，在这零散记录一下

工作

1月

年初一月份的时候还在有赞做webview加速的方案。业余还翻了翻 webview 初始化的源码，写了一篇博客记录。

WebView深究之Android是如何实现webview初始化的

2月

比较惨的日子，年终绩效 1 被动离职，重新开始找工作，而且毕业时间没满一年，特别的尴尬。反思了一下表现，发现也离职其实也不是个坏事。可以出去面一轮重新定位一下自己，顺便涨薪改善下生活

思考了一下实习到离开有赞的时间，表现确实低于预期。对业务没有兴趣，开会睡着这种事情也犯过，对别人的批评容易感到惧怕。到后来变成了只低头干活，对其他事情几乎毫无表现，平时也不怎么说话。从现在回头看，确实很糟糕。

其实17年底从微商城去共享已经是我顶着不出活被开除的危险厚着脸去的，因为觉得跟着大佬做webview的项目能学到很多，自己做到一半了也不想放弃。现在想想，从做事的角度，我做错了，从技术进步的角度，应该是做对了。整个webview加速的项目，让我的全面思考，代码重构的能力上了不止一个档次。

年前年后找工作，因为经验的问题，大厂和偏大的厂基本没有投成简历。先是面试海康，同花顺啥的公司练了手。年后拿到了几家公司的offer，最后觉得铭师堂教育类的业务还行，人也有千把人，薪资也是给的最高的，加上有认识的人，能更快的适应团队，就去了。

3月

入职铭师堂。刚开始是基础设施组，但是因为业务需要人做，后面去了教师端业务线。兼职一部分Android的基础活。

入职第一个开始写的是替换老代码的下载，用okhttp开始写一个新的下载 SDK， 写了一周多时间，支持了普通文件和m3u8的下载和断点续传。把线程池，任务，网络每一层都抽象的很清楚。虽然不是很难的东西，但是也算是入职后打点基础，顺便验证下自己还是有一些基本的sdk的设计能力的。

刚入职的时候比较着急产出东西，写 SDK 的时候其实也没有很好的和同事沟通清楚需求。被指出来的时候反思了一下。觉得在公司，沟通清楚事情，再开始干活往往会更加清晰。其实这也是业务团队在每个迭代期添加很多评审流程的原因之一。

3月工作不是很多，中间又阅读了一下 GreenDao 和 Android Handler的源码，出了2篇文章。

GreenDao源码

深入理解Android消息机制

4月

开始做教师端的业务，没记错的话是一个校本试卷的业务。

5月

在业务开发的同时重构了一些老的代码。印象比较深的是作业类型非常的多。老的代码大概写了8，9个if-else

if (homework1) {
} else if (homework2) {
}...
 /// n个作业
 ...
 else if (homeowrk9) {
 } else {
 }
复制代码

我把他重构到了子类，写成

Manager.register(homework1)
...
/// 注册
...
Manager.register(homework9)
Manager.dispatch(type)
复制代码

整个教师端的首页逻辑被我修改的很清晰。很容易维护。后面产品提出小的需求修改的时候我很快就能找到对应的地方。

我刚去的时候项目还是mvp架构。我还写了一个 Android Studio 的插件去自动生成 mvp 的模板代码。

研究了一部分Android 原生的音频播放，写了一个简单的sdk， 但是因为公司需求不着急换。后面就没继续了。

6月

开始在自己的业务模块里面使用 Kotlin， 并且在公司内部做了 Kotlin 的分享。其中也了解到了，我现在的团队其实技术还是比较开放的。

开始强迫自己在普通的业务开发中尽可能的使用函数响应式的方式去处理逻辑。 在自己业务模块内部写了一部分单元测试 期间做了一个比较无聊的需求。各种文案细节的错误在提测的时候bug满天飞。

7月

重构整理公司原有的jsbridge sdk 业务开发 开始准备把 Android Arch Component的东西加到自己的业务 翻译了一把 kotlin coroutine的文档，在 github 上。可能内容当时比较冷，只有 72 个start。

kotlin协程文档（译）

8月

整个移动端的大整改。因为我的业务内容不多，看大家把公共模块的资源移动到自己的业务如何重命名比较累，就写了个 python 脚本自动化的处理了一部分。

利用 Instrumentation 监听 Activity 跳转写了一个 monkey 随机测试的脚本 顺便撸了一遍monkey 随机点击的源码，虽然感觉然并卵，猜都能猜到是随机事件+模拟点击屏幕

monkey工具的源码我当时弄了一份在 github， 有兴趣的看看也无妨

Android monkey 工具源码

参与日志监控的开发，一期比较简单。二期交给了架构组同学。

和同事一起，在各自的业务模块里面加入了 arch component，基类用lifecycle重构，抽出了生命周期相关的逻辑。 p层改用 viewmodel 替代。 数据流使用 LiveData 保持单向。具体的我代表团队，发出了一篇文章。感兴趣的也可以看看

Android Architecture Component 和架构升级在铭师堂的实践

9月

8-9月当时一直在开发一个习题的业务。比较忙。之前老的图片选择库有问题还重新开发了一个。

开发的时候为了处理分页加载本地图片的问题，我使用了 paging， 因为用错了，找问题的时候顺便撸了源码。写了一篇文章：

Paging分页加载库源码分析

有一个生活中的小插曲，当时合租的室友想在小区做外卖，第一天晚上还真有不少人打电话订。我看他们用微信好友红包的方式太麻烦，就兴冲冲的写了个小程序。

可惜2天刚写了个壳，他们就被物业查水表了。。。

10月

10月，因为觉得组件化带来解耦的同时也带来了工程的管理成本。打造一个移动端自己的ci平台也很必要。于是，我拉上一个对前端很有兴趣的Android 同事，开始研究自己做打包平台。

和领导沟通之后，我成了这个项目的 owner，第一次当owner才知道owner的不容易。从前期的需求收集，评审，包括这个平台要做成一个什么样的产品形态，原型图都要自己从头开始。中间也有很多对标不一致的问题。

十月在业务开发之余，我就在调研整个技术方案。在gitlab ci， jenkins api都玩了一圈之后，考虑到团队现状，选择了构建基于 jenkins， 可视化和配置平台用自己的。构建产物的下游操作自己处理的方案。

当了owner，自己大概总结了几点：

1. owner需要比组员付出更多的精力，编码只是很小的一部分。
2. owner在考虑技术方案的时候要多维度思考。从实现成本，对现有体系的影响，团队资源各个角度都要考虑到。要发挥出技术的价值，不能有一丝一毫的炫技和技术成本的浪费
3. owner需要经常主动找组员对标，避免自己和组员在产品上理解不一致导致的后续问题。很多时候，“一致”只是我们自己的错觉。
4. 对于非全职的技术方案。owner需要让大家对目标有共同的追求。需要对体验，功能各个方面有追求，否则很容易把项目弄烂尾。这一点其实和第三点有关系。
5. owner需要想办法争取资源。CI一期结束的时候，为了下一步组件化管理坐进来，我请大家吃饭顺便把基础设施的同学叫上，先吃，最后大概率会一起进来干活。

11月

ci平台一期的服务端开发。技术栈用的 gin + gorm 虽然是内部项目。代码也写了几千行。后期因为和jenkins的api不一致，想了很多同步数据的办法。总体在写代码这件事上，自己还算满意。 在开发到发布的过程，自己也想到了监听进程守护进程，监控服务等问题。因为golang不能接运维的体系，所以后面这些也打算自己来弄。

11月还有一个很重要的事情就是我们开始写 Flutter。我们把flutter接入了混合工程。

12月

最近的一个月。优化ci平台。 使用flutter重写了我的业务的一个页面，争取年后可以直接发到线上、 支援其他人的业务开发。

关于Flutter之类的新技术，从我刚开始觉得kotlin是好东西没有理由就要上，到Flutter思考为什么要上，怎么上。这一点我感觉自己也有了很大的进步。

关于 flutter， 我在写一个 todolist 的app， 一方面作为学习，一方面想写一个自己的 工具 装在手机上用。 项目是开源的，还正在写。有兴趣的同学可以指点指点

Flutter写的todolist

技术

今年学习了 golang，开始学习一部分 服务端的技术。以及移动端跨端的技术。目的一方面是因为兴趣（对Android UI的内容毫无兴趣）， 另一方面是希望在移动端地位日渐往下的时候，能快速完成移动业务并且把手伸向其他领域，争夺利益。

学习了这么多自然会联想到技术的深度和广度。自己也做了思考.

• 广度

技术的广度其实是很有必要的。最简单的例子，JVM上的函数响应式，或者异步编程，当初看rxjava和kotlin coroutine的时候，费了很大劲才转过来思维。但是我相信，如果之前接触过js的异步编程模型。coroutin的async await部分会很容易就掌握。而且广度，对于开阔眼界，包括在公司干活的时候看到更多的资源，更多的潜在问题，都是很有用的。事情做到一定程度，广度不可缺少。

• 深度

技术，在学习之后最好的状态，个人认为是厚积薄发。一个有价值的技术人，应该是有不可替代性的。这里，包括我们对技术的掌控，对技术的理解。这里离不开一门技术的深度。如果技术只是停留在 hello world 的水平，做大家都能堆砌简单业务随随便便做到的事情。那么自己的技术会变得毫无价值。举个例子，我们想要做更多的事情时候，会面临非常多的场景，更好的解决这些场景，作深入一件事情，就需要我们的技术深度。理解的越深，做的越好。

从做事的角度，个人觉得广度和深度并不矛盾。目前为止，我可能采取的技术路线是，广度铺开1-2件事，例如服务端和flutter，短期内虽然不求接触到非常多的问题，但是只要是自己接触过的，就要去理解到位。例如 flutter，需要阅读一部分源码应付自己平时报错会不知所措。例如服务端，会深挖一些点去优化自己的内部项目。对于自己没场景没必要去接触的东西，如果没遇到啥问题，会用就可以。乱用了只要不影响团队，个人暂时也不会太多关注（例如Android的包大小，图片放哪里之类的问题），但是只要能力养成了，我觉得如果有一天他们成为我的问题了，我也不是不能解决。

学习。今年买了2本 Android 源码解析的书，空闲时间复习了一下 ipc 和 初始化的东西。 买了一本py处理数据的书，暂时还没开始看。估计暂时是不会学习相关的东西。没有精力了。

生活

• 健身

去年毕业的时候办了一个健身卡。就是随便水水，虽然去的不少，但是练的不足。今年7月办了一个健身私教。12节课虽然花了几千块钱。但是也看到了效果。

健身开始的时候体重 110 kg 不到的样子。体脂率29% 现在体重在家是 95kg， 体脂率26% 目标明年夏天到 85kg， 体脂率22%

• 游泳

感觉:swimmer:还是个比较舒服的运动。从去年蛙泳个2趟很累到现在，也可以有 800m 23分钟的速度。不快不慢。如果有人一起，想参加明年的活动去钱塘江里面体验一次。

• 电影

现在养成了每周五晚上看看最新电影的习惯。去的次数比较多。期待 19 年的漫威。

健康

今年感觉坐久了要不舒服，拍了核磁共振轻微膨出。貌似没什么大事。但是需要注意，不注意的话说不定哪年就变成腰突了。

今年查出尿酸有点高，挂号网上问了医生，跟肥胖还是有很大的关系，需要继续坚持运动。

秋天的时候咳嗽，断断续续一个月一会好一会不好，去医院，把 CT 和 肺功能检查全做了，还顺便被要求查了个甲状腺，所幸只是有小结节，和咳嗽没关系，只是普通咳嗽。

今年检查身体花了不少钱，自己比较怕这种东西。就当花钱买放心，还是需要健身运动，有一个健康的身体。身体是革命的本钱，身体没了，什么都没了。

感悟

今年算是经历了很多事情。感觉自己对于很多东西也有了新的认知。

对于工作和技术

1. 创造和发挥技术该有的价值
2. 和团队同事保持沟通和对标。不要活在自己的观点里
3. 新技术可以追求，但是要列出充足的理由和兜底方案。盲目说上等于不会

对于明年，希望自己

1. 深挖服务端技术，让自己拥有打造一套优秀的前后端一体技术方案的能力
2. 对团队的现状，业务的痛点做进一步思考，发挥出技术应有的价值
3. 研究跨端技术，提升效率，如果可以，直接把h5替代native的业务抢回来，提升移动团队的地位。

瞎** BB了很多，感谢大家的浏览。有什么想说的，也可以评论留言，共同讨论