这些年在项目开发中遇到过很多困难, 有些在当时觉得很困难, 但是后来回头再看时感觉也没那么难, 所以要在其中找一个最困难的, 好像也不太容易比较.
这里就简单说两个印象最深刻的吧.
第一个是当开始开发时的一个页面嵌套滑动的需求开发, 用在查词结果页的展示, (此处可以展示实景)
难点是要在一个可以侧滑的场景下, 也可以上下滑动, 并且在上下滑动的同时要控制header的展示位置, 当时也是参考了很多实现, 包括, 外部viewpager+内部listview, listview+悬浮header
scrollview+listview 发现都不能很好的实现, 当时自己也是对页面触摸事件分发一知半解, 对嵌套页面的滑动冲突没有实际经验, 所以面对这个问题觉得很头大.
好在最终在借鉴各种方案的前提下, 通过外部scrollview + viewpager+listview的方式实现了, 主要逻辑都在外部的scrollview的dispatchTouchEvent()中,
经过这一两年, 也遇到过一些其他的例子, 现在仍然感觉当时的处理还是比较有道理的.
通过这个需求, 自己对页面事件分发流程的理解也算是更深一步.
第二个要说一个应用换肤的需求, 当时产品提出一个笼统的换肤的要求, 但没有说明具体的方式方法, 我们也是分析研究了几种当时能够想到的方式, 包括主题切换方式实现, 还有通过插件方式提供资源包, 又分为静态预置, 动态获取两种更新方式. 形式上也分为简单资源压缩包, 或者以apk形式形式提供. 而在资源包具体实现上又分为全量包, 和差量包;
这个需求的难点在于前期的这些调研, 需要对每种方案都进行研究, 分析原理, 风险, 并测试流程.
最终考虑到我们的换肤需求, 并没有太多的动态性, 作为我们的应用未来可能也不会qq一样会有第三方提供主题插件, 而且未来的UI变化太大, 也无法提前确定一套颜色+图片的设计框架.
所以最终我们选择了最保守的方案, 只是抽取了应用设计的颜色, 在不同的5个主题下分别定义了这几十种颜色, 而在后期的页面开发中都必须使用这些颜色号, 而不能直接设置具体颜色值.
这样主题切换时, 就会自动呈现不同的颜色主题. 此处可以实景演示.
代码重构: 从最开始的原始结构: activity+ fragment 逐渐过渡到mvp模式开发. 在业务分模块的前提下, 区分model, presenter, view三个部分
其他也有很多难点,包括:
实现兼容的状态栏沉浸式方案, 并且解决因此引起的AdjustResize模式失效. 至今stackoverflow上还有这个问题的讨论, 当时也是查了很多资源, 才解决.
加快应用启动速度, 需求要求我们的查词页面在所有机型上0.5s之内启动完成, 这个为了这个需求费了好大劲, 显示分析页面启动过程中所有的耗时点, 然后重构代码, 延迟加载, 优化布局, 去掉大图片资源, 改为自定义颜色值, 自定义一些布局控件, 减少measure步骤, 等等, 然后再次分析耗时点. 最终基本上在所有手机上实现0.5s内启动. 但很可惜后期的需求又把这个需求覆盖了, 我们现在也提供了启动广告页面展示, 已经不再要求快速启动了. 但仍然在这个过程中, 熟悉了一套优化启动速度的经验.
fragment的引入. 之前的应用版本中没有使用过fragment , 而我们从7.0开始需要一个侧滑菜单, 并且需要支持平板, 所以是一个引入fragment的好契机, 通过引入fragment, 实现了一部分页面的复用逻辑, 像是左侧的侧滑菜单, 在平板上就是常驻的. 实现本身并没有什么难度, 但遇到的问题还是很让人头痛.
一篇博文:http://www.jianshu.com/p/d9143a92ad94
在Activity之外, 还得重新研究fragment的生命周期, 而fragment的生命周期更复杂;
startActivityForResult的返回码需要处理; 在嵌套fragment中收不到这个回调. 新版android已经修复了这个问题
getActivity()返回null; 常发生在内存不足被重启的情况下; 有异步操作没有完成, 而fragment已经detach了. 好的建议是在fragment内部存一个activity实例;
有使会生成两个一样的fragment实例, 给调试带来困难; -- 什么情况下? 内存重启, 具体可以见:http://www.jianshu.com/p/78ec81b42f92//新版android已经修复了这个问题; 能用replace就不要使用hide() show()
popBackStack 不可靠, 容易导致白屏问题; --具体原因是内部的bug, 新版本android 已经修复;
Fragment传参, 需要注意, fragment自动重启时参数为空的情况.建议使用setArguments() 但是一些复杂的自定义类对象, 又做不到.
fragment切换动画不如view切换动画好实现;
形成经验:只有在整个页面都需要复用的时候才考虑使用fragment, 而如果是一些局部显示, 优先考虑使用view . 尽量不要使用嵌套fragment; 配合mvp模式, fragment尽量不参与业务逻辑;
总之要轻度使用fragment;
小说的排版,
需求要支持小说阅读页面点击查词功能, 需要动态计算点击位置对应的单词; 同事又要支持阅读页面点击跳转, 这样在实现时, 需要增加标签支持, 这与前面的点击查词功能有些冲突, 实现时非常头痛.
如何点击取词;
如何在TextView中显示链接, 并相应点击事件.
消息推送:
机型适配, 个别小机型崩溃问题定位.用户修改了字体, 用户root刷机之后崩溃, 还有修改了特殊语言之后的崩溃,
SDK开发;
自动化测试方案: 使用jenkins搭建了一个自动化运行平台, 可以自动执行写好的脚本, 验证核心查词接口的功能,
难点是包括jenkins, robotium, 都没有使用过, 需要从0开始,
客户端页面可被后台随时启动功能. 可以根据需要, 随时通过后台唤起客户端的一个页面, 可以是一个展示网页的页面(此时需要把网页地址作为参数传给客户端), 也可以是客户端已经存在的任何一个页面, 比如一本小说详情页, 一个课程页面, 在需要开展促销活动的时候, 提供跳转到这些页面的能力;
入口是后台推送入口和主页预留的活动入口;
需要实现一种后台可配置的启动字符串机制, 最后确定了通过以个json格式的字符串, 来制定要启动的页面, 和附带相应的参数; 这样客户端所有的页面都不需要修改, 只需要在入口处解析出这个命令字符串, 然后跳转到对应的页面;
遇到的困难是, 有些已有的页面需要很复杂的参数, 甚至是一个bean 对象; 所以在给这些activity准备参数的时候就要通过字符串的形式提供, 然后再解析为bean 对象实例.
从某种意义上来说, 就是定义了一种启动页面的协议.
内存泄漏分析:
