简易集成的MVP模块化App框架（3/3）

上一篇

简易集成的MVP模块化App框架（2/3）

前言

一直想整理一个自己app框架，现在刚好不是很忙就整理一下，尚不成熟还有待改进

大纲

1.整体结构：MVP模式+模块化

2.网络框架：Retrofit+Rxjava

3.屏幕适配方案：头条的AndroidAutoSize

4.分享框架：Mob的ShareSDK

5.其他：base、常用工具类以及简易的自定义控件等

6.常见问题

7.使用说明

项目链接

https://github.com/UncleQing/QingFrame

6.常见问题

1.butterknife再模块化遇到的问题

首先有个编译器问题，就是依赖

annotationProcessor 'com.jakewharton:butterknife-compiler:x.x.x'

这个需要在所有使用butterknife的module和library都依赖。

还有个资源的问题，这个项目因为新建立没有集成业务模块所以还未暴露出，不过以前项目遇到过，大致就是R2和R的问题

参考：https://www.jianshu.com/p/c6e3f67e391e

2.分包工具意义

一般大工程都会使用，因为默认打包只有一个dex文件，最多存储65536个方法，因此如果项目过大就会超出报错

参考：https://blog.csdn.net/xiaxl/article/details/83089944

3.AndroidAutoSize使用注意

别忘了在manifest中添加meta-data

4.图片选择器或PhotoUtils使用注意

获取图片url在7.0之后发生了变化，因此需要一个fileProvide

在photoUtils设置，包名+fileprovider格式，并在Manifest配置相关provider

//还需再Manifest配置相关provider
public static final String FILE_PROVIDER = "com.zidian.qingframe.fileprovider";

        <provider
            android:name="android.support.v4.content.FileProvider"
            android:authorities="com.zidian.qingframe.fileprovider"
            android:exported="false"
            android:grantUriPermissions="true">
            <meta-data
                android:name="android.support.FILE_PROVIDER_PATHS"
                android:resource="@xml/file_paths" />
        </provider>

参考：https://blog.csdn.net/lmj623565791/article/details/72859156

5.分享注意问题

再次重申微信分享需要有正式签名，并保证包名和微信开发平台申请一致，否则拉不起来微信。其他注意细节详见分享介绍

6.app更新部分

详细：https://blog.csdn.net/Demo_Jin/article/details/88431270

先列举这么多，以后发现了再追加

7.使用说明

现在仓库链接还没搞好，只能从GitHub手动集成了

1.集成后修改包名为自己需要的包名

详细：Android项目修改包名

2.修改项目下的build.gradle，版本号之类

3.根据业务新建module，File->New->New module

4.修改各个module下的build.gradle，确保javaCompileOptions和依赖library-common，参照app下的build.gradle

5.activity继承BaseActivity、Fragment继承BaseFragment等

总结

基本设计思想是从原型得出大致设计方向，将共通的东西抽象出来、分类，然后设计工具、零件、基类，将复杂的东西集中，使后续开发变得简易快捷。当然大多数项目后期需求会变来变去，所以设计最好模块化，可配置。例如一些功能性的UI，可以让服务器后台配置，然后只需解析服务器数据就能动态显示哪些入口之类。一些经常变动的页面最好使用html实现。总之我的理解app框架设计的核心理念就是好看、好改和少改，因为上线的app再发版一次真很麻烦，所以发版除了必要性的bug修正以及新功能追加，剩下的都应该可以从后台配置。另外也为了后续接手项目的同事能尽快熟悉工程，否则设计的不好，接手的同事就看不透彻，就会发生因为改bug而改bug导致项目更加难懂，垃圾项目就是这么慢慢变成的...