开发中遇到的难点

这些年在项目开发中遇到过很多困难,  有些在当时觉得很困难, 但是后来回头再看时感觉也没那么难,  所以要在其中找一个最困难的, 好像也不太容易比较.

这里就简单说两个印象最深刻的吧.

第一个是当开始开发时的一个页面嵌套滑动的需求开发,   用在查词结果页的展示,  (此处可以展示实景)

难点是要在一个可以侧滑的场景下,  也可以上下滑动,  并且在上下滑动的同时要控制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 对象实例.

从某种意义上来说,  就是定义了一种启动页面的协议.

内存泄漏分析: