一位移动端开发者这一年的辛路历程

原创
2017/01/25 17:04
阅读数 76

记得去年写年终总结的时候,我还在去看老友的火车上,那时对新一年充满了无数期许,虽已是争分夺秒,但是当宣布 game over 的那一刻,这一年的收获、成长、遗憾、失落已经定格。

内容提要

  • MVP 架构 App
  • 浮窗组件开源
  • NodeJs 全栈开发
  • App web 化发展趋势
  • 年度博客总结

MVP 架构 App

针对项目中结构混乱,分层不清晰,提出 MVP 架构的想法,经过内部分享,试点实践,最终于五六月份在 MVP 的基础加上 EventBus 全面重构。 架构的收益是持续的,去掉了耦合在各个层面上回调函数,从架构层面上规避了最常见的内存泄漏问题,同时由于层之间的高度解耦,使得我们可以针对不同层次使用不同的单元测试框架,大大降低了写单元测试的成本。

尽管 MVP 和 EventBus不算什么新技术,但对我们的项目来说是第一次,作为一个团队的一员,要引入新的技术或新的想法不是一件容易的事。你得说服你的老大还有你的同事,你不能干巴巴的说这个技术好然后你的同事就能信服你,特别是技术水平和视野上的差异,没有认知上的共鸣,你很难推动实施。作为团队的新面孔,我也是费了很多波折,开始在小组内做 MVP 的分享,再后来是在新接手的业务带头实践 MVP ,真正让大家全面认可是下面的经历:

大约是4、5月的时候,随着功能的增加,各处隐藏的内存泄漏问题终于累积到了一个爆发点,大量引发 OOM 问题。经过内存工具排查、反复测试、观察内存走向,游走大部分历史代码终于解决了问题。我把解决过程详细的写成了两篇内部分享文章,鞭尸了 n 多个黑代码(很多人为了怕影响同事关系,宁愿容忍渣代码,也不愿出,我很不赞同这种价值观,对于技术氛围的形成十分有害,渣代码就是要鞭尸,我觉得应该提倡 review ,彼此鞭尸渣代码。),内存溢出并不是在某个功能点,而是散布在各个地方的 Handler ,这些 Handler 让各个层次藕断丝连。为了规避这些问题,才有了后来的 MVP + EventBus,它比开始真正被接纳。

关于在团队中引入新技术,除了沟通能力之外,你应该还要做到两点:1 明白项目的问题在哪里,2 用你要引入的技术解决当下的问题,3 对于新的技术,团队成员成本多大,例如当时想本要使用 RxJava ,考虑到当时团队成员的学习能力成本就使用较为容易上手的 EventBus 了。

浮窗组件开源

为了方便玩家游戏过程不用切换游戏也能方便地体验我们的 App 的服务,我们需要"伸出一双手"到游戏中,在合适的位置、合适的时间出现。等于将 App 的功能阉割到浮窗中,所以逻辑还是比较复杂,经过几个版本下来遇到了很多坑,特别是帮兼容问题上,在解决这些问题之后我觉得应该把浮窗组件沉淀一下,开源出来:https://github.com/liuguangli/FloatUtil

插件化研究

在进行浮窗功能设计的时候,一开始打算做成插件的形式,花了大量的时间进行插件化的研究,看了几大开源框架,对于设计模式、Android 框架、App 加载和执行等都是一次进阶性的提升,最后形成了插件化研究的系列文章:

NodeJs 全栈开发

App 客户端的需求越来越少,刚好后端要做业务重构,进行前后端分离,主动申请参与前端的开发,从无到有参前端 NodeJs 项目架构并支撑第一个新业务的上线。前后端分离,在组织架构上也算是一种解耦, 为了让后端从"代码套页面"的噩梦中解放出来、更加专注于数据业务的开发,后端面向细粒度 API 开发,只关注服务和接口;NodeJs 作为服务到用户的中间层,面向用户侧的开发,关注交互和界面,提供多端特性的适配。

阅读全文直接点击:http://click.aliyun.com/m/9802/

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部