LibChecker-Rules
LibChecker-Rules copied to clipboard
zhaobozhen
（讨论）对于不开放的私有Lib，是否应当添加标记？
其实到目前为止，我还是不太了解您开发这个App的初衷，只是因为我自己有在做一些国产软件相关的统计，碰巧在酷安看到了您这款软件，觉得比较有帮助，在统计时也就顺手补充了一点信息。 有些App的私有Libs，命名也相对较为规范，虽然这些Libs并不是公开给其他开发者可以接入的，但是通过名称和App本身具有的功能，也能够猜出其大致的作用。 比如网易云音乐中，就有下列这一系列命名非常规律的私有lib： libnecmH264Enc.so libnecmH264Dec.so libnecmMediaEdit.so libnecmMediaCommon.so libnecmMediaInfo.so libnecmAACEnc.so libnecmMediaPlayer.so libnecmAACDec.so libnecmMediaGift.so libnecmMediaFlvCrypto.so libnecmMP3Dec.so libnecmMediaCodecJDec.so
这些都是凭借“常识”就可以推断出他们具体作用的运行库文件，是否有必要为这些文件增加标记描述呢？
我目前不是一个Android开发者，只是一个比较爱折腾的玩家，当然因为有在学习其他的编程语言，各类开发文档还是能含糊的懂个大概、稍稍查些资料也就能获得一些这类“常识”。对于和我差不多的、同样具有一些“常识”的用户来说，给这些文件标记完全没有意义，因为仅仅是合理猜测，而无法去真正证实。
但对于纯小白用户而言，他们可能更关心的，是App会不会偷偷“干一些坏事”，如果我们把这些能够通过合理猜测推断出它的用途的lib，给打上一个标签，和描述的话，这样App列表里剩下的，就仅仅是我们谁也无从推断的libs没有标记（当然可以开调试然后穷举操作行为直到找出调用的时刻，不过没有意义）这样的话，当他们点开一个App详情，看到全部的Libs都是“有人了解它是干啥的”的时候，就会对这个App更加放心一些，反过来，如果一点开，里面全是“不明所以”的libs，就会更加担心这个App是否会作恶。
因为并不了解您开发这款App是否有面向小白用户的想法，所以我提出了这样一个意义不大的问题，如有打扰，还请谅解。
选择发在Issue而并非通过反馈的方式，是因为这个想法，我希望可以被其他人也看到，如果有足够多的用户也认为有必要添加的话，那么即使您不想浪费时间在这些意义不大的事情上，其他愿意花些时间在这上面的用户也可以另行Fork出一个版本，但如果多数人也都认为没意义，那自然就不必去做这件事了。
其实我开发这款 App 的初衷是给自己用来学习 Android 用的，方便看各个软件用了哪些技术。但是现在发展成了大家用来看广告 SDK 和看系统更新内置软件的作用了😂。
关于标记库，原则上不能只靠猜测来判断，而是需要有明确的官方文档指出其用途。因为现在有许多开发者也在用我的 App，包括一些极客用户，确保正确的信息才不会造成迷惑和误导。
我其实是不打算做成那种“清理广告”、“查看流氓行为”的软件的，而是相对中立。当然未来也有计划做自定义仓库功能，这样爱折腾的用户可以 fork 我的仓库，然后自己修改。
@zhaobozhen 是不是搞个订阅就可以第三方规则了？
自定义仓库这里我后面会做，现在这个机制其实不太好，标签的显示还要靠主程序更新才能更新。后面可能会打包成数据库，根据版本直接在应用里更新。然后仓库的数据格式也要变化，在这些都做完之后就可以支持自定义仓库了。
@zhaobozhen 是不是搞个订阅就可以第三方规则了？
自定义仓库这里我后面会做，现在这个机制其实不太好，标签的显示还要靠主程序更新才能更新。后面可能会打包成数据库，根据版本直接在应用里更新。然后仓库的数据格式也要变化，在这些都做完之后就可以支持自定义仓库了。
如果打包成数据库了，那应该如何开放数据库接口，或者是把整个数据库文件下载下来？
@zhaobozhen 是不是搞个订阅就可以第三方规则了？
自定义仓库这里我后面会做，现在这个机制其实不太好，标签的显示还要靠主程序更新才能更新。后面可能会打包成数据库，根据版本直接在应用里更新。然后仓库的数据格式也要变化，在这些都做完之后就可以支持自定义仓库了。
如果打包成数据库了，那应该如何开放数据库接口，或者是把整个数据库文件下载下来？
后面我会开发一个规则生成器，自动打包成规则包，当然那可能是很久之后的事情了（
其实我开发这款 App 的初衷是给自己用来学习 Android 用的，方便看各个软件用了哪些技术。但是现在发展成了大家用来看广告 SDK 和看系统更新内置软件的作用了😂。
关于标记库，原则上不能只靠猜测来判断，而是需要有明确的官方文档指出其用途。因为现在有许多开发者也在用我的 App，包括一些极客用户，确保正确的信息才不会造成迷惑和误导。
赞赏为准确性做出努力，但单凭文件名作高精度判定，感觉不太可能完全实现。如果有库同名，免不了误导。不少库的官方文档没有清晰提及生成后的so文件名，只能推理。还有某些.so是厂商在多个SDK中共享使用，有点难以分组。 个人建议提供多阶仓库、更多选项（包括如开发者、描述的中文/英文；乃至列出多种选项和允许投票），尽早允许网友自定义规则（并在界面中明确标识）。能通过文档或名称大致确定/推测用途的，描述并作相关标注。
现有规则中有一例，native-libs/libJni_wgs2gcj.so.json，没有作者、源码位置，但记录了介绍。
