1 关于项目大体框架的思路
(1) 关于框架主体用的模式
传统的mvc胜在方便，但是后期拓展性，维护性差
mvp胜在拓展性，维护性较好,但是接口繁多,谨慎处理引用
mvvm个人感觉可以替代ButterKnife
所以个人更偏向使用使用mvc+mvvm+接口回调的方式来达到mvp+mvvm的效果
(2) 通过封装接口事件按照份属模块类型进行统一回调处理
例如 地图事件 菜单事件 模块事件 登录事件
比如现在又个项目里面要做登录这个功能 一般因为由主项目衍生出其他类型的项目
在风格上基本大同小异 这个登录做个类比 实际项目中自己可以根据需求替换
现在就需要设计类 LoginView LoginViewAction 实现类一般会涉及到了ui操作
所有一般会放在Activity里面
1 初始化 比如loginView（String... args）
2 注入接口 比如loginView(loginAction)
3 实例化参数 开始在回调方法里面完善对应的逻辑
这种通过依赖注入提炼出来的模块在在其他衍生的模块可以直接拿来用 快捷方便
在一定程度上分割出对应的逻辑
(3) 关于mvc+mvvm+aop的思考,aop感觉和mvp核心思想非常相像（单一职责，接口分离）
一个简单的注解对应一个功能，虽然在一定程度上集成麻烦,不过在在后台使用
aop如火如荼的情况下，android使用非常少让在下很是费解。
2 关于代码外在表现形式的思考
（1） 做成arr包的模式
1 优势在于源代码是被封装起来的 查看起来相对麻烦
2 劣势在于做成这种模式的话 编译出来的arr在windows系统上
直接替换arr包没清理缓存会引用缓存的class文件
3 改动不大的前提条件下 做成arr包是个不错的选择
（2） 做成model的形式
1 代码挺暴露的，就像没穿衣服一样，容易修改
（3） 做成apk的形式
1 这个就很少了,插件化开发,在eclipse下面有着sharedUserId这个
属性,做成插件化开发更方便。
3 关于日志文件和项目调试这块
(1) 关于日志 首先要说的是studio(idea类似) 在adb没连接的情况下
或者端口被占等等 造成进程奔溃的时候控制台看不到日志 这个时候就突兀出了
本地日志的重要性 一般都是实现Thread.UncaughtExceptionHandler类，系统出现
crash的时候一般会回调uncaughException方法 这个网上比较多的工具类就不叙述了，
养成良好的阅读日志习惯是很必要的。
(2) 关于项目调试这块 这就不得不说后台了 有的时候项目出了问题为了要证明是谁的
锅，我们一般也要调试来拿到后台的数据甩出去才更有底气，
首先要说的studio， studio相比elcipse，还是elcipse这块相对于
更好用,studio觉得比较实用的快捷键在于 F8(执行下一步) F9(下一个断点) alt+F8(测试代码结果)
大家都知道点击左键是调试 但是点击完左键点击右键可以加上条件限制
关于elcipse,F6（执行下一步）F8(下一个断点) Expressions add new expression（测试代码结果）
(3) 关于项目构建问题 一般可以在gradle控制台找到具体原因 这个功能在idea里面是没有的
4 关于混淆apk和破解apk
1 首先是关于混淆apk elcipse和studio都有自带的混淆规则的文件
在elispse上面在projec.properties里面proguard.cofig=这个是混淆文件的名字
在studio上面在app gradel里面 设置minifyEnable true并且设置自己的混淆规则文件
2 关于破解apk 需要用到apktool dex2jar jd-gui还有用到的反编译的apk
（1）首先把apk后缀改成zip 然后解压得到classex.dex文件
（2）定位到dex2jar包下面 把classex.dex文件放入
（3）终端執行 d2j-dex2jar.bat classes.dex
（4）把生成的jar包用jd-gui打开
关于资源文件的反编译
1 定位到apktool目录下面
2 终端执行apktool.bat d -f app.apk
3 得到对应的app文件夹里面存放的是对应的资源文件
5 关于android的aop思考和问题
1 首先是aop是能解决什么问题或者说aop的优势（解决重复的代码判断,以注解的形式来简洁代码结构）
1 单一职责，对应相同的功能逻辑对应一个类,已注解的形式来实现 对内隐藏细节对外暴露接口
更符合接口隔离原则，依赖倒置原则，开闭原则。
2 一般核对登录 打印方法时间 权限核对 这种重复的代码可以减少很多 代码会更加的简洁 逻辑结构清楚
3 关于aop的实现现在一般是依托于aspject框架 因为需要用ajc编译所有需要配置gradle，这里
只讲配置gradle插件容易出现问题的地方
1 是命名问题项目名称尽量和artfactId一致
2 是groovy下面的包名有的时候会出现自动隐藏问题 比如你创建包名为com.yellow.plugin 里面创 建Yellow.groovy 在resources下面implementation-class=com.yellow.plugin.Yellow找不到这个类时 需要重新 再创建
3 编写groovy插件的时候一定要保证语法正确(可以下个groovysdk自己猜测下) 要不然会出现插件找不到错 误，本地插件更新时 要重新上传一遍
6 关于项目适配的思考(请先从美工拿到图的分辨率)
1 手机（现在一般是1280*720，美工出图一般也是这个）
1 可以创建一个Library比如resource来专门做适配
2 根据美工给的尺寸分辨率来生成对应的dimens,drawable
3 除了图标关于图片都用drawable显示
4 weight的使用
5 关于margin和padding的区别(padding是控件本身内部距离，意味着点击范围增大)
2 平板(这里只讲目前项目使用的方案)
发现使用最低限制符能起到一个很好的作用 用到的平板尺寸一般是2560*1600*320 这个就是sw-800
平板的尺寸更加多样 对于限制最小宽度来做适配是相对于其他选择是更方便和快捷的
7 关于项目框架的思考MVC和MVP和MVVM的必要
1 MVC 走一步算一步的模式 需求？加 逻辑变换？改
1承担着视图和逻辑的activity很容易变得臃肿
2 曾经做过一个聊天的页面，轻轻松松到了2000多行代码 甚至还有各种回调和Eventbus的使用，可读 性和维护性都很差，不过小项目撸代码还是很方便的.
3 后期逻辑的变化，代码的修改很容易造成代码,结构层次的混乱，拓展性很差。
2 MVP 青出于蓝 划分出一个Present来掌管逻辑 Contract是具体接口方法的管家，分 工明确。后期项目
维护起来相对于来说更方便，层级更清楚。但是也有几个小缺点
1 代码量问题比起MVC的模式要大很多
2 关于P持有引用造成内存泄漏问题
3在比较复杂的需求下,P的代码量会非常大，而且关于视图控件的引用会比较多
3 MVVM不知道各位看官怎么想法，反正使用过后第一印象是不需要ButterKnife了
1 数据的双重绑定在一定程度上,用起来是挺方便但是架不住需求的频繁变更
2 布局变化后需要重构才能生成绑定的ActivityBinding
3 Model的变化可以体现在ViewModel上,但是容易导致业务逻辑不是很明确
4 布局layout里面要注意加上android的熟悉 比如需要在一个控制一个控件的visible 需要导
入