关于android:一个便捷操作的Android可视化规范检查

1次阅读

共计 3755 个字符,预计需要花费 10 分钟才能阅读完成。

Hello 啊各位铁子,明天带来一个本人开源的可视化标准查看工具,真正的懒人必备!让标准查看回归最简略,最便捷的操作流程,别说开发人员,就是一个小白也能针对我的项目进行纯熟的标准查看操作,我先贴下地址,前面解说实现过程。

我的项目开源地址:

https://github.com/AbnerMing8…

目前工具有九个性能,蕴含了,正文,类,办法,变量等根本的标准验证,如下图所示,当然也都是一些常见的标准性能查看,后续的话也会进行拓展,尽管此标准是依照我公司的规范去执行的,其实,Android 嘛,大差不差,就那些标准,根本百变不离其宗,如果有不是很合乎的,大家也能够在源码中进行更正为本人须要的就能够了。

我的项目运行效果图:

我的项目呢,没有抉择打包进行公布,因为思考到各个我的项目,各个公司的标准不一,打包的话不符合实际的开发需要,所以啊,各位铁子,大家能够 down 下我的项目,依照流程本人运行我的项目,而后查看理论的性能成果,当然了,你也能够针对本人公司标准,进行减少或批改已有的逻辑,使其合乎本公司的标准流程措施。

标准这个货色,我置信大家的公司都会有,俗话说无规矩不成方圆,一个我的项目要是没有标准,每个人都依照本人的思路去编写,长此以往,大家能够想想,这样的我的项目会呈现什么问题?这里我就不明说了,所以啊,标准是一个我的项目的基石,也是掂量一个我的项目,是否强壮,稳固,可保护的规范,堪称是相当重要的。

既然了有了这样的一套标准,那么在执行的时候,就须要去进行验证,毕竟协同开发的我的项目,每个人都有本人的一套开发规范,有时因为粗心或忽略,可能某一块就没有依照既定的标准去落实,那么就须要进行斧正进去,而后进行批改,同样的新人接手我的项目,或是外包人员染指开发,就更应该进行标准的查看,从而让我的项目在一套规范的体系中运行。

其实市面上的标准查看工具颇多,像 Lint,CheckStyle 等等,要么须要肯定的配置依赖,要么没有一个能够定制化的标准执行,大多数和理论的业务多多少少有些差距,基于此现状,这也是这个工具诞生的起因。工具的诞生,旨在简略便捷,进步咱们的开发效率,节约咱们的工夫老本,使得我的项目稳固,可保护,基本上初衷便是如此,当然也是依照这样的准则去落实的。

Ok,侃了有点多了,说一说实现的思路吧,这个可视化的工具,是用 electron 进行开发的,和那个代码生成工具一模一样,大家感兴趣的话,能够持续看,不感兴趣的话,就别看了,因为和 Android 常识关联性不大,[手动捂脸],间接去 Github 间接下载体验吧。

Electron 我就不多说了,因为之前在介绍代码生成工具时,说了很多了,根本都是采纳最根本的 web 语言去开发的,这里就不过多赘述了,简略的说几点实现思路。

一、定位我的项目

定位我的项目,就是须要抉择一个能够执行的 Android 我的项目,这是实现性能的第一步,没有我的项目,上面的所有性能根本无奈发展。

抉择我的项目,基本上是抉择一次,在根底配置页面进行保留,而后,每个性能页面首先遍历出我的项目下所有存在的 Module,进而针对不同 Module 做针对性检测。

关上一个目录应用到的是 electron/ remote 中的 dialog 模块,具体应用如下:

// 引入
const dialog = require('@electron/remote').dialog;

// 抉择文件
        dialog.showOpenDialog({
            title: '请抉择您的我的项目文件,尽量是 Android 我的项目哦~',
            properties: ['openDirectory']
        }).then(result => {
            const path = result.filePaths;
            if (path != null && path != "") {
                // 抉择后回显
                $(".config_file_input").val(path);
                // 进行保留门路
                localStorage.setItem("select_path", path)
            }

        });

通过以上的代码,咱们就能够针对抉择的门路进行保留,目前呢,只是定位到了我的项目,上边说了,咱们是须要定位到 Module 的,如何进行定位到 Module,如下代码:

这里用到了 fs 模块,之前在讲述主动生成代码工具的时候也说过,就不多赘述了。

// 引入 fs 模块
let fs = require('fs');

// 取出存储的门路,不为空,进行遍历文件
if (selectPath !== "" && selectPath !== null) {
            // 遍历文件
            fs.readdir(selectPath, function (err, files) {if (err) {console.log(err);
                    return
                }
                //length 为 0 证实,抉择的文件门路下是空的, 暗藏抉择目录选项
                if (files.length === 0) {
                    isEmptyDir = true;
                    $(".data_select_file").css("display", "none");
                    return;
                }
                // 不为空,就遍历以后门路下的所有的文件目录
                var isDir = false;
                files.forEach(function (item, position) {
                    let path = selectPath + "/" + item;
                    fs.stat(path, function (err, stats) {if (err) {return false;}
                        if (stats.isDirectory()) {isDir = true;}
                        // 最初一个判断
                        if (position === files.length - 1) {
                            // 没有一个文件夹,暗藏
                            if (!isDir) {
                                isEmptyDir = true;
                                $(".data_select_file").css("display", "none");
                            }
                        }
                        // 检测抉择的是否是一个 Android 我的项目,通过是否蕴含 app,gradle,settings.gradle,当然也能够判断其余
                        if (item === "app" || item === "gradle" || item === "settings.gradle") {numAndroid++;}
                        // 判断是文件夹
                        if (stats.isDirectory()
                            && item != "build" && item != "gradle"
                            && item.indexOf(".") != 0) {
                            let nodeDiv = "<option value='" + item + "'>" + item + "</option>"
                            $(".data_file").append(nodeDiv);
                        }
                    });
                });
            });
        }

基本上,所有的性能,都是基于以上逻辑的。

二、定位文件

能够发现目前实现的性能中,像 layout,图片命名,类名查看,就属于文件类型的,针对这种文件性质的,咱们就须要找到其文件,而后获取文件名字,就能够简略的判断是否合乎相干标准了,比方类是否满足大驼峰,layout 是否满足,小写,下划线,是否带 Module 前缀等等规定验证就能够实现相干性能了,图片基本上和 layout 相似,简略吧,其实一点技术含量没有 [手动捂脸]。

layout 的门路是固定的,src/main/res/layout,间接加上前边的我的项目门路加上 Module 门路就能够进行遍历了,代码就不沾了,就是一个遍历。

类文件的话,就须要循环遍历了,也就是 Module 下可能会有 N 个包,那么就须要一直的遍历进去,而后失去一个一个的文件,再进行简略的规定验证,后续的话,对于 Activity,Fragment,ViewModel 等一些非凡性质的,能够加上包名进行判断。

三、代码内容截取

代码内容截取,绝对略微简单一些,因为,失去文件之后,须要对文件中的内容进行判断,比方,类正文,办法正文,办法命名,变量查看,try catch 检测等等,这一类的标准查看,都得要获取到文件内容,而后能力执行下一步的操作。

类正文就比较简单了,失去文件内容之后,无论是 Java 文件还是 Kotlin 文件,大括号必定都是存在的,那么就截取呗,以“{“进行截取,获取第 0 个,而后判断相干关键字是否存在,比方 author,desc,date 等,或者其余关键性的参数,不存在就意味着类正文不存在,就能够把不存在的类进行返回到页面上,让开发者做针对性批改即可。

办法正文,须要判断是 Java 文件还是 Kotlin 文件,如果是 Kotlin 文件,咱们间接能够以“fun“关键字进行截取,如果是 Java,那么就须要找每个办法的相似之处,我这边采纳的是“) {”,当然了也有更好的计划,大家能够针对源码进行优化。

其余的,像办法命名,变量查看,try catch 检测,基本上也是相似的寻找关键字,截取形式进行实现的,这里也不多过多赘述了,大家参考源码实现就能够了。

源码中相对来说比拟乱,有些代码还没来得及优化,毕竟咱也不是专门搞 Web 开发了,哈哈,凑合着看吧,有问题,大家一起沟通,一起修改,毕竟这种货色的存在,多多少少的可能在标准查看上,节约咱们一部分的工夫。

还有啊,那个可视化的脚手架,本人也在整顿,会不定期更新进去,其实也没啥技术含量,大家看前几章,预计也能搞进去,前面工作不忙了,会接着更 [手动捂脸]。

疫情期间,大家多留神防护。

正文完
 0