uni-app为什么混淆加密只支持nvue？
uni-app为什么混淆加密只支持nvue？
打包加密问题
打包时加密只支持nvue？居然不支持js或vue文件，如果把文件名改成nvue，一大堆CSS编译错误，还要去修改，太麻烦了……之前用过另一个平台的方案，打包可以全部代码都加密，生成的apk改成zip解压后，虽然可以看到原始目录结构，不过文件全是乱码加密的，实际上使用也没有什么加密解密导致的效率问题……如果uni-app也能实现那就很好了……如果只是nvue文件加密,那改成nvue代价可能就有点大了……
| 信息类型 | 信息 |
|---|---|
| 开发环境 | - |
| 版本号 | - |
| 项目创建方式 | - |
主要是要加密公共js中的一个接口加密用的key，我按你说的把这个变量放在App.vue中的globalData，然后改名为App.nvue，然后配置中尝试去混淆App.nvue，发现这么操作编译不通过。辣么有什么方法能解决呢。谢谢。
回复 DCloud_heavensoft: 那按你这么说，APP打开的第一个页面设置为nvue，然后在这个页面把一些敏感变量赋值给storage，然后其它好几个vue文件都import一个js，js中需要这个敏感变量，直接通过storage获取。这样打包后的apk转成zip解压后的代码就不含有这个敏感值了？我还没有试过，感觉很奇怪，应该有更直接处理方式才对！
回复 DCloud_heavensoft: 那我最小的改动就是软件打开后的那个界面做成nvue（各种CSS填坑），然后在这个界面进行vuex变量的赋值，然后配置下这个nvue文件为加密文件，打包时打上加密选项……感觉这种仅支持nvue加密的做法有点奇怪……和后端接口交互，一般都有接口签名加密的密钥，我觉得如果是商业应用，应该都有类似需要加密的变量需求的。
回复 DCloud_heavensoft: 很多人如果不注意，可能都觉得uni-app打包后的APP就是完全加密的，我看论坛中有的评论有好多人很吃惊，说为什么解压后能看到源码之类……感觉打包时再加强下这个提示，引导他们去做相应的加密处理会更好……界面那些效果泄漏倒是其次，主要是一些敏感信息泄漏影响很大……
在uni-app的开发过程中，混淆加密是一个重要的环节，用以保护代码逻辑和资源不被轻易反编译或篡改。针对你提到的“uni-app为什么混淆加密只支持nvue”的问题，实际上，这是一个基于技术实现和平台特性的考虑。不过，在解释这一点之前，需要澄清的是，uni-app本身并不直接提供混淆加密的功能，而是通过集成第三方工具或平台特性来实现这一功能。
首先，我们需要了解nvue和vue页面的区别。nvue是基于Weex引擎的页面，它允许使用Vue的语法来开发原生渲染的页面，这意味着nvue页面最终会被编译成原生代码运行。而vue页面则是通过H5+技术栈实现的，它在Webview中运行，代码以JavaScript的形式存在。
由于这种技术差异，混淆加密的实现方式也会有所不同。对于nvue页面，由于它们被编译成原生代码，因此可以使用原生开发环境提供的混淆加密工具，如Android的ProGuard或iOS的LLVM的Obfuscator等。这些工具在编译阶段对代码进行混淆，从而增加反编译的难度。
然而，对于vue页面，由于它们运行在Webview中，代码以JavaScript形式存在，混淆加密的实现就变得更加复杂。虽然存在JavaScript混淆工具，如UglifyJS、Terser等，但这些工具只能在一定程度上增加代码阅读的难度，并不能完全防止代码被反编译或篡改。此外，JavaScript混淆还可能引入性能问题，因为混淆后的代码往往不如原始代码高效。
以下是一个简单的示例，展示了如何使用Terser对JavaScript代码进行混淆：
# 安装terser
npm install -g terser
# 使用terser进行混淆
terser input.js -o output.min.js --compress --mangle
在上述命令中，input.js是原始JavaScript文件，output.min.js是混淆后的输出文件。--compress和--mangle选项分别用于压缩和混淆代码。
然而，需要注意的是，这种混淆方式并不能提供与原生代码相同的保护级别。因此，在需要高安全性保护的场景中，建议优先考虑使用nvue页面，并利用原生开发环境提供的混淆加密工具来保护代码。
综上所述，uni-app混淆加密“只支持nvue”的说法并不准确，但nvue页面确实在混淆加密方面提供了更多的选择和更高的保护级别。对于vue页面，开发者需要权衡混淆效果、性能和安全性之间的关系。
